RPO（恢复点目标）
RPO（Recovery Point Objective）指业务系统在灾难发生后可容忍的数据丢失量，通常以时间为单位衡量。例如，RPO为1小时表示系统最多允许丢失1小时内产生的数据。RPO直接影响备份频率，较短的RPO要求更频繁的数据备份或同步。
- 关键影响因素：数据写入频率、备份技术（如快照、异步/同步复制）、存储性能。
- 典型场景：金融交易系统通常要求RPO接近0，而日志分析系统可能允许数小时的RPO。
RTO（恢复时间目标）
RTO（Recovery Time Objective）指灾难发生后，业务系统恢复到可接受状态所需的最大时间。例如，RTO为4小时表示系统需在4小时内恢复服务。RTO决定了灾难恢复流程的紧急程度和资源投入。
- 关键影响因素：故障检测速度、恢复流程自动化程度、备用基础设施准备情况。
- 典型场景：电商大促期间可能要求RTO分钟级，而内部办公系统可能接受天级RTO。
RPO与RTO的关系
- 协同性：两者共同构成容灾能力指标，但优化方向可能冲突。例如，追求RPO=0可能需要牺牲RTO（如同步复制增加延迟）。
- 权衡决策：需根据业务优先级分配资源。高RPO/RTO要求的系统通常需要更高成本（如异地多活架构）。
技术实现方案
低RPO方案
- 数据库日志实时同步（如MySQL Binlog复制）
- 存储级同步镜像（如SAN阵列远程复制）
低RTO方案
- 热备站点自动切换（如AWS Multi-AZ）
- 容器化应用快速重建（Kubernetes集群故障转移）
公式示例：
数据丢失风险窗口 ( W = \text{实际RPO} - \text{设计RPO} )
当 ( W > 0 ) 时需调整备份策略。