看实测，不看承诺 — RPO、RTO、3-2-1 与不追责的复盘

一句话总结

RPO 和 RTO 是写在文档里的目标，而恢复演练是测量这些目标实际在多少分钟内守住了。实际数据丢失要从“最后一次成功的备份”算起，实际恢复时间要从故障开始的那一刻算到服务被确认的那一刻。演练结束后，必须留下不追究个人责任的事后分析，以及有负责人和期限的改进措施。

为什么需要它

“备份每小时运行一次，RPO 是 1 小时”这句话经常是假的。如果备份作业连续失败了两次而没人知道，实际损失就是三个小时。“恢复 30 分钟就够了”也只是测了恢复命令运行的时间，而发现故障要 15 分钟，决定恢复要 13 分钟，准备又要 13 分钟。目标与实测的差距，只有做演练才看得到。

工作原理

两个目标。 NIST SP 800-34 Rev. 1 这样定义应急计划的术语。RTO（Recovery Time Objective）是系统允许停止的最长时间，RPO（Recovery Point Objective）是必须把数据恢复到故障之前的哪个时间点——也就是可以丢失的数据的最大时间跨度。

	目标	实测方法
RPO	允许丢失的最长时间	故障时刻 − 故障前最后一次成功的备份时刻
RTO	允许停止的最长时间	服务确认时刻 − 故障开始时刻

实测时常出错的地方有两处。一是把 RPO 算成“最后一次备份的时刻”，却不看那次备份是否失败；二是把 RTO 算成“从恢复开始到结束”。对用户来说，服务从故障开始的那一刻起就停了。

按区间拆开。 把恢复时间拆成检测 → 决策 → 准备 → 恢复 → 确认几个区间，就能看出该缩短哪里。如果恢复命令最长，就改备份方式或带宽；检测最长，就改告警；决策最长，就改由谁决定什么的流程。

3-2-1 规则。 这是美国 US-CERT 在 2012 年的 Data Backup Options 中推荐的规则——数据保留三份副本（包括原件），存放在两种不同的介质上，其中一份放在另一个地点。同一个磁盘阵列内的三个快照，即使有三份副本，介质只有一种、地点只有一个，所以违反了规则。阵列整个损坏或建筑物起火时，三份会一起消失。

验证恢复出来的数据。 恢复“完成了”与数据“正确”是两件不同的事。备份时如果同时留下一份记录每个文件哈希的清单（manifest），恢复之后与清单对照，就能区分出缺失的文件和内容不同的文件。sha256sum -c 就做这件事。

不追究个人责任的事后分析。 SRE 书中关于事后分析文化的一章说，事后分析必须是无责（blameless）的。一旦开始找是谁错了，人们就会隐瞒事实，而同样的条件依然留在那里。在根本原因一节里，不要写“谁”，而要写让那个人只能那样做的条件——备份失败没有触发告警，没有人看备份目标卷的余量。改进措施要附上负责人和期限。没有负责人的措施没有人会去做。

在现场相遇的样子

演练中最常暴露的事实是备份一直在悄悄失败。备份目标卷写满导致增量备份失败，而告警只发到了邮件，没有人看那个邮箱——这样的故事很常见。所以备份监控不要停留在“作业失败就告警”，而要设成“最后一次成功超过 N 分钟就告警”。作业根本没有运行时，失败告警是不会来的。

第二种是恢复流程只存在于人的脑子里。演练最好让不了解该流程的人只看运行手册去做一遍。如果演练时准备区间很长的原因是“在找恢复服务器的连接信息”，那么把这些信息写进运行手册就是改进措施。第三种是只做一次演练就结束。数据规模和配置在不断变化，半年前是 45 分钟的恢复，现在可能要两个小时。每个季度重复同样的演练，把各区间的用时累积成表，目标能不能守住就会以趋势的形式显现出来。

下一项实验要做什么

在四套数据的副本清单中找出违反 3-2-1 的。用备份作业记录和故障记录测出实际的数据丢失时间和恢复时间，与目标比较，找出最长的区间。把恢复出来的文件与清单对照，区分缺失的和发生变化的，最后撰写不追究个人责任的事后分析和有负责人、期限的改进措施。