在小团队里，灾难恢复通常只剩下一份从来没人打开过的文档里的一行字：备份已经开启。这句话本身没错，却算不上任何问题的答案，因为它既没有说明真正出事时找回来的数据会有多旧，也没有说明恢复一次要花多长时间，更没有说明到今天为止究竟有没有人完整地做过一次恢复。

拥有备份和真的能恢复之间存在一段明显的距离，大多数故障正是在这段距离里升级成事故。一份存在、内容也够新、却从来没有被还原过的备份，本质上仍然只是一个假设；而你第一次去验证这个假设的时刻，恰好是发现它其实是错的最糟糕的时刻。

两个数字能把意见变成计划。 你能承受丢多少数据，又能承受停多久？这就是你的恢复点目标和恢复时间目标。只要业务一侧没有人把这两个数字说出口，关于备份频率的一切技术争论都无法收尾，因为根本不存在可以用来判断对错的标准。

用大白话讲清 RPO 和 RTO

恢复点目标，也就是 RPO，指的是你允许丢失的数据量。只做夜间备份，意味着 RPO 是 24 小时：下午 17 点出故障，从前一天夜里到出事之间产生的一切都会消失。如果这个结果不可接受，那么错的是备份计划本身，在别的地方再怎么精心打磨，都补不回这部分损失。

恢复时间目标，也就是 RTO，指的是你允许停机的时长。它包含全部环节：发现故障、做出决定、准备资源、执行还原、验证结果，以及把流量切回来。很多团队只估算还原这一步，忘掉了另外五步，这正是真实恢复往往比预期多花好几倍时间的原因。

这两项都是业务决策而不是技术决策，而且指标定得越严格，要花的钱就越多。RPO 定成 5 分钟，就需要持续复制。RTO 定成 1 小时，就需要一套能够自动重建的基础设施，因为在高压之下没有人能在一小时之内手工把一台服务器配置完。

真正有产出的对话是关于取舍的对话。把每一档目标各自的成本告诉业务方，让他们来选，而不是在工程侧自己拍一个数字，然后祈祷这个数字刚好符合那些从来没有被说出口的期望。

没演练过的备份不算备份

真正让人痛的失败，很少是因为没有备份。多数时候痛的是那些在最需要的时刻才发现根本用不了的备份。

常见的原因如下，而且全都要等到还原时才会暴露出来：因为没有人像盯失败那样盯着成功，任务已经安静地失败了好几周；导出只抓到了表结构却没有抓到数据，或者只抓到一部分表，因为有人在很久以前把其余的加进了排除清单；文件确实加密了，可密钥偏偏就存在那台已经坏掉的机器上；备份和它本该保护的对象放在同一个账号、同一个区域里。

最后一条今天的分量比过去重得多。和生产环境放在一起的备份，只能防住硬件故障，除此之外什么都防不住。它扛不住账号被入侵，扛不住账号层面的误删除，也扛不住那种同一套凭据能碰到什么就能加密什么的勒索软件。

想知道一份备份到底能不能用，唯一的办法就是把它真正还原一次。把这件事排进日程，至少每个季度做一次，并且每次都计时。计出来的这个时间才是你真正的 RTO，而不是文档里写的那个数字。

灾难恢复必须覆盖哪些东西

数据是所有人第一时间想到的部分，却很少是拖慢恢复的部分。真正把恢复拖长的，几乎总是那些没有人列进清单的东西。

数据库，这个所有人都记得。用户上传的文件，通常单独存放在别处，而且往往根本没有任何备份。配置和密钥，很多时候只存在于正在运行的那台机器上。DNS 和证书，如果保管它们的账号恰好就是你丢掉的那个，短时间内根本重建不出来。基础设施本身，也就是服务器、网络和各类规则，如果用代码定义过就能很快重建，如果是靠在控制台上一路点出来的，那就慢得让人痛苦。

还有关于这一切如何拼在一起的知识，在小团队里这是决定恢复时间的最大单一因素。一套只有一个人能凭记忆重建的系统，它的恢复时间就等于那个人是否有空，而这称不上是计划。

先写清单，再写计划。多数团队在列清单的过程中，就会发现至少一个完全没有备份的组件；用这种方式发现它，比用另一种方式便宜得多。

一页纸就能写完的计划

事故进行当中没有人会去读长文档。你要瞄准的是一份疲惫的人在凌晨三点也能照着做、并且不需要动脑筋的东西。

它需要包含：由谁来宣布恢复已经开始，因为在这到底算不算灾难这个问题上犹豫，是最常见的拖延来源之一；备份在哪里、怎么拿到，包括一套不依赖已经倒下的系统的凭据；按顺序排列的还原步骤，具体到不需要临场发挥就能照着执行；如何验证确实成功了，也就是一项具体的检查，而不是网站看起来能打开这种感觉；以及对内和对外分别应该通知谁。

把它放在一个能在故障中幸存下来的地方。只存在于它要恢复的那套系统里的恢复计划，是一种反复出现、而且完全可以避免的错误。

同样的道理也适用于访问权限。如果只有一个人掌握主机账号的凭据，你的恢复时间就取决于这个人接不接电话。我们的 Linux 服务器加固指南 讲的正是这一切所依赖的访问控制。

匹配规模，而不是追求完美

小团队不需要在第二个区域放一套热备。成本是实打实的，而额外的复杂度本身又会带来新的故障方式。

多数小团队真正需要的东西便宜得多：放在独立账号里、用生产环境无法使用的凭据访问的备份；按固定周期演练并计时的还原；用代码定义、不用考古就能重建的基础设施；以及一份确实有人读过的一页纸计划。

这一组东西覆盖了硬件故障、误删除、账号被入侵和勒索软件，而现实中发生的事情大部分就是这几类。超出这个范围的部分，是在判断进一步缩短停机时间到底值多少钱，而这个问题应该由业务方来回答，不该由工程侧来回答。

Mecanik 在服务器安全分析 服务中会检查并搭建以上这些内容。第一个问题永远相同，而且和技术无关：你能停多久，以及这个数字是谁定的？

相关文章: 真正有意义的可用性 SLA 、小团队的软件供应链安全 、企业 AI 智能体：成本与失败之处 、英国金融科技软件开发：FCA、支付轨道与成本 。

常见问题

RPO 和 RTO 是什么意思？ 恢复点目标是你能承受丢失的数据量，所以只做夜间备份就意味着 RPO 是 24 小时。恢复时间目标是你能承受停机的时长，包含发现故障、做出决定、准备资源、执行还原、验证结果以及把流量切回来。两者都是业务决策，而且指标定得越严格，成本就越高。

为什么没演练过的备份不算备份？ 因为这些故障形态只有在还原时才会暴露。没有人像盯失败那样盯着成功，任务就会安静地失败好几周；导出可能只有表结构而没有数据，或者漏掉被排除的表；加密密钥就放在那台已经坏掉的机器上；副本和它保护的对象放在同一个账号里。请每个季度还原一次，并且每次都计时。

备份应该存放在哪里？ 存放在独立的账号或区域里，并且使用生产环境无法使用的凭据。放在同一环境里的备份只能防住硬件故障，除此之外什么都防不住：它扛不住账号被入侵，扛不住账号层面的删除，也扛不住那种同一套凭据能碰到什么就能加密什么的勒索软件。

灾难恢复里人们最容易漏掉什么？ 和数据库分开存放的上传文件、只存在于运行中机器上的配置和密钥、保管在一个本身也可能丢失的账号里的 DNS 和证书、靠鼠标点出来而不是用代码定义的基础设施，以及只有一个人掌握的、关于这一切如何拼在一起的知识。

小团队需要热备吗？ 通常不需要。成本是实打实的，额外的复杂度也会带来它自己的故障方式。放在独立账号里的备份、演练过并计过时的还原、用代码定义的基础设施，再加上一份确实有人读过的一页纸计划，就能覆盖硬件故障、误删除、账号被入侵和勒索软件，也就是现实中发生的绝大部分情况。