在勒索软件加密你的服务器那一天，没有人愿意临场才发现业务到底能恢复多少、需要多长时间。这两个答案有各自的名字：RPO 和 RTO。这些数字要么由你提前定好——从容地、摆在桌面上讨论——要么在最糟糕的时刻由事故替你决定。
本文不绕弯子地解释这两个概念，介绍至今依然有效的备份法则（3-2-1），并说明为什么一家运输公司——一天都不能停止开具 CT-e，也不能停止追踪货物——需要用一种特定的方式来思考这件事。清晰的定义，正是你会希望自己提前读过的那种。
RPO：你能接受丢失多少数据
RPO（Recovery Point Objective，恢复点目标）是你的业务能接受丢失的最大数据量，以时间来衡量。如果你的 RPO 是 1 小时，意味着恢复之后，你可能会丢失最近一小时的工作——而这是可以接受的。如果 RPO 是 24 小时，你可能只能回到昨天上午的那一份快照。
实际上，RPO 决定了你每隔多久做一次备份。你不可能一边设定 15 分钟的 RPO，一边一天只备份一次——这在数学上说不通。RPO 越小，备份就越频繁（也越昂贵）。
能解开这个定义的问题很直接：如果我丢失了自上次备份以来进入系统的所有数据，这会让我付出多大代价？对于一张已开具却未保存的 CT-e，代价是重新录入并冒着税务不一致的风险。对于一份货物装载清单，代价是不知道车上装了什么。
RTO：你需要在多长时间内恢复
RTO（Recovery Time Objective，恢复时间目标）是在恢复完成、系统重新运转之前，你的业务能承受停摆的最长时间。如果 RTO 是 4 小时，那么从事故发生到业务重新运转，你只有 4 小时——一分钟都不能多。
RTO 不只是把文件复制回去所花的时间，而是整段时钟：发现问题、隔离受影响的部分、找到一份干净的备份、恢复、验证其完整性并重新启动。只掐算复制时间的人，往往太晚才发现验证和重新启动所花的时间比预期更长。
这里的问题关乎金钱：每停摆一小时的代价是多少？对一家运输公司来说，停摆一小时意味着延误交付、SLA 罚款、卡车排队却没有单据、客户不断来电。正是这个每小时的成本，决定了是否值得投资更快的恢复。
RPO 与 RTO 不是一回事（而你两者都需要）
它们常被混淆。区分它们的简单方法是：
- RPO 向后看——在过去，你能接受丢失多少数据。
- RTO 向前看——从现在起，你能接受停摆多久。
一个系统可能 RPO 极好而 RTO 极差：你几乎不丢失任何数据，却要花三天才能重新启动。也可能相反：20 分钟就重新启动，但只能回到上周的那份快照。两者必须放在一起、针对每个系统都说得通。税务 ERP 要求 RPO 和 RTO 都很紧凑。而一个可以从数据源重建的 BI 数据仓库，则能承受更宽松的数字。
3-2-1 法则：能扛住攻击的备份
只有真正有备份可供恢复，RPO 和 RTO 才有意义。至今仍在整理这件事的法则是 3-2-1：
- 数据的 3 份副本（原始的加上另外两份）。
- 2 种不同的介质或技术（不是两份都放在同一块磁盘、同一台服务器上）。
- 1 份异地副本——离线或不可变，勒索软件既够不着也删不掉。
最容易落空的正是那个「1」。放在同一台服务器上、或挂载在网络上的 NAS 里的备份，会在攻击当天连同其余数据一起被加密。现代勒索软件会优先搜索并摧毁备份，正是为了逼你交赎金。因此异地副本必须是不可变的（一次写入、任何人都无法重写）或真正断开连接的。没有这个「1」，整套法则救不了你。
从未被恢复过的备份不算备份
这是事故之后最扎心的一句话。一套每天运行、生成文件、在面板上标记为绿色——却从未被恢复过的备份例程，是一种假设，而不是一种保证。很多人正是在攻击当天才发现文件已损坏、缺了正确的数据库，或者恢复所需的时间是计划的三倍。
备份只有在你真正测试恢复、在一个独立环境中并掐算时间之后，才成其为备份。这项测试用事实而非信心回答：你的 RTO 是否真实，你的 RPO 是否与配置的频率相符。具体建议：每季度做一次有记录的恢复测试，并在系统有重大变动时随时进行。
运输公司的案例：一天都停不起的那一类
运输公司没有「几天」RTO 这种奢侈。没有 ERP，就无法开具 CT-e 和 MDF-e——没有税务单据，卡车出不了场。没有追踪，你就失去车队的位置和在途货物的可见性。停摆的每一小时都会变成 SLA 罚款、延误交付和响个不停的电话。
实践中该如何思考：
- 按关键程度对系统分级。税务开具和追踪（SASCAR、Autotrac、Omnilink）要求以小时计的 RTO 和较低的 RPO。BI 报表则能承受更宽松的。
- 让备份频率与 RPO 相匹配。如果你最多只能接受丢失 1 小时的单据，那么税务数据库的备份就不能是每天一次。
- 一份不可变的异地副本——攻陷 ERP 的勒索软件不能够着它的备份。
- 掐算时间的恢复测试，以确认你是否真能在 4 小时内重新开始开具单据。
目标很简单：让数据被勒索成为几小时的麻烦，而不是几天的停摆——并让支付赎金永远不是桌面上唯一的出路。这是以设计保障隐私与连续性，而非靠打补丁。
常见问题
RPO 和 RTO 有什么区别？
RPO（Recovery Point Objective，恢复点目标）是你能接受丢失多少数据，以时间衡量——它决定备份的频率。RTO（Recovery Time Objective，恢复时间目标）是事故之后你需要在多长时间内恢复运营。RPO 向后看（丢失的数据）；RTO 向前看（停摆的时间）。你需要为每个关键系统都定好这两者。
什么是备份的 3-2-1 法则？
即数据的 3 份副本，存于 2 种不同介质，其中 1 份放在异地——离线或不可变。那个「1」是抵御勒索软件的关键：异地副本必须处于攻击够不着的地方，因为现代勒索软件会在索要赎金之前先搜索并摧毁网络上可访问的备份。
为什么说未经测试的备份不算备份？
因为从未被恢复过的备份只是一种假设。人们往往在事故当天才发现文件已损坏、缺了某个数据库，或者恢复所需的时间是预期的三倍。只有在独立环境中真正做一次掐算时间的恢复测试，才能证明你的 RTO 和 RPO 是真实的。理想的做法是每季度测试一次。
如何为运输公司确定 RPO 和 RTO？
按关键程度对系统分级。税务开具（CT-e、MDF-e）和车队追踪要求以数小时计的 RTO 和较低的 RPO，因为没有单据卡车就出不了场，业务停摆就会变成 SLA 罚款。BI 和报表则能承受更宽松的数字。之后，把备份频率配置得与 RPO 相匹配，并真正测试恢复。
因勒索软件导致业务停摆的代价有多大？
这正是决定 RTO 的那笔账。对一家运输公司来说，停摆的每一小时都意味着延误交付、SLA 罚款、卡车排队却没有税务单据以及无人回应的客户。正是这个每小时的成本，决定了投资更快恢复的必要性——停摆的每小时越贵，RTO 就必须越紧。
支付勒索软件赎金能解决问题吗？
支付既不能保证拿到密钥，也不能保证数据完好地恢复，还会资助下一次攻击。替代方案是拥有不可变且经过测试的备份，让你能在约定的 RTO 和 RPO 内恢复运营，而不必依赖罪犯。在事故发生前就定好这些数字，才能把赎金从桌面上唯一出路的位置上拿掉。