dr-drills

灾难恢复演练的频率、场景与验收

补充说明

DR 演练验证的是“真出事时能不能在 RTO 内恢复、会丢多少数据（RPO）”，不是“备份任务是否成功”。备份成功不等于可恢复；必须实际恢复到独立环境并校验数据。

演练类型从桌面推演、单组件故障、区域切换到全量恢复。频率按业务等级定，核心系统至少每季度一次切换演练。

常用示例

DR 分级：

演练方案模板：

演练名称：prod-sh-1 区域故障切换
时间窗口：2026-11-08 02:00–05:00 CST
范围：支付、订单；不含风控
前置条件：备份校验通过、DNS TTL 调到 60s、观察者就位
步骤：
1. 冻结变更，通知业务
2. 停止 prod-sh-1 写入或模拟区域故障
3. 提升 prod-sh-2 数据库为主
4. 切换全局流量
5. 验证核心链路和关键报表
6. 记录实测 RTO/RPO
中止条件：数据不一致、双写、错误率 > 5%
回滚：切回 prod-sh-1，恢复复制关系

备份恢复验证：

velero restore create --from-backup prod-20261017 --namespace-mappings prod:drill
kubectl -n drill get pods
kubectl -n drill get pvc
psql "$DR_DSN" -c "select count(*) from orders;"

切换后验证：

kubectl --context prod-sh-2 get nodes
kubectl --context prod-sh-2 -n checkout get pods
curl -fsS https://api.example.com/healthz

记录实测结果：

演练判定规则：

• 任一核心链路未恢复、数据丢失超过 RPO、RTO 超时，演练判定失败。
• 关键步骤依赖未文档化的个人知识，判定失败并更新 runbook。
• 演练后 5 个工作日内完成改进项登记，否则视为未闭环。

易错点与排错

• 只演练切换不演练切回，回切时发现复制方向、DNS 和证书都没配。
• 备份任务成功但从未恢复验证；恢复时缺 CRD、密钥、PV 或镜像。
• DNS TTL 太长，切换后客户端仍访问旧集群。
• 演练窗口未通知业务，被误判为真实故障并触发外部告警。
• 演练使用简化配置，生产依赖、数据量和网络策略未覆盖。
• 不记录实测 RTO/RPO，年年写“演练成功”但指标没有改善。
• 双写或数据回灌顺序错误，造成数据覆盖或重复。
• 演练后不更新 runbook、联系人和监控，下一次仍然手忙脚乱。

读完自测

合上页面，先回答，再展开对照。

1. 备份成功是否等于可恢复？为什么？
2. RTO 和 RPO 分别衡量什么？
3. 演练判定失败的条件有哪些？

相关条目

• disaster-recovery — 灾难恢复设计
• cluster-backup — 集群备份
• velero — 备份与恢复工具
• backup-strategy — 备份策略
• build-velero-backup — 动手恢复演练