灾难恢复
灾难恢复通过数据副本和恢复流程应对严重故障。本文负责故障域、备份、RTO/RPO 和方案选择。
1. 面试核心
先记住这几条，再读正文2. 高可用
高可用通过冗余和故障转移降低中断。故障域包括主机、可用区和地域。共享数据库、网络、证书与错误配置也会造成共同故障。
两个实例若共用同一交换机，交换机故障会同时影响它们。副本的位置应覆盖目标故障域。软件发布还需要独立的灰度与回退设计。
3. 接管路径
接管方案需要健康判断、状态同步和剩余容量。写入隔离和客户端切流见故障转移。
恢复目标要覆盖依赖和用户入口。只恢复数据库进程，用户仍可能无法完成交易。
4. 备份
复制可把误删和错误更新传播给副本。备份保存历史状态，以恢复逻辑损坏。
备份策略需明确频率、保留期和异地存储。加密密钥、配置与应用镜像也要可恢复。独立账号和访问控制有助于隔离误操作。
备份可用性通过恢复测试验证。测试需在隔离环境检查数据完整性和业务结果。
4.1 时间点恢复
PostgreSQL 18 的 PITR 使用基础备份与 WAL 归档。恢复先加载基础备份，再重放日志到目标时间或位置。所需日志区间必须连续。普通 pg_dump 不能作为 WAL 重放的基础备份。
假设 12:00 故障，最后可恢复位置对应 11:57。恢复点落后 3 分钟。若 12:20 恢复约定业务，恢复耗时是 20 分钟。这两个实测值分别用于核对 RPO 和 RTO。
误删恢复还需定位错误操作之前的位置。恢复后的合法新写入需要另行核对和补录。仅有最新副本无法完成这种历史选择。
5. RPO
RPO 是允许丢失的数据时间窗口。目标为 15 分钟，表示最多接受丢失这段时间的变化。实际丢失量还取决于窗口内的写入量。
只有每日备份而无增量日志时，无法满足分钟级目标。异步复制取决于灾后可用副本的实际位置。同步确认则需同时说明持久性和故障域。
不同数据可有不同目标。账务要求严格核对，推荐缓存可以重建。
6. RTO
RTO 是业务恢复到约定水平的时间目标。它覆盖发现、决策、资源准备和数据恢复。应用启动、验证与切流也计入耗时。
| 方案 | 平时保留的能力 | 恢复时的主要工作 |
|---|---|---|
| 备份恢复 | 历史备份与部署材料 | 创建环境并恢复数据。 |
| Pilot light | 核心数据与少量组件 | 启动应用并扩容。 |
| 温备 | 可运行的缩小环境 | 扩容到接管规模。 |
| 热备或多站点运行 | 完整接管容量 | 切流并验证状态。 |
预置资源越多，持续成本越高。实际耗时还受数据量、依赖与自动化影响。方案名称本身不保证目标。
7. 恢复顺序
恢复顺序来自依赖图。身份、网络和密钥先就绪。数据库、对象存储与消息系统随后恢复。核心写入、查询和非核心任务分批启用。
每一步需有可验证的完成条件。健康探针验证访问路径，数据核对验证业务状态。外部支付和回调也需确认恢复。
8. 恢复演练
演练应从指定备份恢复到空环境。区域失效、密钥缺失和复制落后都应纳入场景。
每次记录实际恢复点与耗时。数据规模或依赖变化后，需要重新测量。完整演练方法见故障转移。
9. 常见问题
9.1 复制与历史备份
复制缩短副本的数据差距。备份允许选择历史恢复点。误删已传播到所有副本时，仍需历史备份或日志恢复。
9.2 双机与故障域
双机的能力取决于它们共享哪些依赖。同地域、同数据库的两台应用实例，只覆盖部分实例故障。地域灾难需要相应的独立恢复资源。
10 · 面试题卡片
10.1 高可用与容灾有什么区别，怎样根据 RTO/RPO 设计方案
出现公司：阿里巴巴
题型：综合题
考察重点
- 冗余、故障域、备份和灾难恢复的范围。
- RTO、RPO 对复制、备份和预置资源的约束。
- 恢复顺序、业务验证和定期演练。
参考回答
高可用降低日常中断，灾难恢复应对严重故障后的恢复。
备份保留历史状态，复制则传播当前变化。二者共同覆盖节点故障和逻辑损坏。
RPO 决定数据恢复点要求，RTO 决定恢复耗时要求。短 RPO 需要更连续的数据保护。短 RTO 需要预置容量与可执行流程。恢复演练应包含依赖、数据和用户路径验证。
10.2 每日全量备份怎样满足分钟级恢复点目标，RTO 又怎样计算？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：连续日志、恢复点与业务恢复时间。
相关内容：时间点恢复。
参考回答
每日基础备份可配合连续日志归档实现分钟级恢复点。
前提是所需日志完整，并已到达可用恢复位置。12:00 故障、最后恢复到 11:57，数据窗口是 3 分钟。12:20 恢复业务则耗时 20 分钟。后者还包含启动、校验与切流。