灾难恢复流程

灾难恢复（Disaster Recovery，DR）与“日常恢复”的区别在于场景的破坏性与不确定性。日常恢复有明确的起点：手里有一份已验证的备份，知道要恢复到哪个时刻，按流程操作即可。灾难恢复则往往从“系统已经不可用”开始，此时可能连发生了什么都不完全清楚，而业务方的催促已经在进行中。

这一页要解决的核心问题是：在压力之下，如何把恢复这件事变成一套可执行、可交接、可追溯的流程。一个常见的反直觉结论是：灾难恢复中最难的不是技术，而是决策——要不要切换、恢复到哪个时刻、由谁来批准。技术动作可以在演练中练熟，决策框架则必须在事前约定好，否则事故现场会在讨论中耗尽 RTO。

本页的组织顺序是：先定义“什么算灾难”与分级，再讲恢复流程的各个阶段，然后是角色分工与沟通机制，最后给出可落地的检查清单与演练衔接。

前置知识

建议先阅读：备份策略设计

基础概念

什么算灾难

严格说，凡是不属于“常规运维操作”、需要启动应急流程的事件，都可以纳入灾难范畴。按影响范围可以粗略分为：

级别	现象	典型原因
单点故障	某个进程/连接异常，业务基本正常	会话被杀、锁等待、临时空间不足
实例不可用	数据库实例无法提供服务	主进程崩溃、磁盘写满导致 PANIC、配置错误导致起不来
数据损坏或误删	数据被错误修改或删除，实例可能仍可用	误执行 DROP/DELETE、应用 bug 写坏数据
机房级故障	整个机房不可用	断电、火灾、网络割接失败、洪水
区域性灾难	多机房同时受影响	地震、大范围停网、区域级云服务故障

不同级别对应不同的响应路径：单点故障走常规运维；实例不可用可能要提升备库；数据误删通常走 PITR；机房级故障必须依赖异地资源。

RPO 与 RTO 在灾难场景下的含义

在灾难场景里，RPO/RTO 是决策的标尺，不只是指标：

RPO 决定“能恢复到哪一刻”，进而决定选择哪份备份、是否接受数据损失。
RTO 决定“允许多久”，进而决定是原地恢复、切备库，还是异地重建。

举例：如果 RPO 是 5 分钟、RTO 是 30 分钟，那么“从 2TB 备份原地恢复到 3 小时前”这个方案直接不满足要求——它既超过了 RPO（丢 3 小时），也超过了 RTO（要 3 小时以上）。此时唯一可能达标的路径是提升已有备库。

灾难恢复与备份的关系

备份是灾难恢复的必要不充分条件。恢复还需要：

可用的恢复环境（主机、存储、网络）。
恢复所需的 WAL 归档（用于 PITR）。
恢复脚本、配置片段与操作手册。
有权执行、能执行的人。
决策与批准机制。

缺少任何一项，备份就只是“躺在存储上的文件”。这也是为什么灾难恢复流程通常独立成章：它关注的是把“备份”转化为“可用服务”的全过程，而不只是备份本身。

恢复点与恢复时间

概念	含义
恢复点（recovery point）	恢复到的那一刻，对应 RPO
恢复时间（recovery time）	从启动恢复流程到服务可用的时长，对应 RTO
数据丢失量	恢复点与故障时刻之间的数据差

这三者之间存在约束：想缩短数据丢失量，就要更频繁的归档与更强的同步复制；想缩短恢复时间，就要更近的备份、更快的存储，或现成的备用实例。

故障发现与故障确认

灾难恢复流程的起点是“发现异常”。但“告警”不等于“故障确认”。常见的误报来源：

监控探针自身网络抖动。
单条 SQL 慢导致健康检查超时，但实例整体正常。
从库延迟被误判为主库故障。

因此流程中应当有故障确认环节：用独立的第二条路径（例如直接连库、从另一台机器探测、查看日志）确认实例确实不可用，再启动恢复流程。跳过这一步的代价是可能在不必要的情况下切换，带来额外风险。

恢复决策的三条路径

大多数灾难场景最终落到三条路径之一：

路径	适用	优点	风险
原地恢复	实例数据损坏，主机可用	不涉及切换，架构不变	恢复期间停机时间长
提升备库	主库不可用，备库健康	RTO 最短	可能有数据丢失（异步复制）
异地重建	机房整体不可用	应对区域级灾难	RTO 最长，依赖异地资源

选择哪条路径，取决于故障类型、备库状态、数据丢失容忍度与业务优先级。

一次 PITR 与灾难恢复的区别

PITR（基础备份 + WAL 归档回放）是技术手段，灾难恢复是管理过程。前者回答“怎么把数据退回去”，后者回答“谁在什么时候做什么决定、如何验证、如何对外沟通”。把两者混为一谈，会导致演练只练了技术动作，却没有练决策与协作。

恢复的时间构成

理解 RTO 的构成有助于找出瓶颈：

text

总恢复时间 =
    故障发现时间
  + 故障确认时间
  + 决策与批准时间
  + 环境准备时间
  + 数据搬运时间
  + 基础备份重放时间
  + WAL 重放时间
  + 数据验证时间
  + 流量切换时间

其中“发现 + 确认 + 决策 + 准备 + 验证 + 切换”这些非技术环节，往往比“数据重放”占比更大。优化 RTO 时如果只盯着数据库，容易事倍功半。

语法与用法

判断实例是否在恢复中

sql

SELECT pg_is_in_recovery();

返回 true 表示当前还在恢复（例如是一个备库或正在 PITR 的实例）。

查看重放进度

sql

SELECT pg_last_wal_replay_lsn() AS replay_lsn,
       pg_last_xact_replay_timestamp() AS replay_ts;

replay_ts 表示已重放到的事务时间戳，是判断“还差多少”的最直观指标。

检查恢复是否完成

sql

SELECT pg_is_in_recovery(),
       pg_last_wal_replay_lsn(),
       pg_last_xact_replay_timestamp();

当 pg_is_in_recovery() 变为 false，说明恢复已完成或已提升为主库。

手工提升备库

bash

pg_ctl promote -D /var/lib/pgsql/data

或在 SQL 中：

sql

SELECT pg_promote();

查看是否已有实例监听目标端口

bash

pg_isready -h 127.0.0.1 -p 5432

用于确认实例是否已经可以接受连接。

查看备份与归档的关键状态

sql

SELECT archived_count, failed_count, last_archived_wal, last_archived_time
FROM pg_stat_archiver;

在决定“恢复到哪一刻”之前，先确认归档到哪一段。

记录恢复起点

sql

SELECT now() AS recovery_started_at,
       pg_current_wal_lsn() AS lsn_before_stop;

在停止实例前记录当前 LSN，可以为后续“到底丢了多少”提供依据。

详细说明

阶段一：发现与确认

这一阶段的目标是在最短时间内把误报排除掉，并对故障做出定性判断。动作包括：

由监控告警或人工报告触发。
用独立路径确认实例状态（直接连接、pg_isready、查看操作系统进程与日志）。
确认影响范围（是单库、单实例，还是整个机房）。
初步判断故障类型（硬件、软件、人为误操作、网络）。

这一阶段的产出是：故障确认 + 初步定性。应当记录时间点，作为后续复盘与 RTO 计算的依据。

一个实用建议是：不要在看不清状况时就开始恢复操作。数据误删场景中，如果实例仍然可用，最优先的动作是阻止进一步写入（例如撤销相关应用的写权限、或把表设为只读），而不是立即开始恢复。这能显著提升后续恢复的精确度。

阶段二：止损

在确认故障后、开始恢复前，先做“止损”：

若实例仍在运行且有损坏风险 → 停止实例，防止损坏扩大。
若磁盘写满 → 立即清理或扩容，否则无法启动。
若误操作来自应用 → 停掉相关写入路径。
若怀疑硬件故障 → 标记该硬件，避免复用。
若怀疑安全事件 → 保留现场、按安全事件流程处理（不要直接恢复，可能破坏证据）。

不要跳过止损。在磁盘持续写满、或应用持续写坏数据的情况下开始恢复，会得到一个“恢复完又被破坏”的结果。

阶段三：评估与决策

这一阶段决定走向，也是最需要事前约定的部分。需要回答：

数据丢失容忍度：业务能接受回到哪一刻？这要与业务方确认，而不是技术单方面决定。
可用资源：有没有健康的备库？有没有可用的备用主机？异地资源是否就绪？
哪份备份：最近一份已校验的备份是哪一份？
WAL 是否足够：从该备份到目标时刻的 WAL 是否齐全？
走哪条路径：原地恢复 / 提升备库 / 异地重建？
谁批准：谁有权决定切换、决定接受数据丢失？

其中第 6 点最容易被忽略。没有事前约定的授权机制，事故现场会出现“大家都觉得该切，但没人敢拍板”的僵局。

阶段四：环境准备

在正式开始恢复前，把环境准备好：

准备数据目录，确认容量足够（需要容纳备份内容 + 恢复后的实例）。
准备配置：postgresql.conf 中的恢复参数、pg_hba.conf、表空间路径映射。
准备权限：操作系统账号、目录属主（通常需要 0700 权限）。
准备 WAL 来源：归档目录可达，或 restore_command 指向正确位置。
记录起点时间，便于后续统计 RTO。

如果使用原地恢复，还应先备份当前数据目录（哪怕它已经损坏）。原因有二：一是万一恢复方案选错，还能回头；二是事后分析可能依赖现场。

阶段五：执行恢复

执行阶段的关键是“按已演练过的脚本走”。典型顺序：

停止实例（若尚未停止）。
清空或移走目标数据目录的内容（保留 postgresql.conf 等配置视方案而定）。
恢复基础备份的内容到数据目录。
配置恢复参数并创建 recovery.signal。
启动实例，观察日志确认恢复开始。
监控重放进度（pg_last_xact_replay_timestamp()）。
到达目标后由 recovery_target_action 决定行为（暂停、提升或关闭）。

关于第 3 步与第 4 步的顺序，有一个容易出错的细节：备份中的配置可能覆盖你的恢复配置。因此更稳妥的做法是先把备份内容放好，再追加恢复参数，避免被覆盖。

阶段六：验证

恢复完成后必须验证，且验证要覆盖多个层面：

层面	检查内容
服务可用	能启动、能接受连接、无致命日志错误
结构完整	数据库列表、关键表、索引、约束存在
数据正确	行数、关键业务口径、时间戳范围合理
一致性	外键约束、复制状态、序列当前值合理
应用可用	应用能连上并完成核心流程（在只读或隔离环境先验）

验证要留证据：把查询结果、日志片段、时间点记录下来。这些既用于决定“是否可以切流量”，也用于事后复盘。

阶段七：切换与收尾

切换（把业务流量指向恢复后的实例）是灾难恢复中最危险的时刻之一，因为一旦切换，回退成本很高。在此之前应当：

确认验证全部通过。
确认有新实例（或修复后实例）的备份已经开始运行——否则切换后又会进入“无备份保护”状态。
确认监控已覆盖新实例。
确认负责人明确批准。

切换之后要立即恢复备份保护（至少先有一次成功的备份与归档），并安排一次额外校验。

阶段八：复盘

无论成败，都应当复盘。复盘的重点不是追责，而是把以下问题回答清楚：

故障的根本原因是什么？
从发现到恢复各阶段各用了多久？（用记录的时间戳算）
哪个环节最慢？是技术还是协调？
备份与归档是否按预期工作？有没有发现缺口？
文档与脚本是否需要更新？
需要新增哪些监控或自动化？

复盘的结论必须落到具体改动（改文档、改脚本、加监控、调参数、改流程），否则下次会重复同样的问题。

角色与职责

事故现场最容易出现的问题不是没人干活，而是职责不清。一个简单的分工框架：

角色	职责
事件指挥（IC）	统一决策、对外沟通、分配任务
操作执行	按手册执行恢复动作
业务确认	确认可接受的数据丢失范围与切换时机
沟通协调	向相关方同步进展，避免多人同时重复询问
记录人	记录时间线、决策与命令

小型团队可以由一人兼多职，但职责必须在演练中明确过一次，而不是在事故中临时分配。

沟通机制

沟通成本常常是 RTO 的隐性杀手。有效的做法：

建立单一沟通渠道（一个群或一个电话会议），避免信息分散。
设定固定的同步节奏（例如每 15 分钟一次简短更新）。
明确“谁对外发声”，避免多人给出不一致的信息。
记录关键决策与时间点，供复盘使用。

恢复手册应包含的内容

手册是流程的载体。最小可用手册应包含：

环境信息（主机、端口、数据目录、归档位置、配置路径）。
恢复参数模板（restore_command、recovery_target_*）。
分步操作命令（可直接复制执行）。
每一步的预期输出与判断标准。
常见错误的处置方法。
关键联系人。

手册的检验标准很简单：一个没参与过这套系统的人，能否照着做完。

恢复到不同对象的选择

灾难场景中，“恢复哪个对象”本身就是一个决策：

想恢复的对象	手段
整实例	物理备份 + WAL 归档（PITR）
单个数据库	逻辑备份（`pg_dump` 单库），或 PITR 到新实例后抽取
单张表	逻辑备份（`pg_dump -t`），或 PITR 到新实例后 `COPY` 抽取
单行数据	从逻辑备份解析，或从副本/审计日志中还原

决策时的一个原则是：能用小手段就别用大手段。为找回一行数据而重放整个实例，既慢又风险高。

恢复时长的影响因素

因素	影响
备份大小	直接决定搬运与重放时间
存储性能	顺序读带宽是瓶颈
WAL 数量	从备份结束到目标时刻的 WAL 越多，重放越久
CPU	WAL 重放是单线程，主频影响明显
校验与验证	完整校验耗时可能接近恢复本身
人员响应	从告警到有人开始操作的时间

其中“WAL 重放是单线程”这一点常被低估：即使有 64 核，重放速度基本由单核性能与 I/O 决定。因此“备份越旧、需要重放的 WAL 越多、恢复越慢”是一个正向反馈的恶化关系。

为什么要保留“失败现场”

在处理灾难时，直觉是尽快清理现场。但有些场景下，保留现场的价值很高：

怀疑硬件故障：保留日志与磁盘状态有助于定位。
怀疑安全事件：现场是取证基础。
需要复盘：原始的目录结构、配置、日志都是证据。

建议至少把日志复制一份到安全位置，再开始动数据目录。

恢复期间的只读可用性

在某些场景下，可以让恢复出来的实例先以只读方式对外提供部分服务（例如只提供查询），以缓解业务压力，等验证充分后再开放写入。这需要：

明确哪些业务可接受只读。
明确只读期间的数据可能不完整。
明确开放写入的判断条件。

这属于业务折中，必须由业务方参与决定。

恢复与归档的中断处理

在恢复期间，原实例通常已停止，WAL 归档也随之中断。这意味着恢复过程本身不会产生新的归档。若恢复耗时很长，需要注意：

恢复完成后，先确认归档已恢复工作，再对内宣布完成。
恢复期间产生的新业务数据（如果切换到了备用节点）也需要纳入归档保护。

否则会出现“恢复完成，但新数据未受保护”的陷阱。

恢复演练与真实灾难的差别

演练通常知道“故障是什么、要恢复到哪”，真实灾难则充满未知。因此演练设计应当刻意引入不确定性：

不提前告知具体故障类型。
提供不完整的初始信息，要求参与者在流程中获取。
要求真实执行验证与切换步骤，而不只是“跑一遍命令”。

只有带不确定性的演练，才能检验到决策与协作环节——而这正是真实灾难中最容易出问题的地方。

灾难分级与响应级别

同样叫“故障”，影响面差别极大。把灾难分级，可以让响应动作与投入的资源匹配：

级别	典型表现	影响范围	典型响应
一般故障	单个连接报错、部分查询变慢	局部功能	值班处理，不启动灾难流程
严重故障	实例不可用，可快速重启恢复	单实例	运维按手册恢复，事后复盘
灾难	实例不可用且数据可能受损	单实例或整个集群	启动灾难恢复流程，多角色参与
重大灾难	主库与备库同时受损，或机房级失效	业务整体	启动最高级别响应，动用异地备份

分级的意义在于：不要对每个故障都启动最高级别流程（成本高、易麻木），也不能把灾难当一般故障处理（延误时机）。分级标准应当在平时定义清楚，并写明每级对应的决策授权人。

恢复目标的选择：崩溃点还是稍早时刻

灾难恢复常常要选择恢复到哪个时刻，这里有两种典型取向：

恢复到尽可能新的位置：把数据损失降到最小，但风险是——如果灾难是由逻辑错误、误操作、恶意写入引起的，那么这些“坏数据”已经写进 WAL，恢复得越新，坏数据也被一起恢复出来。
恢复到稍早的安全点：牺牲一部分最新数据，换取“确定干净”的状态。适合逻辑损坏类灾难。

判断方法：先问清楚“灾难是让数据丢失，还是让数据变坏”。

数据丢失（磁盘损坏、实例崩溃）→ 尽量往新恢复。
数据变坏（误删表、错误批处理、安全事件）→ 恢复到坏动作发生之前。

如果不确定是哪一类，宁可先恢复到较早的时刻并暂停，在确认数据质量后再决定是否继续往前推进（这正是把 recovery_target_action 设为 pause 的价值）。

实战示例

示例一：确认实例状态

bash

pg_isready -h 127.0.0.1 -p 5432

text

127.0.0.1:5432 - no response

结合日志确认属于实例级故障：

bash

tail -n 50 /var/lib/pgsql/data/log/postgresql-2026-09-20.log

示例二：止损（停止写入路径）

sql

-- 先撤销应用的写入能力（示例：改为只读账号或撤销权限）
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE usename = 'app_user'
  AND pid <> pg_backend_pid();

这一步的目的是防止数据继续被破坏，为后续精确恢复争取条件。

示例三：记录故障前后关键时间点

sql

SELECT now() AS recorded_at,
       pg_last_xact_replay_timestamp() AS last_replay_ts,
       pg_current_wal_lsn() AS current_lsn;

在决策阶段，这些值用于估算“需要重放多久”与“会丢多少”。

示例四：检查归档是否齐全

sql

SELECT archived_count, failed_count, last_archived_wal, last_archived_time
FROM pg_stat_archiver;

text

 archived_count | failed_count |  last_archived_wal    |   last_archived_time
----------------+--------------+-----------------------+------------------------
           1452 |            0 | 000000010000000000000C | 2026-09-20 10:35:12+08

若 last_archived_time 早于故障时刻较多，说明存在数据缺口，恢复目标需相应下调。

示例五：准备恢复配置

conf

restore_command = 'cp /mnt/wal_archive/%f %p'
recovery_target_time = '2026-09-20 10:30:00+08'
recovery_target_inclusive = on
recovery_target_action = 'pause'

先用 pause 让实例停在目标点，便于验证后再提升，而不是直接 promote。

示例六：启动恢复并观察

bash

touch /var/lib/pgsql/data/recovery.signal
pg_ctl start -D /var/lib/pgsql/data -l /var/lib/pgsql/restore.log

bash

grep -E "recovery|restored log file" /var/lib/pgsql/restore.log | tail -n 20

关注日志中“已重放到哪个位置”的信息，与目标对比。

示例七：验证恢复结果

sql

SELECT pg_is_in_recovery(),
       pg_last_wal_replay_lsn(),
       pg_last_xact_replay_timestamp();

text

 pg_is_in_recovery | pg_last_wal_replay_lsn | pg_last_xact_replay_timestamp
-------------------+------------------------+-------------------------------
 t                 | 0/16C4D88              | 2026-09-20 10:30:00.123456+08

pg_last_xact_replay_timestamp 恰好落在目标时间附近，说明恢复点正确。

示例八：提升并确认可用

sql

SELECT pg_promote();

bash

pg_isready -h 127.0.0.1 -p 5432

确认可写：

sql

SELECT pg_is_in_recovery();
-- 期望返回 f

示例九：记录一次完整的恢复时间线

text

10:12  监控告警：实例无响应
10:14  确认故障：pg_isready 无响应，日志显示磁盘写满
10:16  止损：停止实例，扩容磁盘
10:25  决策：走原地恢复，目标时间 10:10（RPO 5 分钟）
10:28  环境准备完成，开始恢复基础备份
10:52  基础备份恢复完成，启动实例与 WAL 重放
11:05  重放到目标点，实例暂停
11:12  验证通过（结构 + 数据 + 一致性）
11:18  提升为主库，业务流量恢复
11:30  首次备份与归档确认正常

总共约 66 分钟。复盘时可以看出：环境准备与验证占用了较多时间，是优化重点。

示例十：恢复后的收尾动作

sql

-- 确认归档链路已恢复
SELECT archived_count, failed_count, last_archived_time FROM pg_stat_archiver;

bash

# 确认新备份已生成
ls -lt /var/lib/pgsql/backup/daily | head

这两步是“宣布恢复完成”前的必要检查。

示例十一：评估数据丢失量

恢复完成后，用恢复起点与恢复终点估算丢失了多少数据。时间差可以直接从日志比对；如果用 LSN 计算字节量：

sql

-- 对比两个 LSN 之间的字节距离（示例中为占位 LSN，请替换为真实值）
SELECT pg_wal_lsn_diff('0/3000000', '0/2F00000') AS bytes_between;

text

   bytes_between
------------------
          1048576

这个数值用于向业务方说明“丢了多少字节的 WAL”，再结合业务写入速率换算成大概多少秒的写入，比单纯说“回滚了几分钟”更容易被理解。

示例十二：恢复到指定恢复点后再开放写入

如果事先用 pg_create_restore_point 打过命名恢复点，可以在灾难恢复时精确停在该点上：

sql

-- 日常运维中使用：打一个命名恢复点（注意：需要超级用户，且会写 WAL）
SELECT pg_create_restore_point('before_major_upgrade');

conf

# 恢复时在 postgresql.conf 中指定命名恢复点
restore_command = 'cp /mnt/wal_archive/%f %p'
recovery_target_name = 'before_major_upgrade'
recovery_target_inclusive = on
recovery_target_action = 'pause'

命名恢复点的前提是事先打过；如果灾难发生前没有打点，就退回到按时间或 LSN 恢复。

注意事项

告警不等于故障确认，启动恢复流程前务必用独立路径确认。
不要在看清状况前开始恢复。先止损、再决策，避免恢复被持续破坏。
停止实例前记录 LSN 与时间，这是事后计算数据丢失量的唯一依据。
原地恢复前先保留现场，至少把日志复制一份。
恢复配置可能被备份中的配置覆盖，注意追加顺序与配置来源优先级。
recovery.signal 与 standby.signal 互斥，同时存在会导致启动失败。
recovery.conf 在 PostgreSQL 12 已被移除，存在该文件会导致服务端拒绝启动。
WAL 重放是单线程的，重放时长由单核性能与 I/O 决定，与核数无关。
恢复期间不会产生新的归档，恢复后要单独确认归档链路已恢复。
切换是高风险动作，必须以验证通过 + 明确批准为前提。
不要在没有备份保护的情况下开放业务写入，切换后应尽快恢复备份与归档。
复盘结论必须落成具体改动，否则同类故障会重复发生。

最佳实践

事前从业务方取得书面的 RPO / RTO 指标，并据此设计三条恢复路径的适用条件。
维护一份可直接执行、含预期输出的恢复手册，并确保非原作者也能照着完成。
在演练中明确“事件指挥 / 操作执行 / 业务确认 / 沟通 / 记录”五类角色分工。
建立统一沟通渠道与固定同步节奏，减少恢复过程中的信息噪声与重复询问。
恢复流程中固定加入“止损”环节，防止恢复期间数据继续被破坏。
用 recovery_target_action = 'pause' 作为默认选择，先验证再提升，避免误提升。
恢复完成后执行分层验证（服务、结构、数据、一致性、应用），并保存验证证据。
切换前确认新实例的备份与归档已开始工作，避免出现保护空窗。
记录完整时间线（发现、确认、决策、准备、恢复、验证、切换），并在复盘时逐段分析耗时。
每次灾难处置或演练后更新手册、脚本与监控，并把改动纳入版本管理。
至少每季度演练一次，且要在演练中刻意引入不确定性以检验决策环节。
对恢复环境（主机、存储、容量）做常态化准备，不要等到事故现场才开始找资源。

继续学习：异地备份策略

灾难恢复流程 ​

基础概念 ​

什么算灾难 ​

RPO 与 RTO 在灾难场景下的含义 ​

灾难恢复与备份的关系 ​

恢复点与恢复时间 ​

故障发现与故障确认 ​

恢复决策的三条路径 ​

一次 PITR 与灾难恢复的区别 ​

恢复的时间构成 ​

语法与用法 ​

判断实例是否在恢复中 ​

查看重放进度 ​

检查恢复是否完成 ​

手工提升备库 ​

查看是否已有实例监听目标端口 ​

查看备份与归档的关键状态 ​

记录恢复起点 ​

详细说明 ​

阶段一：发现与确认 ​

阶段二：止损 ​

阶段三：评估与决策 ​

阶段四：环境准备 ​

灾难恢复流程

基础概念

什么算灾难

RPO 与 RTO 在灾难场景下的含义

灾难恢复与备份的关系

恢复点与恢复时间

故障发现与故障确认

恢复决策的三条路径

一次 PITR 与灾难恢复的区别

恢复的时间构成

语法与用法

判断实例是否在恢复中

查看重放进度

检查恢复是否完成

手工提升备库

查看是否已有实例监听目标端口

查看备份与归档的关键状态

记录恢复起点

详细说明

阶段一：发现与确认

阶段二：止损

阶段三：评估与决策

阶段四：环境准备