1同行回答
保险的业务系统架构庞大，前端后端业务/中台/规则/核心/打印等众多系统，不仅南北向交互频繁，而且在东西向调用也非常密切密切。规划前，务必梳理清系统间交互逻辑以及数据特征，脱离于业务模型与数据关联设计的数据保护方案，必将导致数据耦合性错乱，造成无效保护的致命缺陷。根据保险系统的模型，参照数据体量、规模、连续性，有几类数据需要密切关注：
1，电子保单类数据，主要包括投保保单的电子化信息，如保单合同、扫描件、渠道回传以及交易处理报文等众多信息，属于长期保留数据。电子保单类数据可以说是保险公司的资本，至关重要。电子保单类数据，在体量上无法形成海量规模，但在系统间关联性极强。针对此类数据，由于电子保单类零散分布在众多业务系统中，拥有多个取数逻辑渠道，在方案设计前务必与业务需求方统一取数备份逻辑，尽量保留多份不同源数据保护方式避免备份失效、数据无法恢复，同时还应注意避开批处理以及间发性业务高峰，防止备份时与业务发生IO竞争。
2，影像件数据，主要包括保单相关的影印件，如投保单材料复印件、OCR图片信息以及交易环节处理的签章信息等，属于长期保留数据。影像数据，常由于文件小、数量多等特征形成海量文件。针对此类型数据，保险行业通常采用NAS等低端存储进行保留。对于海量影像数据的保护，主流数据保护常采用NDMP方式进行数据备份，NDMP方式备份虽然解决了读取数据块问题，但由于影像数据小且多，没有解决数据遍历时消耗的大量时间，其效率依旧不乐观。除此之外，主流的备份软件支持多流并行备份方式，如果业务数据配置、格式相似，数据读取路径统一，采用此种方式能有效改善数据遍历时扫描文件慢的焦点问题。当然若是资源成本允许，利用对象存储替代低端NAS存储存储影像，从根本上去解决影像存储问题也不为一种不错的解决方案。
3，交易处理日志，日志信息主要包括APP应用、中间件以及系统处理各类保单时形成的日志文件，日志文件是后台系统维护人员排障时的重要参考之一，属于短期或中长期保留数据。交易处理日志，通常情况下会定期分割，然后归档转存。单个系统的日志文件规模，视系统负载情况而定，一般为GB级别文件。对于同一系统的日志文件，结构、内容以及格式都相似度高，具有大量重复内容，此场景下采用重复数据删除手段，效果显著。