云灾备解决方案：保障业务连续性的最后一道防线

灾备方案值不值，只用两个数字衡量：RTO（多久能恢复） 和 RPO（能容忍丢多少数据）。除此之外的架构名词——双活、两地三中心、冷热备——都只是实现这两个数字的手段。

先算清楚停机一小时值多少钱

把这张表算出来，才知道该投多少钱做灾备。很多团队直接上"两地三中心"，结果一年灾备成本超过十年停机损失的总和。

可用性与年停机时间对照

每提升一个 9，成本通常翻倍甚至更高。先确定业务真正需要几个 9，再选架构。

四档灾备，成本差 10 倍

多数业务落在"温备"就够：花 2–3 倍成本，把 RTO 从 4 小时压到 30 分钟，性价比最高。

备份要遵守 3-2-1 原则

• 3 份数据（生产 + 两份备份）
• 2 种介质（如云盘 + 对象存储）
• 1 份异地（不同地域，最好离线不可改）

勒索软件的第一目标就是备份。如果备份和主库在同一个账号、同一块存储上，等于没有备份。建议对关键备份开启对象锁 / 版本控制，防止被批量删除。

真正决定成败的是演练

方案写得再完整，没演练过就只是文档。建议：

• 每季度做一次恢复演练，抽一个真实业务系统，从备份完整恢复到可访问
• 记录实际 RTO，与设计值对比，差距超过 2 倍就要复盘
• 演练要包含"人"的环节：谁通知、谁决策、谁执行，凌晨 3 点能不能找到人
• 演练结果写入变更记录，作为下次整改依据

经验上，第一次演练的实测 RTO 通常是设计值的 2–5 倍，因为总会漏掉 DNS 切换、证书、依赖的外部服务这些细节。

五个常见错误

1. 只备份数据库，不备份配置：恢复了数据，但 nginx、证书、环境变量全丢了
2. 备份在同一个可用区：机房级故障时一起没
3. 没验证过备份可读：备份文件损坏在恢复当天才发现
4. 把容灾当成高可用：高可用解决单机故障，容灾解决地域级故障，两件事
5. 切换没有回滚路径：切过去发现新环境有问题，切不回来

什么时候不需要灾备

个人项目、内部工具、可重建的测试环境——备份 + 文档化的重建步骤就够了。灾备投入应该与业务中断损失成正比，而不是与公司规模成正比。

如果你正在做的是"选云 + 控成本"而不是"建灾备"，可以先用 云服务器比价 拉出各家的多可用区价格差，再判断同城双活的溢价是否在预算内。