RPO 和 RTO 是什么？备份、主从复制和容灾有什么区别？

知识点详解：能恢复哪些数据，与多久恢复业务，分别判断

先把两个目标画在故障时间线上

假设故障发生在 10:00，系统能够恢复到 9:55 的有效数据。数据可能损失的时间范围是五分钟，这一维度对应 RPO。

如果服务到 10:30 才重新达到约定的可用状态，那么恢复用了三十分钟，这一维度对应 RTO。

两者不是同一根刻度，也不能把“备份每五分钟执行一次”直接等同“任何故障都满足五分钟 RPO”。备份是否完成、是否可读，以及日志缺口，都要检查。

这些目标与方案取舍可以参照 AWS 灾难恢复方案说明，本文不照搬某个云产品的收益数字。

为什么只保留昨晚备份不够？

一份较早的完整备份，只能提供那时的恢复基础。想恢复到更近的时刻，还需要后续可用且完整的日志等数据。

例如 MySQL 的时间点恢复，可以从备份恢复，再应用所需的 binary log，见 MySQL 时间点恢复说明。

但是日志存在，不代表自动达到任意时刻。需要核对连续性、保留范围、停止位置与可用性，不能回放到错误操作之后，再声称避免了误删。

图：基础备份，加后续可用日志。

有副本，为什么仍要备份？

复制有助于提高可用性，并缩短某些故障的切换过程。但主库的误删或错误写入，也可能被复制到副本。

因此，副本与备份保护的是部分不同风险。可用副本不能替代历史恢复点；历史备份也不一定具备快速接管能力。

异步复制还有延迟和故障时未复制数据的可能。所谓“零数据损失”，必须带上故障模型与确认条件，不是勾一个复制选项就成立。

图：副本也会复制误删。

RTO 为什么不能只测数据库启动？

用户还需要应用、配置、认证、缓存、网络路由等依赖。数据库启动了，但应用连到旧地址、权限不可用，业务仍没有恢复。

因此，演练应该从实际约定的故障时刻开始计时，包含发现、决策、恢复、切换和验证。结束点也要明确，比如关键业务路径达到约定成功率与容量，而不是进程刚出现。

时间主要花在哪一步，决定我们该优化数据恢复、自动化切换，还是依赖配置。没有分段记录，就很容易把所有慢都归因于“备份太大”。

图：业务恢复，不止数据库启动。

演练怎样形成可信证据？

在受控环境按选定故障情形恢复，记录可用备份与日志、实际恢复点、各阶段耗时，以及业务核对结果。

检查权限、备份隔离和可用密钥也很重要；不能到了恢复现场才发现文件在、解密或访问条件却不在。

本文的时间是明确的假设示例，没有冒充线上恢复测量。方案越接近零损失、极短恢复，成本与复杂度通常越高，要由业务目标驱动，而不是所有系统都追同一指标。

面试官继续追问

备份校验通过，就证明能恢复吗？

不够。校验可帮助发现文件问题，实际恢复还涉及版本、依赖、日志与业务一致性。需要执行恢复验证。

怎样评估演练成功？

同时看数据恢复范围和业务恢复时间，再检查一致性与容量。只达成其中一项，不能说两个目标都满足。

面试速记卡

• RPO：可接受的数据损失时间范围。
• RTO：可接受的业务恢复时间。
• 备份与日志：基础恢复点加后续可用变化。
• 复制：帮助可用性，不替代历史恢复与误操作保护。
• 证明：恢复演练，核对数据、依赖、耗时与业务验证。