RPO、RTO，以及 3-2-1
一句话总结
备份设计中的所有选择，都源于 RPO（最多允许丢失多少数据） 和 RTO（必须多快恢复） 这两个数字。
为什么需要它
“备份周期该怎么定？”这个问题本身没有答案。把它改成 “最多允许丢失多少分钟的数据？”，答案就会出现。
- RPO(Recovery Point Objective) — 发生故障时，能够恢复到多早以前的数据，也就是可接受的数据丢失量。如果 RPO 是 1 小时，备份间隔也必须不超过 1 小时。
- RTO(Recovery Time Objective) — 从故障发生到服务恢复所允许的时间。它不仅取决于备份方式，还取决于整个恢复流程。
这两个数字直接关联成本。要把 RPO 缩短到分钟级，需要持续归档；要把 RTO 缩短到分钟级，需要待命系统。因此，这些数字由业务而非技术决定。 工程师的工作，是接收这些目标并把它们转化为可实现的设计。
如何运作
三种方式
| 方式 | 保存什么 | 备份时间 | 恢复时间 | 存储空间 |
|---|---|---|---|---|
| 全量(Full) | 全部内容 | 长 | 短（只需解开一个备份） | 大 |
| 增量(Incremental) | 上一次备份之后的变更 | 短 | 长（全量 + 按顺序应用所有增量） | 小 |
| 差异(Differential) | 上一次全量备份之后的变更 | 中等 | 中等（全量 + 最后一次差异） | 中等 |
增量和差异很容易混淆，关键在于基准点不同。增量以上一次备份为基准，差异以上一次全量备份为基准。因此差异备份会逐日变大，但恢复时只需要两个备份。
实践中常见的组合是每周一次全量 + 每天一次增量。不过它的风险是，只要一个增量损坏，之后的所有增量都会失效。因此必须同时配套多代保留策略和定期验证。
3-2-1 规则与现代补充
经典规则是：3 份副本、2 种不同介质，其中 1 份位于异地。
如今通常还会再加两条。
- 其中 1 份离线或不可变(immutable) — 用于防御勒索软件。如果生产网络能访问备份服务器，备份也可能一起被加密。
- 0 个错误 — 定期执行恢复验证，确认错误为零。
一致性 — 备份过程中仍在变化的数据
复制文件时，如果应用仍在写入该文件，备份就会成为不属于任何时点的混合状态。对数据库尤其致命。
解决方法分为三个层次。
- 应用级转储 —
pg_dump -Fc,mysqldump --single-transaction。最可靠，且可移植性最好。 - 文件系统快照 — LVM/Btrfs/ZFS。先冻结时间点，再备份快照。但它只冻结块级时点，不会包含应用仍保存在内存中的数据。而且，快照卷写满后快照会失效，所以必须预留足够空间。
- 持续归档 — 持续归档 WAL/二进制日志，以支持任意时间点恢复。需要将 RPO 降到分钟级时使用。
恢复演练真正暴露的问题
备份策略中未经验证的部分，永远在恢复端。定期真正恢复一次，通常会发现以下几类问题。
没有恢复目的地。 有备份，却没有用于解包的磁盘和服务器。故障时获取这些资源所需的时间会直接计入 RTO。要测量真实恢复时间，必须从空服务器开始。
备份里缺少必要内容。 数据库备份了，却没有上传文件、配置文件，或证书和密钥。原因是列清单时只考虑了“数据”，没有统计重新启动服务所需的一切。
密钥也在备份里。 如果解密密钥只和加密备份放在同一个位置，它就毫无意义。反过来，若把密钥放在无人知晓之处，也无法恢复。应将密钥放在不同于备份的位置，但至少两个人能够访问。
不知道顺序。 文档没有说明该先启动数据库、是否需要清空缓存，以及如何处理队列中的剩余消息。结果是数据恢复了，服务却无法正常运行。
备份早已悄悄停止。 如果只发送成功通知，长时间没有任何消息反而看起来像正常状态。应把最近一次备份的年龄作为指标并设置告警。“24 小时内没有成功备份就告警”比“失败时告警”更可靠。
从未确认备份是否可读。 很多系统只要文件大小正确就判定成功。至少要实际解压；如果是数据库，则应真正连接并查询一行数据。没有测试恢复的备份，不是备份，只是文件。
现场常见情况
记住备份悄悄失效的五种方式会很有帮助。
- 目标被遗漏 — 新增了卷，却没有加入备份脚本。
- 只看成功日志，看不到失败 — cron 默认保持安静，必须检查退出码并提供失败通知机制。
- 勒索软件传播到备份 — 只保留最新备份的配置对此完全无能为力。
- 恢复目标环境不同 — UID/GID 映射、SELinux 上下文或内核版本不同时，文件虽已恢复，服务却可能无法启动。
- 备份影响生产性能，导致备份窗口缩短 — 之后往往会拉长周期，最终无法满足 RPO。
针对第 2 点，最低限度的防线如下。
#!/usr/bin/env bash
set -euo pipefail
trap 'echo "backup FAILED at line $LINENO" >&2; exit 1' ERR
rsync -aHAX --numeric-ids --delete /srv/data/ /backup/prod/data/
echo "backup OK $(date -Is)"
此外，把成功时间写入文件并监控**“最近一次成功是否在 24 小时内”**，远比阅读日志可靠。
接下来要检查什么
后续测验将检查在什么条件下选择 RPO、RTO、全量、增量、差异和异地副本。通过这些标准后，下一模块将继续实践 tar 全量与增量备份、rsync 多代保留、验证脚本，以及带时间测量的恢复演练。