灾难恢复（DR）：RTO/RPO 定义、冷备/热备/双活架构
灾难恢复（DR）：RTO/RPO 定义、冷备/热备/双活架构
一、RTO 与 RPO 定义
- RTO（Recovery Time Objective，恢复时间目标）
指系统在灾难发生后，允许的最长不可用时间。- 举例：RTO = 2 小时 → 系统必须在 2 小时内恢复上线。
- RPO（Recovery Point Objective，恢复点目标）
指系统在灾难发生后，允许的数据丢失时间范围。- 举例：RPO = 5 分钟 → 最多只能丢失 5 分钟内的数据 知乎专栏 华为云。
👉 RTO 决定恢复速度，RPO 决定数据完整性。两者共同决定容灾架构的设计与投入。
二、常见容灾架构模式
| 架构模式 | 定义 | RTO | RPO | 成本 | 典型场景 |
|---|---|---|---|---|---|
| 冷备（Cold Standby） | 仅做数据备份，无备用系统运行，灾难后需人工恢复环境 | 数小时～数天 | 数小时以上 | 低 | 历史归档、非核心业务 |
| 热备（Hot Standby） | 备用系统实时同步，可随时接管 | 分钟级 | 秒级甚至 0 | 高 | 金融交易、电商支付 |
| 双活（Active-Active） | 两地机房同时对外提供服务，实时同步，互为主备 | 秒级 | 接近 0 | 极高 | 核心金融、电信、跨区域业务 |
注：冷备强调“低成本+长恢复”，热备强调“快速切换”，双活则追求“零中断、零丢失”，但投入最大 oneprocloud.com.cn。
三、架构选择的思考维度
- 业务重要性
- 核心交易系统 → 双活/热备
- 内部办公系统 → 冷备/温备
- 预算投入
- 冷备成本最低，但恢复慢
- 双活需高昂带宽、存储与同步机制
- 合规与 SLA 要求
- 金融、医疗、电信等行业往往要求 RTO < 1 小时，RPO ≈ 0
- 政府或制造业 ERP 系统可接受 RTO 数小时，RPO 分钟级
四、总结
- RTO/RPO 是容灾设计的核心指标，决定了恢复速度与数据完整性。
- 冷备 → 热备 → 双活，体现了从低成本到高可用的演进路径。
- 企业应结合 业务关键性、预算、合规要求，选择合适的 DR 策略，而非盲目追求“双活”。