备份与灾备演练 RTO RPO 的验证
PinkStage
6 min read
备份与灾备演练 RTO RPO 的验证
备份这件事最危险的状态是“以为有备份”。真正能救命的是演练过的恢复：在约定时间内、丢得起的数据范围内，把业务拉起来。RTO 是恢复要多久，RPO 是能容忍丢多少。两个数字不是写出来的，是演练测出来的。存储是所有有状态工作负载的地基，灾备则是地基出问题时的兜底，两者都经不起“假设它能用”。
RTO 与 RPO 到底约束什么
- RPO（恢复点目标）：灾难发生前最近一次可接受的数据丢失量。数据库每 5 分钟做一次归档备份，RPO 大致是 5 分钟量级。
- RTO（恢复时间目标）：从灾难发生到业务恢复可用允许的最长时间。RTO 两小时，意味着两小时内必须跑通。
两者相互拉扯：RPO 越紧，备份越频繁、成本越高；RTO 越紧，恢复流程越要自动化、演练越要熟。经验上，先按业务容忍度定这两个数，再反推备份频率和切换脚本，而不是反过来凭感觉写个“一小时恢复”。
用数字反推方案
给定 RPO=15 分钟，意味着备份间隔必须 ≤ 15 分钟，且最近一次成功备份到故障点的数据会丢。给定 RTO=1 小时，意味着从发现到恢复全链路（拉备份、起服务、校验、切流量）必须在一小时内跑完。把这两个数代入实际步骤，哪步超时就改哪步：备份拉取慢就先做增量；起服务慢就把镜像预热到恢复环境。
| 策略 |
典型 RPO |
典型 RTO |
适用 |
| 每日全量备份 |
约一天 |
数小时 |
数据变更少 |
| 定时增量加全量 |
分钟级 |
数十分钟 |
多数在线业务 |
| 同步双写或多活 |
近零 |
分钟级 |
核心高可用 |
数字不是越紧越好，越紧成本越高，要和业务能承受的代价匹配，而不是追求理论最优。
备份的三条铁律
- 3-2-1：至少 3 份副本、2 种介质、1 份异地。单机房单盘不算备份。
- 加密与权限：备份里往往含全量敏感数据，加密存储、最小访问权限是底线。
- 可验证：不被恢复过的备份等于不存在。定期做恢复校验。
全量、增量与差异
- 全量：每次都拷全部，恢复最简单但最费空间和时间。
- 增量：只拷上次以来的变化，备份快但恢复要按顺序拼，任何一环坏就断链。
- 差异：拷上次全量以来的所有变化，折中方案。
恢复时间随增量链长度上升，演练时要测“最差情况”——即离上次全量最远的那次恢复，别只测刚备份完的理想态，否则真实故障往往落在最坏的那一端。
演练才是验证
只在文档里写“RTO=4h”没意义，要真刀真枪跑：
# 演练流程（概念示意）
restore db --from backup-20261022 --target staging
verify db --checksum --rowcount
cutover app --to staging-db
measure elapsed --since drill-start
测完对比实际耗时和既定 RTO，差多少就补哪段：是备份拉取慢、还是切换手工步骤多、还是依赖服务没一起恢复。
演练要测“部分失败”
真实灾难很少是“一切都没了”，更多是“数据库在、应用挂”“主区没了、备区半通”。演练要故意制造部分失败：只恢复数据库不恢复缓存，看应用能否降级；只切一半流量，看备区能否扛住。只测“全好”的完美恢复，真实故障一来就懵。
演练期间的通报
演练虽是模拟，也要像真事故一样通报和记录：开始时间、参与人、每一步耗时、是否触发预案外操作。否则演练结果只有“成了”两个字，复盘时无从改进。把演练当事故演习，纪律才会在真出事时起作用。
容易被忽略的依赖
- 应用配置、密钥、证书要和应用数据一起恢复，否则库起来了系统起不来。
- 数据血缘：A 库恢复但 B 库没恢复到同一时间点，跨库一致性被破坏。
- DNS、网关、外部依赖的切换，常被遗忘在“数据库恢复”之外，导致流量进不来。
把恢复能力写进 SLO
恢复能力不是运维的私事，要作为 SLO 的一部分对外承诺，并定期汇报实际达成的 RTO/RPO。当业务方知道“最坏丢 15 分钟、一小时恢复”，他们才会配合做对应设计，而不是假设“永不丢、秒级恢复”。
演练频率与职责分工
建议每季度至少一次全链路演练，关键业务每月一次。演练要明确负责人、观察员、决策人三个角色，避免真实故障时没人拍板。把演练列入运维日历，和发布窗口错开，既不影响业务也能保证定期发生。很多团队写过预案却从没演练，预案躺在文档里等于没有，真出事时没人记得步骤。
恢复失败的真实原因归类
- 备份本身损坏：从不校验，恢复时才知道。
- 跨版本不兼容：用新集群版本恢复旧格式备份失败。
- 依赖没一起恢复：库起来了应用却连不上。
- 权限或密钥缺失：恢复环境拿不到解密密钥。
演练要把这些逐一验证，而不是只跑“数据库恢复”一条线。每暴露一类就补一类，演练的价值正在于把纸面预案变成可执行的肌肉记忆。
踩坑清单
- 备份成功但从不恢复，某天真要用发现备份文件损坏或版本不兼容，恢复直接失败。
- 把备份放在和源数据同一个故障域（同机、同可用区），机房级故障一起没。异地才算数。
- RPO 设成“零”，却只做每日全量，实际会丢一天数据，数字和现实脱节。
- 只演练了数据库，没演练整套链路，恢复后上游连不上、下游无数据，业务仍不可用。
- 演练在非真实时段做，没考虑白天流量、连接池、限速等约束，结果和真实故障差很远。
- 恢复脚本依赖某位同事的本地环境，人不在就跑不起来。脚本要进版本库、可在干净机器执行。
- 增量链断了还照常演练全量恢复，以为覆盖实则漏了中间环节，真实恢复时才暴露断点。
灾备的能力不是买来的，是一次次演练攒出来的。把演练排进例行日程，让它像发布一样常态化，RTO/RPO 才是真数字，而不是纸面承诺。
1 view
0 likes
0 comments