📚 课程目录第3章备份策略设计

3. 备份策略设计：全量备份、增量备份、差异备份、备份窗口与频率规划

备份策略这东西，说白了就是回答三个问题：备份什么、什么时候备份、怎么恢复最快。我见过太多团队把备份搞成了“心理安慰”——每天跑个脚本，日志全绿，真到恢复的时候才发现缺这少那。嗯，咱们今天就把这块掰开揉碎了讲。

调度系统的数据，无非就是任务定义、执行记录、状态快照、日志这几类。针对不同数据，备份方式也得灵活搭配。我个人习惯把备份方式分成三种，先看个对比：

备份类型	备份数据量	恢复速度	存储空间	典型场景
全量备份	全部数据	最快（一次恢复）	最大	周/月基线、系统初始化
增量备份	上次备份后变化的数据	最慢（需逐层恢复）	最小	高频备份、日志归档
差异备份	上次全量后变化的数据	中等（全量+最近差异）	中等	日间快速恢复、中间态保护

你想想看，增量备份虽然省空间，但恢复时要先恢复全量，再按时间顺序把每个增量包一个个叠加上去。我在项目中遇到过，一个跑了三个月的调度系统，增量链长达 90 层，恢复时花了整整 7 个小时——业务早就炸锅了。所以我的原则是：增量备份只适合短链，超过 7 层必须做一次全量或差异来截断。

备份窗口，就是系统允许备份操作占用的时间窗口。调度系统有个特点——它本身就在调度任务，备份操作不能跟业务任务抢资源。我一般这样规划：

注意： 备份窗口不是越长越好。我曾经见过一个团队把全量备份窗口设了 6 小时，结果备份任务跟凌晨的批量任务撞车，导致调度队列积压，核心任务延迟了 40 分钟。记住，备份窗口的上限 = 业务容忍的最大延迟 - 安全余量。

备份频率怎么定？我有个简单的公式：RPO（恢复点目标）决定频率，RTO（恢复时间目标）决定备份类型。

举个例子：如果你的调度系统要求最多丢失 1 小时的数据（RPO=1h），那增量备份至少每小时一次。如果恢复时间要求在 30 分钟内（RTO=30min），那增量链就不能太长，否则恢复时叠加太慢。

我常用的频率规划模板：

我的经验： 任务定义这类低频变化的数据，全量备份就够了，没必要做增量。执行记录变化快，增量备份最划算。日志文件嘛，我建议直接走日志轮转+归档，别跟业务数据混在一起备份。

单一备份方式很难满足所有需求。我推荐一个经典组合策略：

这样做的好处是：恢复时最多只需要“全量 + 最近一次差异 + 最近一次增量”，三层叠加，恢复速度可控。我在项目中用这个方案，RTO 从原来的 2 小时降到了 25 分钟。

下面这张图，是我自己画的一个备份策略执行流程，你可以参考：

做备份策略这么多年，有些坑我是一路踩过来的。分享几个典型的：

增量链无限增长：我曾经有一个调度系统，增量备份跑了 3 个月没做全量，结果一次磁盘故障，恢复时发现增量包有 200 多个，恢复花了整整 2 天。从那以后，我强制要求增量链不超过 7 层，超过就自动触发一次差异备份截断。
备份窗口跟业务窗口重叠：有一次我把全量备份设在凌晨 1 点，结果业务方临时加了个凌晨批量任务，两个任务抢 IO，备份跑了 5 小时还没完，业务任务也延迟了。后来我加了备份窗口检测，如果窗口内 IO 压力超过阈值，自动推迟到下一个窗口。
只备份不验证：这个最要命。备份日志全绿，但恢复时发现文件损坏。我现在每个备份任务完成后，都会随机抽取 5% 的数据做恢复验证，确保备份文件是可用的。

核心总结：

嗯，备份策略这块，说白了就是空间、时间、恢复速度的三角博弈。没有银弹，只有根据业务场景不断调整。我个人的习惯是每季度复盘一次备份策略，看看 RPO/RTO 是否还满足业务需求，备份窗口有没有被新业务挤占。保持迭代，才能让备份真正成为容灾的基石。