2024年11月那天下午三点，我接到一个客户电话。他们的电商系统在杭州的机房，上午十点机房市电中断，UPS撑了四十分钟后整机断电。等运维到现场把机器拉起来的时候，主库的数据文件只恢复到了前一天晚上，差了大半天。用户订单、支付流水、库存扣减，全部对不上。这一停机就是四个多小时，客户第一句话不是问数据能不能找回来，而是问我们：这东西当时有没有做容灾？我查了一遍配置才发现，备份脚本确实每天在跑，但备份的数据一直躺在同一台机器的同一块盘上。机器不通电，备份跟着一起不通电。
这件事之后我花了很长时间在研究"容灾"这件事到底该怎么定级。市面上讲容灾的资料里，最常出现的两个词就是 RPO 和 RTO。这两个词看起来像缩写、像术语，很多人一看到就直接跳过去了。但说实话，这两个数字基本决定了你该花多少钱、该买几台机器、该把数据放在多远的地方。也是从那之后，我自己的运维规范里多了一条硬规定：任何上线方案在讨论服务器配置之前，必须先把 RPO 和 RTO 写出来，写不出来就不准谈架构。
如果你正在给自己的业务做容灾规划，或者手上有一堆方案文档想判断够不够用，这两家可以先看看：狗云DOGYUN（高性价比云服务器，机型齐全，适合多机房部署灾备节点）、RackNerd（全球 VPS 机房分布广，异地容灾节点铺起来方便）。机器是容灾方案的地基，先把节点位置选对，后面的同步策略才谈得上。
一、RPO 管的是"数据丢了多少"，RTO 管的是"多久能起来"
RPO 全称 Recovery Point Objective，恢复点目标。它回答的是一个数据量的问题：如果现在机房断了，我最多能接受丢失多少数据？RPO = 15 分钟，意味着最坏情况下，业务可以承受回退到 15 分钟前的状态；RPO = 4 小时，意味着你必须接受丢掉 4 小时内的数据。
RTO 全称 Recovery Time Objective，恢复时间目标。它回答的是一个时间的问题：从故障发生到业务重新对外提供服务，最多允许多长时间？RTO = 1 小时，是说一小时内必须把服务拉起来并且数据是完整的。
这两个指标有个特别容易被忽略的关系：RPO 决定了 RTO 的下限，RTO 又反过来推着 RPO 变小。想象一下，如果你的 RPO 是 4 小时，那么机房断电后，你要先花 4 小时把数据回放到断电前的状态，再花时间把服务拉起来这还没算排查故障和切流量的时间。RTO 报出来是 5 小时，而你的业务方当初承诺客户的是 1 小时，这中间 4 小时的差就是从天上掉下来的。很多方案翻车就翻在这里：数据备份做了，同步策略也做了，但没人算过"回放 + 启动"这个总账。
二、容灾等级其实是拿钱换来的
业内一般按 RPO 和 RTO 把容灾分成几个等级。我按自己的理解重新梳理了一遍，大概是这样对应的：
单点备份、备份在本地RPO 24 小时、RTO 数小时甚至一天。成本几乎为零，但它只防"误删数据"这种软故障，机器整机挂掉就一起没了。这基本等于没有容灾，只能叫备份。
本地有备份、备份异地存放RPO 收敛到几小时，RTO 几小时。成本很低，一个异地对象存储桶或者另一台便宜机器就能实现。这是绝大多数中小站点的合理起点。
实时同步复制、异地热备RPO 接近 0（几秒级），RTO 几十分钟。成本明显上来了，因为你得为故障时那台闲置的备用节点长期付钱，还要维护复制链路。
异地双活两边同时在跑，流量可以随时切过去。RPO 接近 0，RTO 几分钟。成本是所有级别里最高的，通常还要配仲裁节点、防脑裂机制、真的一致性协议。这一层一般只有交易规模到了某个量级才划得来。
要注意的是，等级不是越高越好。双活听起来很美，但它的复杂度会吃掉大量人力。我见过不少团队上了双活之后，白天根本不敢动配置，因为一改就可能引发脑裂，最后大家干脆把备用节点当生产节点用，反而更乱。定级之前先问自己一个问题：如果这次故障的处理时间从 30 分钟变成 3 小时，业务真的会出乱子吗？如果答案是不会，那 RPO 从 0 放到 24 小时，省下来的钱可能比省下来的精力更值钱。
三、我的三条落地经验
第一，RPO 和 RTO 必须由业务方签字，运维不能自己拍。这两个数字说白了是业务损失的换算。技术团队心里容易有一种"越严越好"的执念，但真正该问的是：丢 5 分钟的订单数据，损失是多少？如果这笔损失是每月几千块，那为它常备一台机器的钱就不值。定级的时候把损失换算成钱写在文档上，很多争论会瞬间结束。
第二，备份和容灾是两件事，"备份跑成功"不等于"能恢复"。这是我踩过最贵的一个坑。脚本每天 0 点跑，退出码是 0，日志里写着"备份完成"，但真到恢复的时候才发现备份文件是空的磁盘当时已经满了，脚本写了个空文件并且正常退出。备份必须做验证：定期从备份里随机抽一个文件恢复出来跑一遍，而不是只看脚本退出码。我现在的规矩是每月自动做一次完整恢复演练,恢复不了就直接告警。
第三,灾备节点要选在真正远的地方，而不是同一栋楼的另一层。同一机房的两台机器共享同一路市电、同一个空调、同一批运维人员,遇上一次区域故障就是一起完蛋。异地才有意义。我一般至少跨一个城市,如果业务更核心就跨一个省份。另外要注意同步链路的带宽成本RPO 越接近 0,意味着每秒都要传增量数据,这部分流量费是实打实的,算方案时别漏掉。
回头看 2024 年那次四小时停机,真正的问题并不是我们没做备份,而是我们从头到尾就没有一个明确的"我们能接受丢多少数据、停多久"的说法。RPO 和 RTO 这两个数字,本质上是一份承诺,而不是一句口号。它一旦写下来,就意味着有人认了这条线,后面的架构设计、同步策略、成本预算,全都有了统一的评判标准。容灾这件事说难不难,难的不是技术,是先把自己的业务损失算明白。
喜欢 
顶
难过
囧
围观
无聊
