运维体系建设：运维自动化(7)

运维体系建设：运维自动化(7)

（本文共1533字，大约需要阅读4分钟）

自动化案例—数据完整性保障模型

备份恢复系统

二、复制机制子层

如果系统中有数据复制机制，在某些场景下对数据恢复是有辅助作用的。

1、底层存储的复制机制

底层存储的复制机制：在理想情况下，每个存储实例，包括那些保存了备份的基础存储系统都应该具有复制机制，否则在数据恢复过程中，可能才会发现备份文件不能读取。例如存储网络中的配置多存储器，每个存储器中的磁盘配置RAID。

将不同层级的备份存储在不同部署点上是更合理的，因为每个部署点不会同时出现故障。每个部署点都应该建立在某种冗余存储机制上，如RAID、Reed-Solomon纠错码、GFS等。这里还要注意，数据存储最看重的是稳定性，而非花里胡哨的功能，选择复制机制或存储系统时，尽量选择常规主流的、被许多用户持续使用的系统。使用不常见的系统，会有一定的售后、不常见的存储风险。当然，配置有最新功能的存储系统也可以使用，但需要在测试环境和用户试用环境下进行长期测试后才可以上线使用，进入线上环境时，也需要逐步替代老型号或并行运行，以确定其稳定性。

2、备份机制利用复制机制的优化

全量备份的本质：处理海量数据时，最重要也最有效的方式是给数据建立一个“可信点”（快照），也就是一部分数据校验过后，由于时间等原因变成了不可变数据。一旦确信某个用户的资料或者交易记录已经是不会再变的了，就可以校验并且进行合适的基准点保存，以便未来恢复，这也就是全量备份，这种快照的抽象原理可以向应用层或基础架构层延伸设计，全量备份不仅适用于结构化的数据库备份，也适用于非结构化的文件备份。

增量备份的本质：对于“可信点”之后的数据进行增量备份，其中仅包含自从上次备份后新增或更改过的数据。这种技术在理想情况下可以将备份时间缩减到与主要处理逻辑的吞吐量在一个数据级内，节约备份时间。

从恢复的角度来说，增量备份的过程是需要定期评估和优化的，我们都知道不能在3年前建立一个全量备份，然后三年来一直进行增量备份，因为那样的话完全恢复一份数据就需要顺序处理1000个相关性非常强的文件，只要有一个文件出现故障则整个备份无效，而且恢复时间非常长。如果我们的策略是一周进行一次全量备份，每天进行一次增量备份，就要考虑在恢复一次全量备份和6次增量备份的时间是否符合用户服务水平要求，在网络架构建立和工程验收时建立的这种以周单位的备份策略肯定是符合用户服务水平要求的，但在系统运行过程中，在系统架构师离场后，数据量会变的非常大，运维人员就需要对当时的备份策略进行优化以满足服务水平要求，如果不引入其他机制，仅仅将全量备份的周期由7天缩短（如缩短为3天），虽然满足了数据恢复的时间要求，但备份过程占用的系统资源就可能不符合数据保障的约束项要求，比如备份期间系统延迟大增，运维人员必须站在用户成本、系统架构、开发人员的角度从全局理解整个系统，此时采购和上线一个备份数据流水线就是一个优化的好工具。

备份数据流水线：用于降低复制和校验备份任务的时间总量的分布式计算方法。数据如果能合理分片，可以将N个任务并行进行，每个任务可以负责复制和校验1/N的数据。

备份流水线需要在设计部署阶段预先进行一些考量，目标是正确平衡数据分片、保证每个分片之间的独立性、避免相邻并行任务之间的资源抢占。平衡数据分片的原则是通过水平分割负载，同时按时间维度进一步限制垂直数据量的方式进行。备份流水线的技术评估我们在后面分布式中间件的篇章会详细介绍，这里我们只需要知道使用备份数据流水线机制的产品可以在满足数据保障约束项的前提下，加快数据备份时间，提高数据备份周期，以便系统在使用备份进行恢复时可以在服务质量要求时间内完成恢复工作。