93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
---
|
||
title: "RPO (Recovery Point Objective)"
|
||
tags: [devops, disaster-recovery, sre, reliability, data-protection]
|
||
last_updated: 2026-04-29
|
||
---
|
||
|
||
# RPO (Recovery Point Objective)
|
||
|
||
**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。
|
||
|
||
## Definition
|
||
|
||
> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly
|
||
|
||
RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。
|
||
|
||
## Key Characteristics
|
||
|
||
| 维度 | 说明 |
|
||
|------|------|
|
||
| **衡量对象** | 数据丢失量（Data Loss Amount） |
|
||
| **测量方向** | 从故障时刻向后（Backwards）追溯 |
|
||
| **关注点** | 数据完整性（How Much Data Can Be Lost） |
|
||
|
||
## Example
|
||
|
||
如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则：
|
||
- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失
|
||
- 2:00 到 3:00 之间发生的所有事务都面临丢失风险
|
||
|
||
## RTO vs. RPO
|
||
|
||
RTO 和 RPO 衡量的是不同维度，必须**同时优化**：
|
||
|
||
| 场景 | RTO 目标 | RPO 目标 | 说明 |
|
||
|------|----------|----------|------|
|
||
| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 |
|
||
| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 |
|
||
| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 |
|
||
| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 |
|
||
|
||
**关键**：不能只优化其中一个指标。
|
||
- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效
|
||
- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效
|
||
|
||
## [[Feature Flag]] 对 RPO 的保护
|
||
|
||
传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**：
|
||
|
||
- Feature Flag 切换只改变代码执行路径，不触碰数据层
|
||
- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响
|
||
- RPO 在整个 Feature Flag 操作期间始终保持近零
|
||
|
||
## Tiered RPO Targets
|
||
|
||
| Tier | 场景 | RPO 目标 | 说明 |
|
||
|------|------|----------|------|
|
||
| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 |
|
||
| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 |
|
||
| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 |
|
||
|
||
## 实现手段
|
||
|
||
| 方法 | RPO 效果 | 说明 |
|
||
|------|----------|------|
|
||
| 无备份 | ∞ | 完全不可接受 |
|
||
| 每日备份 | 24 小时 | 成本低，RPO 差 |
|
||
| 每小时备份 | 1 小时 | 中等成本和效果 |
|
||
| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 |
|
||
| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 |
|
||
|
||
## RPO 与 RTO 必须协同
|
||
|
||
最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链：
|
||
|
||
- RTO 短 → 系统快速恢复
|
||
- RPO 小 → 数据损失少
|
||
- Feature Flag → 两者兼得的性价比方案
|
||
|
||
## Related Concepts
|
||
|
||
- [[RTO]] — Recovery Time Objective，停机时间指标
|
||
- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标
|
||
- [[Feature Flag]] — 保护 RPO 的配置级热修复机制
|
||
- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏
|
||
- [[High Availability]] — 高可用性，降低 RPO 的基础设施
|
||
- [[Data-Governance]] — 数据治理，包含 RPO 策略
|
||
## Sources
|
||
|
||
- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]
|
||
- [[ctp-topic-44-aws-backup-in-micro-focus]]
|
||
- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||
- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] |