Auto-sync: 2026-04-16 17:30

wiki/concepts/RPO.md

@@ -1,36 +1,32 @@
 ---
-title: "RPO"
+title: "RPO (Recovery Point Objective)"
 type: concept
-tags: [DevOps, SRE, 灾难恢复]
-last_updated: 2026-04-16
+tags: [灾难恢复, 数据保护, 指标]
+sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
+last_updated: 2025-07-26
 ---
 
-## 定义
-Recovery Point Objective（恢复点目标）：可接受的最新数据丢失量，以时间衡量（从故障时刻往前回溯）。
+## Definition
+RPO（Recovery Point Objective，恢复点目标）是指可接受的最大数据丢失量，以时间度量。从最后一次有效备份到故障发生所经历的时间。
 
-## 计算方式
-若数据库在 15:00 崩溃，最后一次备份在 14:00，则 RPO 为 1 小时（14:00-15:00 之间的数据丢失）。
+## Key Characteristics
+- 衡量数据保护程度
+- 从故障时刻向后计算（倒计时）
+- 与备份频率直接相关
+- 需要与 RTO 共同规划，不能只优化其中一个
 
-## 典型场景与目标
-| 场景 | RPO 目标 | 原因 |
-|------|---------|------|
-| 电商支付系统 | 0 分钟 | 不能丢失任何交易数据 |
-| 实时聊天 | 5 分钟 | 可接受丢失最近几分钟消息 |
-| 用户分析仪表盘 | 1 小时 | 部分历史数据可重建 |
-| 内部 CRM | 15 分钟 | 最近的客户更新很重要 |
-| 博客/营销站点 | 24 小时 | 一天的评论/注册丢失可接受 |
+## Tiered RPO Targets (from this source)
+| Tier | Examples | RPO Target |
+|------|----------|------------|
+| Critical | Payment processing, user auth | < 1 minute |
+| Important | Admin dashboards, reporting | < 15 minutes |
+| Nice-to-have | Internal tools, dev environments | < 1 hour |
 
-## 与 RTO 的关系
-- RTO 是速度指标（停机多久），RPO 是数据完整性指标（丢多少数据）
-- 备份频率（CDP vs 定时备份）直接影响 RPO
-- 即使 RTO 优秀（5分钟恢复），RPO 差（1小时前备份）仍意味着大量数据丢失
-
-## 实现技术
-- [[连续数据保护]]（CDP）：持续备份，实现分钟级甚至秒级 RPO
-- 同步复制：零 RPO，但成本高
-- 异步复制：有延迟，通常分钟级 RPO
+## Example
+如果数据库在下午3点崩溃，而最后一次备份是下午2点，则 RPO 为1小时。2点到3点之间的所有数据丢失。
 
 ## Connections
-- [[RTO]] ← 协同指标，共同构成灾难恢复策略
-- [[灾难恢复]] ← RPO 是其核心衡量指标
-- [[连续数据保护]] ← 实现更小 RPO 的技术手段
+- [[RTO (Recovery Time Objective)]] ← 配对指标 → [[RPO (Recovery Point Objective)]]
+- [[灾难恢复]] ← 应用领域 → [[RPO (Recovery Point Objective)]]
+- [[持续交付]] ← 现代上下文 → [[RPO (Recovery Point Objective)]]
+- [[Feature Flag]] ← 保护工具 → [[RPO (Recovery Point Objective)]]