容灾与两个指标
RTO 是故障后恢复服务的目标时长，RPO 是可接受的数据丢失时间窗。两者共同决定容灾形态与成本量级：从定期备份恢复到双活热备，成本可能相差一个数量级。目标必须与业务价值匹配，为低价值业务配置热备是纯粹的浪费。
为什么必须演练
RTO 与 RPO 是结果指标而不是设计指标。写了容灾方案不等于能恢复：备份文件可能损坏、恢复脚本可能依赖故障区域内的资源、切换后的容量可能不足以承接全量流量。只有定期恢复演练与切换演练，才能把这些链路盲区暴露在真正的灾难之前。
容灾等级
| 等级 | 典型形态 | RTO 与 RPO 量级 |
|---|---|---|
| 备份恢复 | 定期备份，故障后重建 | 小时级，小时级 |
| 冷备 | 备环境不常开，拉起较慢 | 数十分钟起，分钟级 |
| 温备 | 备用环境运行，数据持续同步 | 分钟级，秒级 |
| 热备 | 两侧同时承载并互备 | 秒级或更低，秒级 |
基本信息
| RTO | 恢复服务的目标时长 |
|---|---|
| RPO | 可接受的数据丢失时间窗 |
| 验证方式 | 定期恢复演练与切换演练 |
| 常见误区 | 把备份存在同地域当作容灾 |
典型使用场景
- 核心交易系统：按业务影响确定容灾等级
- 合规要求：灾备等级需要留档与定期验证
- 机房迁移：切换窗口与数据同步策略一并规划
- 云区域故障预案：明确切流决策与回退条件
- 数据误删恢复：依靠备份与日志实现时间点恢复
目标怎么定
先给业务分类，再给指标，而不是反过来。同一系统里，交易写入可能需要接近零的数据丢失，而报表数据允许小时级缺失。按业务单元分别设定 RTO 与 RPO，才能把钱花在真正重要的链路上，也才能避免一个笼统指标迫使整套系统都按最高等级建设。
RTO 与 RPO 目标要用演练验证：写了方案不等于能恢复，定期切换演练才能暴露链路盲区，也才能发现预案中过时的联系人、密钥与依赖。