备份软件上的绿色对勾，只说明任务跑完了，一些数据落到了某个地方。它没有说明能否靠这些数据重建业务，也没有说明要花多久。在真正恢复过之前，你手里只有一个假设，而验证它的机会可能就是一年里最糟糕的那一天。
从两个数字开始
这两个术语经常被混淆，有必要说准确。
- 恢复点目标（RPO）： 可接受的最大数据损失，以时间衡量。RPO为一小时，表示最多可以损失一小时的工作。每晚备份做不到这一点，傍晚发生故障可能损失将近24小时的数据。
- 恢复时间目标（RTO）： 中断后恢复服务可接受的最长时间。RTO为四小时，表示服务必须在四小时内恢复运行。
这两个都是业务决定，都是在成本和损害之间权衡。问问各部门负责人，丢失一小时订单或停机一天意味着什么，再告诉他们每种方案的成本。按系统分别设定，工资系统、网站和数据仓库的需求并不相同。还要检查是否一致：财务应用的RTO是四小时，它依赖的一切就必须更早恢复。
恢复为什么会失败
备份的问题总在那几个地方暴露：
- 密钥丢失。 数据加密得好好的，密钥却放在已经损毁的系统里。
- 范围不全。 有数据库，却没有密钥配置、系统配置、DNS、证书或部署工具。
- 传输太慢。 恢复能成功，但通过现有链路拉取大量数据要好几天，远超RTO。
- 数据不一致。 数据库写入时做的快照无法干净启动，或者相关系统的备份相隔数小时。
- SaaS没有保护。 托管服务里的数据，保留期可能与你的假设不符。读一读合同，弄清服务商能为你恢复什么。
- 知识流失。 只有一个人懂流程，而他正在休假。
勒索软件改变了设计
拿到管理员账号的攻击者通常先对备份下手，因为毁掉备份会提高受害者付款的可能性。域管理员能删除的备份，挡不住持有这些凭据的人。要按这种情况来设计：
- 不可变存储。 使用一次写入的存储，比如带保留期的对象锁，保留期内任何人（包括管理员）都不能缩短。要检查所选模式，有些模式允许特权覆盖。
- 独立凭据。 把备份放在单独的账户或租户里，使用不同的管理员和强认证，备份系统不要加入主域。
- 异地或离线副本。 老规则3-2-1仍是合理的底线：三份副本、两种介质、一份异地。
- 足够长的历史。 攻击者可能潜伏数周才动手。如果只留14天备份，而入侵发生得更早，手里的每份副本都可能带着他们的落脚点。
- 监控。 对备份被删除、保留期被缩短，以及备份大小或压缩率突变发出告警，这些可能是加密正在进行的信号。
在隔离网络中恢复，确认没有持久化后门后再接回网络，并预计这比普通恢复耗时更长。还要注意，根据新西兰《2020年隐私法》，即使数据没被复制，无法访问个人信息也可能构成隐私泄露。
做真正的演练
把恢复演练当作有书面结果的限时测试。轮换系统，并且每年至少做一次完整服务恢复，不要只恢复单个文件。让常规管理员以外的人按运行手册操作，手册的缺口才会暴露。每次记录：
- 恢复了什么，用的是哪份备份。
- 恢复数据的时间点，与RPO比较。
- 从开始到服务可用的时长，与RTO比较。
- 如何验证正确性，比如应用登录、记录数、与已知数字对账。
- 哪里出了问题，由谁修复。
数据库进程能启动，不算什么成功。有人用应用完成一项真实任务，才是更好的检验。
本周可以做的事
- 选出最重要的数据库，把昨晚的备份恢复到隔离环境。
- 从动手那一刻开始计时，包括查找密钥和凭据的时间。
- 做几项检查，证明数据确实可用。
- 创建一份用完即弃的测试备份，看普通管理员账号能否删除它。如果能，下一个优先事项就有了。
然后把结果交给风险负责人。实测的数字，比任何保证都有用。