3. 备份恢复的RPO与RTO设计

在MongoDB容灾体系中，备份策略是否“够用”，不能靠感觉判断，而要用两个可量化指标来约束：RPO（Recovery Point Objective，恢复点目标）和RTO（Recovery Time Objective，恢复时间目标）。它们分别回答两个问题：最多能丢多少数据？最多能停多久？只有把这两个数字先定下来，备份频率、oplog窗口、副本集节点数、跨机房链路、恢复演练频率才有设计依据。

一、指标定义：RPO与RTO到底约束什么

RPO描述的是数据可容忍的丢失时间窗口。若RPO=5分钟，意味着故障发生时，允许丢失最近5分钟内写入的数据。它直接决定备份或复制链路的“数据追平能力”：逻辑备份（mongodump）通常只能做到小时级RPO；oplog增量备份可做到分钟级；而副本集同步复制在多数场景下可把RPO压到秒级甚至接近0。

RTO描述的是业务从故障发生到恢复可用的最长时间。它包含故障发现、决策、切换或恢复、数据校验、业务重连等全部耗时。RTO不是“恢复命令执行时间”，而是端到端的业务中断时长。例如RTO=30分钟，意味着从监控告警到应用重新可写，必须控制在30分钟内。

二、不同故障场景下的目标设定

同一套MongoDB集群，面对不同故障，RPO/RTO目标并不相同。常见场景可分为四类：

• 单节点故障：副本集自动选举，RPO≈0（已确认写入），RTO通常为秒级到1分钟，主要取决于选举超时与驱动重连。
• 主节点所在机房故障：若副本集跨机房部署且多数派可用，RPO仍可接近0，RTO取决于仲裁与选举，通常1～5分钟。
• 逻辑误删/误更新：如误删集合、错误update，RPO取决于最近一次可用备份或oplog回放点，RTO取决于恢复数据量，通常30分钟到数小时。
• 区域级灾难：主数据中心整体不可用，需切换到异地副本或从异地备份重建，RPO可能为分钟级到小时级，RTO通常以小时计。

因此，容灾设计不能只给一个RPO/RTO，而应按场景分级。例如核心交易库可设定：单节点故障RTO≤1分钟、RPO=0；误删恢复RTO≤2小时、RPO≤5分钟；区域灾难RTO≤4小时、RPO≤15分钟。非核心报表库可放宽到RTO≤8小时、RPO≤24小时。

三、从指标到技术手段的映射

RPO主要由“数据复制与备份的粒度”决定。若要求RPO≤5分钟，仅靠每日mongodump无法满足，必须启用oplog增量备份或依赖副本集同步。MongoDB的oplog是一个固定大小的capped collection，记录所有写操作，可用于时间点恢复（PITR）。例如：每日02:00做全量备份，同时持续归档oplog，恢复时可先还原全量备份，再回放oplog到故障前一刻，从而把RPO压缩到分钟级。

RTO则由“恢复路径长度”决定。恢复路径越长，RTO越大。典型路径包括：发现故障→确认恢复点→准备目标实例→还原数据→回放oplog→校验数据→切换应用连接。每一步都可优化：预置恢复实例、自动化恢复脚本、并行校验、DNS/连接串快速切换，都能显著压缩RTO。

四、成本权衡：不是越严格越好

RPO/RTO越严格，成本呈非线性上升。以RPO为例：每日全备成本最低，但RPO=24小时；oplog增量备份可把RPO降到分钟级，但需要额外存储与归档链路；跨机房同步复制可把RPO压到秒级，但需要专线、额外节点和更高运维复杂度。RTO同理：冷备恢复可能数小时，热备切换可到分钟级，多活架构可到秒级，但成本和复杂度成倍增加。

因此，合理做法是按业务分级，而不是全库统一。可参考如下分级示例（示例参数，需按实际业务调整）：

五、落地要点与常见误区

第一，RPO/RTO必须可验证。建议每季度做一次恢复演练，记录实际恢复耗时与丢失数据量，与目标对比。若从未演练，RTO只是纸面数字。第二，注意“已确认写入”与“复制确认”的区别：使用w:1时主节点确认即返回，故障切换可能丢失少量数据；使用w:majority可显著降低丢失风险，但写入延迟上升。第三，oplog大小要足够覆盖最坏恢复窗口，否则回放会因oplog滚动而中断。第四，恢复后必须做数据一致性校验，不能只看进程启动。

总结来说，RPO与RTO是MongoDB容灾设计的“锚点”。先按故障场景定义目标，再选择备份频率、oplog策略、副本集拓扑和切换方式，最后用演练验证并持续调优。目标越严格，成本越高，因此必须与业务价值匹配，做到分级保护、重点保障。