RPO 是什么
RPO（Recovery Point Objective，恢复点目标）描述业务可容忍的数据丢失时间窗口：RPO 写 15 分钟，表示故障发生时最多可能丢掉最近 15 分钟写入的数据。它由保护手段的实际频率决定，只做每日备份的实例，无论文档怎么写，真实 RPO 都接近 24 小时。RPO 与 RTO 一起构成容灾设计的两条硬约束，前者管数据、后者管时间。
基本信息
| 全称 | Recovery Point Objective（恢复点目标） |
|---|---|
| 本质 | 数据维度的容灾指标，单位是时间 |
| 决定因素 | 备份、日志传送或复制的实际频率 |
| 配套指标 | RTO 描述业务恢复所需时间 |
| 归属 | 业务承诺，而不是某个软件的开关 |
手段与典型数据丢失窗口
| 保护手段 | 典型数据丢失窗口 |
|---|---|
| 每日一次全量备份 | 接近 24 小时 |
| 每 6 小时备份一次 | 接近 6 小时 |
| 每 15 分钟传送增量或日志 | 接近 15 分钟 |
| 异步复制 | 取决于复制延迟，通常秒级至分钟级 |
| 同步复制 | 接近 0（受链路延迟与距离约束） |
RPO 是设计出来的
RPO 不能靠声明获得：写下 RPO=5 分钟却只做每日备份，实际达成的仍然是 24 小时级别。反过来说，追求更小的 RPO 必须付出更高频的日志或增量传输，会占用生产 IO 与链路带宽。合理做法是先由业务方确认可接受的丢失窗口，再反推需要的技术手段与预算。
RPO 分级与手段
| RPO 目标 | 典型手段 | 主要代价 |
|---|---|---|
| 小时级 | 每日或每数小时备份 | 存储与备份窗口占用 |
| 分钟级 | 高频增量、日志持续归档 | 生产 IO 与带宽被挤压 |
| 秒级 | 半同步复制、准同步日志传送 | 写入延迟上升 |
| 接近零 | 同步复制、多副本共识写入 | 链路距离与可用性权衡 |
影响落地的常见因素
- 数据库日志链是否连续：binlog 或 WAL 断档时，名义 RPO 与实际可恢复点会分离
- 备份任务实际耗时：跨窗口未完成的任务会顺延，等于把丢失窗口按天放大
- 复制延迟：异步复制在业务高峰普遍滞后，延迟峰值决定真实丢失窗口
- 异地链路带宽：带宽不足时高频增量传不完，只能退化为降频传输
- 介质与压缩开销：慢介质或高压缩级别会把备份窗口拖长
从备份频率推算 RPO
从备份频率推算 RPO
# 实际 RPO 约等于相邻两次可恢复点的时间间隔
# 每日全量一次 -> 最坏丢失 24 小时
# 每日全量 + 每 15 分钟归档日志 -> 最坏丢失约 15 分钟
# 核对归档连续性，缺失任何一段都会把 RPO 拉长
ls -1 /backup/binlog | wc -l # 与源端已生成的日志数量比对更高等级的 RPO 意味着更高频的传输，需要评估对生产 IO 与链路带宽的挤占；把 RPO 压到秒级前先确认业务是否真的承受不了这些数据。
RPO 与 RTO 要一起评审：只优化数据丢失窗口而忽略恢复耗时，故障时仍会长时间停服，反之亦然。
评审 RPO 要问的问题
- 最近一次可恢复点距今多久：用最近的备份或日志归档时间减去当前时间，才是真实窗口
- 日志或增量是否连续：中间缺一段就意味着只能恢复到断点之前，实际丢失远大于设计值
- 传输是否会被业务高峰挤掉：链路拥塞时高频任务可能超时失败，RPO 在高峰自动退化
- 备份任务失败是否有人知道：无告警的失败会持续数天，直到需要恢复时才被发现
- 成本是否可接受：把丢失窗口从小时级压到分钟级，通常需要成倍的带宽与存储投入