RPO 和 RTO 是什么？如何影响容灾设计？
简化版
RPO 是灾难后允许丢失多少时间范围的数据，RTO 是从中断到业务恢复可接受多长时间。 RPO 决定复制与备份频率，RTO 决定备用资源、自动切换和恢复流程；两者必须按业务链路定义并通过恢复演练验证，不能只写在 SLA 文档里。
详细版
若要求 RPO≤5min，异地副本或增量备份必须把暴露窗口控制在 5 分钟内；RTO≤30min 则检测、决策、基础设施启动、数据恢复、切流和验证的总和不能超过 30 分钟。同步复制可降低 RPO，但增加延迟和分区时不可用风险；冷备成本低，却很难实现分钟级 RTO。
不同数据应分层：账务可能 RPO 接近 0、RTO 15 分钟，报表可 RPO 24 小时、RTO 4 小时。还要区分“服务页面可打开”和“核心交易完整恢复”，并定义降级恢复点。最终用灾备演练测实际数据缺口和全过程耗时。
完整版教学
一、两个目标分别约束什么
RPO（Recovery Point Objective）回答最多回到哪个数据时间点，关注数据损失；RTO（Recovery Time Objective）回答事故后多久恢复到约定服务水平，关注停机时间。它们是业务容忍度，不是某款存储产品自动提供的参数。
记忆钩子：RPO 看时间轴向后退多远，RTO 看故障后向前等多久。
二、用时间线理解
09:55 最后可恢复点 ---- 10:00 灾难发生 -------- 10:20 核心业务恢复
|<-- RPO 5min -->|<------- RTO 20min ------>|若 09:58 的订单已对用户成功，但恢复点只有 09:55，就需要对账或外部流水补回，不能假装 RPO 只是技术指标。恢复到 10:20 也要说明哪些能力可用，而非只有进程启动。
三、RPO 如何改变数据方案
| 目标 | 常见方案 | 主要代价 |
|---|---|---|
| 接近 0 | 同步/多数派复制 | 写延迟、分区可用性 |
| 分钟级 | 异步日志复制 | 存在复制 lag |
| 小时级 | 周期快照+增量 | 恢复需重放 |
| 天级 | 每日备份 | 数据缺口大 |
复制提高可用性但会同步软件错误和误删，独立备份仍不可少。RPO 还要覆盖元数据、配置和密钥，不只是主数据库。
四、RTO 是各阶段预算之和
RTO = 发现 + 确认 + 资源准备 + 数据恢复 + 切流 + 业务验证
= 2 + 3 + 5 + 6 + 2 + 2 = 20min只宣传“数据库 30 秒提升”会漏掉 DNS 缓存、应用连接、密钥、缓存预热和人工审批。要为每阶段分配预算，超过预算的步骤才是优化重点。
五、恢复层级和业务分级
同一系统可定义三级恢复：5 分钟内提供只读订单查询，20 分钟恢复下单，60 分钟恢复推荐和报表。这样能让核心 RTO 小于全功能 RTO，也指导容量和 Runbook 优先级。每项恢复都要有可测试的入口和数据正确性标准。
假设全量热备年成本 100 万，而关键交易只占 20% 数据，可只给交易域配置热备，其余使用温备或冷备。容灾设计是在损失期望与成本之间做显式取舍。
六、演练与实际值
备份成功不等于可恢复。演练要在隔离环境从备份恢复、校验 checksum 和业务行数、启动依赖、切入测试流量，并记录真实 RPO/RTO。若目标 30 分钟而演练用了 52 分钟，就应按 52 分钟管理风险，不能继续声称达标。
监控包括复制 lag、最近可恢复点、备份年龄、恢复吞吐、Runbook 阶段耗时和演练频率。恢复点还需防勒索和误删，采用跨账号、不可变保留和最小权限。
七、常见误区与追问
- 误区：RPO=0 就绝对不会丢数据。 仍需明确确认边界、共同故障和软件错误。
- 误区：有三副本就不需要备份。 副本会同步误删与逻辑损坏。
- 误区：RTO 只算数据库启动时间。 全链路依赖、切流与验证都属于恢复时间。
- 误区：所有业务使用同一 RPO/RTO。 会导致非核心成本过高或核心保护不足。
- 追问：同步复制能否同时做到低 RPO 和高可用？ 网络分区时必须在拒写和双写风险间选择。
- 追问：怎样证明 RPO 达标？ 对比灾难时最新确认写与恢复后最高业务位点。
- 追问：怎样降低 RTO？ 预置资源、自动化流程、并行恢复并反复演练最慢步骤。
八、加强记忆
RPO 决定数据保护强度，RTO 决定恢复准备程度。答题时画出故障时间线，再把 RTO 拆成发现、恢复、切流和验证，把 RPO 落到复制水位与恢复点。最后强调分级目标、独立备份和实战演练，指标才不是纸面承诺。