增量备份是什么
增量备份只记录自上一次备份（可能是上一次全量，也可能是上一次增量）以来发生变化的数据，因此单次体积小、耗时短，适合数据量大而备份窗口紧张的场景。代价是恢复必须依赖完整链条：先还原基线全量，再按时间顺序依次应用每一份增量，中间任何一段缺失或损坏都会阻断恢复。
基本信息
| 备份依据 | 上一次备份以来的变化数据 |
|---|---|
| 单次开销 | 与变化量相关，日常较小且平稳 |
| 恢复依赖 | 全量基线加全部增量，顺序不可乱 |
| 主要风险 | 链上任一环节损坏或缺失都会影响其后恢复 |
| 生命周期 | 需要明确的全量锚点保留规则 |
增量与差异的差别
| 对比项 | 增量备份 | 差异备份 |
|---|---|---|
| 备份依据 | 上一次任意备份 | 上一次全量备份 |
| 恢复依赖 | 全量加全部增量 | 全量加最近一份差异 |
| 每日耗时 | 较小且平稳 | 逐日增长 |
| 链条风险 | 高，环环相扣 | 低，只依赖全量 |
GNU tar 增量归档
GNU tar 增量归档
# 快照文件记录上次归档状态，首次运行相当于全量
tar --listed-incremental=/backup/snap.file -czf /backup/inc-$(date +%F).tar.gz /data
# 重新开启链条：显式做一次 level 0
tar --listed-incremental=/backup/snap.file --level=0 -czf /backup/full-$(date +%F).tar.gz /data恢复顺序
恢复顺序
# 1) 先解包全量
tar -xzf /backup/full-2026-10-01.tar.gz -C /data
# 2) 再按时间顺序依次解包增量
tar -xzf /backup/inc-2026-10-02.tar.gz -C /data
tar -xzf /backup/inc-2026-10-03.tar.gz -C /data典型使用场景
- 备份窗口紧张：数据量大而低峰时段短，日常只传变化量才能跑完
- 异地传输成本敏感：跨地域链路的每日流量只按变化量计，费用与耗时都可控
- 虚拟机与镜像：块级增量只传变化的数据块，效果优于文件级比对
- 数据库日志：日志归档本身就是一种持续增量，配合基础备份实现时间点恢复
- 频繁保护点：需要每天多个恢复点时，用增量补足两次全量之间的空缺
链条管理是核心难点
增量备份的可靠性完全取决于链条完整：全量锚点不能被过早清理，中间任何一份副本损坏都会让之后的恢复点一并失效。专业备份软件会自动维护链条生命周期，自研脚本则必须自己实现『新全量成功后才清理旧链条』的顺序，并把链条完整性纳入监控。
常见误解
- 以为恢复快：增量恢复比全量慢，链条越长越慢，长链可能反而超出恢复目标
- 以为可以跳过中间副本：增量记录的是相对变化，跳过一段就得不到正确状态
- 以为不同工具可以混用：mtime 对比、块级位图、日志序列三种语义互不兼容
- 以为全量可以随时清理：锚点被删后，依赖它的所有增量都成为废数据
- 以为日常增量成功就安全：链路末端成功不代表链条起点仍完好
增量链条要有明确的生命周期管理：全量锚点不能被过早清理，清理脚本必须先确认没有任何恢复点仍依赖它。
缩短链条的常用做法是定期合成全量或做一次真全量：链条越短，恢复越快，断链影响面也越小。
块级增量（虚拟机位图、存储快照差异）与文件级增量的失效粒度不同：前者以数据块为单位，后者以文件为单位，混用时恢复结果不可预期。