2. 增量备份核心原理：什么是增量备份？与全量、差异备份的对比
聊备份策略，绕不开三个基本概念：全量、增量、差异。很多刚入行的朋友容易把增量和差异搞混，我当年也踩过这个坑。今天咱们就把这三兄弟掰开揉碎了讲清楚。
2.1 三种备份方式的基本定义
先给个最直白的定义：
- 全量备份：把整个数据源完整复制一份。不管文件有没有变化，全部重新拷贝。
- 增量备份：只备份自上一次备份（无论全量还是增量）以来发生变化的数据。
- 差异备份：只备份自上一次全量备份以来发生变化的数据。
嗯，关键区别就在“上一次备份”和“上一次全量备份”这六个字上。你想想看，这决定了恢复时你需要多少个备份集。
一句话总结：全量是“全部重来”，增量是“只存变化”，差异是“从上次全量开始算变化”。
2.2 三种备份方式的详细对比
我个人习惯用一张表来对比，这样最直观：
| 对比维度 | 全量备份 | 增量备份 | 差异备份 |
|---|---|---|---|
| 备份数据量 | 全部数据 | 仅变化数据 | 自上次全量后的变化数据 |
| 备份速度 | 慢 | 最快 | 中等 |
| 存储空间占用 | 最大 | 最小 | 中等 |
| 恢复速度 | 最快（只需一个备份集） | 最慢（需全量+所有增量链） | 中等（需全量+最新差异） |
| 恢复复杂度 | 低 | 高（需按顺序应用） | 中 |
| 典型使用场景 | 首次备份、定期全量 | 高频备份、节省空间 | 平衡备份与恢复效率 |
看到这里你可能会问：既然增量备份最省空间，为什么不全用增量？别急，咱们接着往下看。
2.3 增量备份的核心机制
增量备份之所以能“只存变化”，靠的是变化追踪机制。我在项目中遇到过几种常见的实现方式：
- 文件修改时间戳：检查文件的 mtime（修改时间），如果晚于上次备份时间，就备份。
- 文件大小/校验和变化：对比文件大小或计算哈希值，判断是否变化。
- 块级别变化追踪：在文件系统或存储层记录哪些数据块被修改了。
- 数据库日志解析：对于数据库，直接读取事务日志或归档日志。
举个例子，假设你有一个 100GB 的数据库，每天只修改 1GB 的数据：
- 全量备份：每天 100GB，一周就是 700GB。
- 增量备份：周一 100GB（全量），周二到周日各 1GB，一周总共 106GB。
- 差异备份：周一 100GB（全量），周二 1GB，周三 2GB（周一+周二的变化），周四 3GB……周日 6GB，一周总共 121GB。
你看，增量备份在存储成本上优势非常明显。但代价是什么？恢复时你需要先恢复周一的全量，然后按顺序应用周二、周三……直到周日的增量。如果中间任何一个增量文件损坏，后面的数据就全废了。
我曾经遇到过这样一个事故：某客户使用增量备份策略，连续跑了 90 天没有做全量。结果第 85 天的增量文件损坏，导致后面 5 天的数据全部无法恢复。从那以后，我建议所有项目至少每周做一次全量，或者采用“增量永久”+定期合并的策略。
2.4 三种备份策略的恢复流程对比
恢复流程的差异，直接决定了 RTO（恢复时间目标）。咱们用一张流程图来展示：
从图中可以清楚看到：全量恢复一步到位，差异恢复两步搞定，增量恢复则需要“全量+所有增量”按顺序应用。恢复时间与增量数量成正比，这就是为什么增量备份不能无限累积下去。
2.5 实际项目中的选择建议
说了这么多，到底该怎么选？我根据多年经验总结了几条原则：
我的建议：
- 数据量小于 500GB：直接全量备份，省心省力。恢复快，管理简单。
- 数据量 500GB ~ 5TB：每周全量 + 每日增量。这是最常见的组合，平衡了存储成本和恢复效率。
- 数据量大于 5TB：考虑差异备份或增量永久策略。但必须做好备份链的完整性检查。
- 数据库场景：优先使用日志备份（本质是增量），配合定期全量。
另外，不管你选哪种策略，定期做恢复演练是必须的。我见过太多团队只做备份不做恢复测试，真到出问题时才发现备份文件是坏的。嗯，这个坑我替你们踩过了。
2.6 避坑指南
最后分享几个我亲身经历过的教训：
- 增量链不能太长：建议最多累积 7 个增量就做一次全量。超过 30 个增量，恢复成功率会显著下降。
- 注意备份窗口：增量备份虽然快，但如果变化量突然暴增（比如全量索引重建），备份窗口可能超出预期。
- 校验和不能省：每次备份完成后，务必做校验和验证。我曾经因为存储介质静默错误，导致增量备份数据损坏。
- 元数据要独立存储：备份的元数据（时间戳、校验和、文件列表）最好单独存放，不要和备份数据混在一起。