适用范围与验证状态
本手册面向 PostgreSQL 17 的完整物理基础备份与归档 WAL 时间点恢复演练，状态为待验证（PENDING）。它不实施生产恢复，不执行文中命令，也不表示本站已有可用备份、已达到 RPO/RTO 或完成业务验收。其他大版本、托管服务和第三方备份工具必须先核对对应版本与供应商流程；增量备份链需先按其规范合成为可恢复的完整备份，不直接套用本流程。
PITR 处理误更新、误删除等需要回到历史状态的问题；主备切换主要恢复服务可用性，副本可能已经重放了错误事务，因此二者不能互相替代。演练只恢复到与原集群隔离的独立空实例，不覆盖生产数据目录，不修改生产代理和 DNS，不连接原有选主编排。恢复成功也不自动接收业务流量。
一、把恢复目标写成可以否证的条件
先登记事故或演练编号、数据负责人、批准窗口、原集群标识、备份标识及目标时间。目标必须使用明确 UTC 偏移，例如 2026-09-01 02:15:00+00 仅为虚构示例，不能直接照搬；同时记录来源日志的时区和时钟偏差。业务所说的“误操作之前”需要落实到数据库提交证据，界面点击时间不一定等于事务提交时间。
建议由业务方提供三类已存在的验收记录：目标前应保留的样本、错误事务不应出现的样本、目标后允许舍弃的样本。不要在生产中新建测试订单或执行破坏性事务来生成演练材料。事前明确可接受的数据缺口、隔离恢复耗时及最终接管耗时的不同口径，缺少记录时标记无法确认，而不是把空白填成零。
二、证明备份与归档链属于同一个集群
核对完整基础备份清单、开始与结束位置、系统标识、数据库大版本、表空间映射、校验清单和保留期限。必须拥有从基础备份起点到目标位置所需的连续 WAL，以及所选 timeline 的历史文件。逻辑导出不能充当物理基础备份，单独复制当前数据目录也不等于一套一致的在线备份。相关机制见 PostgreSQL 17 连续归档与 PITR。
归档任务近期成功只能说明近期文件传输状态，不能证明历史窗口连续可恢复。演练前保留源备份的不可变副本；从对象存储取回资料时核对精确对象版本、解密权限及完整性，访问凭据由受保护身份注入，不写进脚本、URL、工单或页面截图。出现缺段、解密失败或来源不明，停止进入启动阶段，不能补造同名 WAL 或跳过错误继续宣称成功。
三、在只读副本上核验基础备份
以下是待人工审阅的命令示例，不由本站执行。OPS_PITR_BASE 应指向已解包为 plain 格式的完整备份副本；OPS_PITR_WAL 指向已核对的归档取回目录，二者都不能指向运行中的生产目录。先确认磁盘与读取 I/O 预算，再由获批执行人运行匹配 PostgreSQL 17 的工具。
OPS_PITR_BASE='/REPLACE_WITH_VERIFIED_BACKUP_COPY'
OPS_PITR_WAL='/REPLACE_WITH_VERIFIED_WAL_COPY'
pg_verifybackup --version
pg_verifybackup --exit-on-error --wal-directory="$OPS_PITR_WAL" "$OPS_PITR_BASE"保存退出码和脱敏摘要。pg_verifybackup 按 manifest 检查文件及基础备份恢复所需 WAL，不会验证额外 WAL 的整个目标窗口，也不能替代服务器启动和业务核验。不得使用跳过校验、忽略缺失文件等选项使报告变绿；具体限制见 pg_verifybackup。若读取影响同盘业务，先停止校验，换用受控副本或新的批准窗口。
四、隔离实例与外部副作用
准备独立主机、容器或虚机，以及此前未使用的空数据目录和独立表空间目标。由双人复核实例清单、实际挂载、符号链接终点与剩余容量，尤其禁止恢复出的表空间链接仍指向生产磁盘。只允许恢复管理员访问；导入数据仍可能含敏感信息，隔离区同样需要访问审计和到期清理制度。
网络策略必须阻断恢复副本访问生产写接口、邮件、消息队列和第三方回调。检查继承配置、postgresql.auto.conf、扩展启动参数、订阅连接与定时任务，把原有流复制连接、选主编排注册和归档写入目的地作为明确核对项。不能只改监听端口便认定隔离完成。启动前由负责人确认还原配置不会重新接入原集群，任意依赖不明就暂停，保留副本以便重新设计。
五、审核恢复配置而不直接推广为通用脚本
下面片段只表达配置意图，不是可直接部署的配置。恢复管理员需按备份工具生成隔离实例配置，并在其数据目录设置 recovery.signal。归档读取命令必须使用该工具经测试的取回逻辑，正确处理 %f、%p 和找不到文件时的退出状态；本文不提供未经环境验证的复制命令。
# 示例仅用于评审；目标时间和 timeline 必须替换为已批准证据。
recovery_target_time = '2026-09-01 02:15:00+00'
recovery_target_inclusive = off
recovery_target_timeline = '3'
recovery_target_action = 'pause'
hot_standby = oninclusive 决定是否包括恰好落在目标上的事务；timeline 必须与目标历史分支对应，不能无条件使用默认 latest。同一次恢复只选定一种主要目标条件，参数与时区由两人确认。pause 配合 hot standby 用于停在目标后只读检查；恢复未达到已设目标就结束会报错，不能把错误退出当作完成。语义以 恢复目标参数 为准。
六、证明停在目标而不是仅仅可以连接
启动由批准的恢复执行人通过既有服务管理方式完成，本手册不启动任何实例。观察启动日志、实际读取的归档分支和恢复目标提示，同时记录磁盘、I/O 与耗时。以下只读 SQL 仅在已确认身份的隔离测试连接执行；超时预算按审批设置，不能用生产默认连接代替。
BEGIN READ ONLY;
SET LOCAL statement_timeout = '5s';
SHOW server_version;
SELECT pg_is_in_recovery(), pg_last_wal_replay_lsn(),
pg_last_xact_replay_timestamp();
COMMIT;先确认 pg_is_in_recovery() 为真，再由具有相应只读核验权限的执行人查询 pg_get_wal_replay_pause_state()，结果应为 paused 而非仅 pause requested。最后回放事务时间不一定恰好等于目标时间，必须与日志、配置和业务样本联合判断。恢复信息函数 定义了这些状态，不应凭一个布尔值宣布完整恢复。
七、业务核对、停止与重新尝试
按预先批准的精确主键执行小范围只读核对，记录查询范围、实际值摘要和验收人。必要扩展、表空间、权限和关键报表入口都应纳入清单；全表计数或一致性校验若超出预算，改用已批准样本并公开覆盖限制。检查订单、账务、消息等跨系统关系时，只使用隔离样本，不尝试重新发送生产事件来“补齐”状态。
若目标选晚、错误事务仍存在、timeline 不符或数据证据冲突，保持业务入口隔离，保存日志与副本。需要回到更早目标时，应重新从受保护备份恢复到新的空位置，不在已回放的数据上倒放 WAL。即使只想向后继续恢复，也必须重新审批目标与配置，不能随手调用恢复继续或提升函数。禁止自动 pg_promote、修改生产入口、删除生产 WAL 或覆盖备份。
八、验收记录与正式接管边界
建议报告逐项填写：备份及归档对象身份、版本与 timeline、含时区的目标、检查结果、实际暂停状态、业务样本结论、取回/回放/核验耗时、未覆盖范围和审批人。没有实测就继续标为 PENDING；恢复耗时与业务接管时间分别记录，不能合并成未经验证的容灾指标。
业务接管是独立变更：需要评审原写入口隔离、新旧数据差异、外部系统补偿、连接池重建、后续归档和新的备份计划。新实例一旦接受写入，直接切回旧实例可能丢失或分叉数据，不属于本演练的自动回退。演练结束后只按精确资产清单清理获批临时副本；源备份、归档和关键证据按保留制度继续保护。