PostgreSQL PITR 是什么
时间点恢复先用一份基础备份搭出数据目录骨架，再通过恢复命令从归档目录按顺序拉取预写日志重放，最后停在指定的时间、日志序列号或命名恢复点。从较新版本开始，进入恢复模式由恢复信号文件触发，恢复目标与恢复动作通过配置项声明。
基本信息
| 前置条件 | 一份基础备份，以及从该备份之后连续的归档日志 |
|---|---|
| 停止条件 | 按时间、日志序列号或命名恢复点选择 |
| 恢复动作 | 可选提升为可写、暂停等待确认或直接关闭 |
| 触发方式 | 恢复信号文件配合实例启动 |
恢复配置
恢复配置
# postgresql.conf 中设置
restore_command = 'cp /backup/pg/wal/%f %p'
recovery_target_time = '2026-10-12 10:30:00+08'
recovery_target_action = 'promote'触发恢复
触发恢复
touch /var/lib/pgsql/data/recovery.signal
systemctl start postgresql
# 观察日志中的恢复停止记录
grep -i 'recovery stopping' /var/lib/pgsql/data/log/postgresql-*.log三种停止方式
| 方式 | 适用情形 | 注意 |
|---|---|---|
| 目标时间 | 知道误操作发生的大致时刻 | 必须携带时区，否则可能停在错误时间 |
| 目标日志序列号 | 已从日志中定位到具体坐标 | 坐标算错会连带重放误操作 |
| 命名恢复点 | 变更前主动打了标记 | 需要在业务侧配合预设 |
使用要点
- 恢复环境要与新实例一致：版本、配置与归档路径都要核对，避免回放中途失败
- 恢复日志要保留：日志里记录了停止位置与实际回放范围，是验证的重要证据
- 目标时间宁早勿晚：停在误操作之前的瞬间，再人工补齐少量数据
- 演练后清理信号文件与目标参数，否则下次重启会再次进入恢复模式
- 恢复完成先只读核对，确认数据无误后再开放写入
恢复完成后检查日志中的恢复停止记录，确认停止点符合预期再做业务验证；只看进程启动成功是不够的。
恢复后的检查项
- 核对实际停止时间与目标时间是否一致，偏差过大要查明原因
- 检查关键表行数与业务抽检数据是否回到预期状态
- 确认实例已退出恢复模式并处于可写状态
- 记录本次恢复用到的日志区间，作为后续演练的参照