3. 备份体系架构设计

备份体系架构设计的核心，不是简单地把数据复制一份，而是要在恢复时间目标（RTO）和恢复点目标（RPO）两个约束下，决定“多久备一次、每次备什么、备到哪里、保留多久”。全量、增量、差异三种备份类型是这套架构的三种基本积木，组合方式直接决定了备份窗口占用、存储成本与恢复速度。

三种备份类型的本质差异

全量备份每次复制数据集的全部内容，恢复时只需一份备份加日志即可回到一致状态，恢复链路最短，但备份窗口最长、存储占用最大。增量备份只备份自上一次任意类型备份以来发生变化的数据块，备份窗口最短、存储最省，但恢复必须按“最近一次全量 + 其后所有增量”的顺序逐层叠加，任何一层损坏都会导致恢复失败。差异备份备份自上一次全量以来所有变化的数据，处于两者之间：恢复只需“最近一次全量 + 最近一次差异”，链路短于增量，但备份量会随距上次全量的时间线性增长。

理解这三者的关键，是区分“备份时的代价”和“恢复时的代价”。增量把成本推给恢复，全量把成本推给备份，差异则在两者之间取平衡。架构设计就是在这个权衡曲线上，根据业务对RTO/RPO的要求选点。

组合策略：如何排布全量、差异与增量

最常见的生产组合是“每周一次全量 + 每日差异 + 每小时增量”。以某业务库为例：周日凌晨 00:00 做全量，周一至周六每天 00:00 做差异，每天 08:00 至 22:00 每小时做一次增量。这样，RPO 在业务时段可控制在 1 小时以内，夜间可放宽到 24 小时；恢复时若故障发生在周四下午，只需“周日全量 + 周三差异 + 周四各小时增量”，链路可控且备份窗口分散。

另一种组合是“全量 + 增量”，适合数据量极大、备份窗口极窄的场景，但必须配合更频繁的全量基线（如每 3 天一次），否则增量链过长，恢复时间会突破 RTO。还有“全量 + 差异”组合，适合数据变化量不大、但要求恢复链路短的场景，代价是差异备份量会逐日增长，需要评估存储容量。

备份窗口与RTO/RPO的量化设计

设计时必须先量化三个参数：数据总量 D、日均变化率 c、备份吞吐 T。全量备份耗时约为 D/T，增量备份耗时约为 D×c/T，差异备份耗时约为 D×c×n/T（n 为距上次全量的天数）。备份窗口必须小于业务低峰期时长，否则会与在线业务争抢 I/O。

例如：D = 2 TB，c = 5%，T = 200 MB/s。全量耗时约 2×1024×1024/200 ≈ 10486 秒 ≈ 2.9 小时；增量耗时约 2×1024×1024×0.05/200 ≈ 524 秒 ≈ 8.7 分钟；差异在 n=3 时约 26 分钟。若低峰期只有 3 小时，全量必须放在周末，工作日只做增量和差异。

RTO 的估算则要看恢复链路：全量恢复时间 ≈ D/T_restore，增量恢复还要加上逐层应用日志的时间。若 T_restore = 300 MB/s，2 TB 全量恢复约 1.9 小时；若叠加 6 个增量，每个增量应用约 5 分钟，则总恢复约 2.4 小时。如果业务要求 RTO ≤ 2 小时，就必须缩短增量链，或提高恢复吞吐。

保留策略：分层与合规

保留策略不能只按“保留 30 天”一刀切，而应按备份类型分层。常见做法是：全量保留 4 周，差异保留 2 周，增量保留 7 天，同时每月保留一份归档全量用于合规审计。这样既满足短期恢复需求，又控制存储成本。对于金融、医疗等有法规要求的行业，归档全量可能需要保留 6 个月至数年，并采用不可变存储或离线介质。

一个可落地的组合策略示例

该示例中，RPO 在业务时段为 1 小时，夜间为 24 小时；RTO 在增量链不超过 6 层时约 2.5 小时，若故障发生在周一，仅需“周日全量 + 周一增量”，RTO 可压缩到 2 小时以内。实际落地时，还需根据存储容量、网络带宽和恢复演练结果持续调优，而不是一次设定后长期不变。