云服务器容灾：RPO/RTO、跨区备份与演练

先说结论：容灾不是“多买一台机器”，而是先定 RPO/RTO，再选备份、冷备、温备还是双活，最后靠演练验证。没有演练的容灾方案，等于没有。大多数业务从“跨区备份 + 可快速重建”做起，比一上来做双活更实际。

两个指标先明确：

RPO：能接受丢多少数据，决定备份频率和复制方式
RTO：能接受停多久，决定冷备、温备还是热备

RPO 是 0，意味着同步复制、双写；RTO 是分钟级，意味着热备或双活。两者都要求高，成本会指数级上升。

容灾的几个层级

层级	做法	RTO	成本
备份	定期备份到站外，故障后重建	小时级	低
冷备	备好机器/镜像，不跑业务	几十分钟	中低
温备	备机运行但不同流量	十几分钟	中
热备	主备同时运行，自动切换	分钟级	高
双活	多中心同时承载流量	秒级到分钟	很高

大多数中小企业做到“跨区备份 + 冷备 + 演练”就够；金融、交易类才需要热备/双活。

RPO 和 RTO 怎么定

从业务损失倒推：停一小时损失多少、丢一小时订单损失多少，再和容灾成本比。别拍脑袋说“必须零丢失”，先看预算和业务真实影响。

RPO 与 RTO 时间线、备份点和恢复箭头 — RPO 决定丢多少数据，RTO 决定停多久。

跨区备份怎么做

数据库每天全量 + binlog/WAL 增量，备份传到另一区域
文件用对象存储跨区复制或 rsync 到备机
镜像/快照跨区复制，确保能快速开新机
配置、证书、密钥单独备份，别只备数据
备份加密，权限最小化

# 示例：数据库备份后传到异地
mysqldump --single-transaction appdb | gzip > appdb.sql.gz
rclone copy appdb.sql.gz remote:backup/db/

数据一致性

异步复制会丢最后一段数据，同步复制会影响性能。按业务选：订单、支付可以接受少量丢失但不能乱序；日志、埋点可以丢。切换前确认备库数据最新，别把旧数据当新数据用。

切换和回切

切换不是改个 DNS 就完事：应用配置、数据库连接、缓存、队列、证书、第三方白名单都要跟着改。回切更难，旧环境恢复后要追平新数据，别急着切回去。

建议把切换步骤写成 runbook，谁执行、多久、怎么验证、失败怎么回滚，都写清楚。

演练

每季度至少一次，覆盖：主机宕机、数据库主从切换、区域故障、备份恢复。演练要记录实际 RTO/RPO，和目标是差多少，下次怎么改。

成本怎么算

容灾成本 = 备机/备区资源 + 跨区流量 + 备份存储 + 演练人力。按业务损失定投入，别为“看起来安全”买一堆闲置资源。

常见误区

有备份就算容灾：没演练、没验证恢复，等于没有
同区域备份：区域故障一起没
只备数据库：配置、证书、密钥丢了照样起不来
双活一定更好：复杂度高，数据冲突更难处理
切换脚本没回滚：切过去发现问题，回不来

同城还是异地

同城容灾延迟低、成本低，但扛不住城市级故障；异地容灾更安全，但延迟和成本高。按业务选：大多数业务先做异地备份，再做同城热备。

云上容灾

云上做容灾，优先用跨区快照、对象存储跨区复制、数据库跨区只读副本；切换时用镜像开新机，DNS 或负载均衡切流。别自己从零搭复制链路。

数据分级

核心交易数据、用户数据、日志、缓存，RPO/RTO 要求不同。分级后把预算花在核心数据上，别给日志做双活。

常见故障场景

主机宕机、磁盘损坏、数据库误删、区域网络故障、人为误操作、勒索软件。每种场景的恢复路径不同，演练要覆盖。

演练清单

演练前定目标、范围和回滚；演练中记录时间线、失败点和人工操作；演练后输出报告和整改项，下次演练验证。

备份保留策略

按“日备 7 天、周备 4 周、月备 12 个月”分层，核心数据可更长；备份文件加密，密钥单独保存。定期抽样恢复，别只看备份成功日志。

加密和权限

备份包含业务数据，权限要最小化；跨区传输走加密通道；离职人员及时回收密钥。备份被偷比服务器被黑更严重。

切换判定

什么情况切、谁拍板、切到哪里，要提前定。小故障先修，大故障才切；切换后先验证核心链路，再放全量流量。

回切

旧环境恢复后，先追平数据再切回；回切前确认新环境写入的数据已经同步，别把用户订单留在旧库。

监控和告警

备份失败、复制延迟、证书到期、磁盘满、区域异常都要告警。容灾最怕“以为在跑，其实早就断了”。

文档

架构图、备份清单、切换 runbook、联系人、回滚步骤放在团队能拿到的地方，别只存在某个人脑子里。

演练频率

至少每季度一次，核心系统每月抽查备份恢复；每次故障后补一次针对性演练。

预算有限怎么做

先做跨区备份 + 可重建脚本 + 季度演练，这三件成本最低、收益最大；等业务损失变大，再加热备和自动切换。

别过度设计

小站做双活，复杂度可能比故障本身更伤业务。按 RPO/RTO 和预算选层级，够用就好。

最后，容灾方案要跟着架构变，每次大改后重新评估 RPO/RTO 和演练结果。

容灾是长期习惯，不是一次性项目，定期复盘比买设备更重要。

把容灾纳入发布流程，每次上线都顺手检查备份和回滚。

这比出事时临时找备份靠谱得多。

平时多流汗，故障时少流血，这一点很重要啊。

常见问题 FAQ

Q1：小公司需要容灾吗？

需要最低限度的：跨区备份 + 可重建 + 演练。不用一上来做双活，但别把唯一副本放在一台机器上。

Q2：备份和容灾有什么区别？

备份解决“数据丢了能恢复”，容灾解决“业务停了能继续”。备份是容灾的一部分，不等于容灾。

Q3：RTO 一般能做到多少？

备份重建小时级，冷备几十分钟，热备分钟级，双活秒级到分钟。取决于架构和投入。

Q4：跨区备份要注意什么？

合规、流量费、加密、恢复速度。跨境还要看数据能不能出境。

Q5：多久演练一次？

至少每季度，业务大促前再加一次。演练不通过，方案就不算完成。

总结

容灾先定 RPO/RTO，再选层级；备份跨区、配置一起备；切换和回切都要有 runbook；最后靠演练验证。别把“买了备机”当成容灾完成。