PostgreSQL 18 中文参考文档(未翻译部分保留英文)🌐 切换到英文原版 →

25.3. 连续归档与基于时间点恢复(PITR) #

25.3.1. 配置 WAL 归档
25.3.2. 制作基础物理备份
25.3.3. 制作增量备份
25.3.4. 执行 PITR 灾难恢复流程
25.3.5. 时间线(Timelines)
25.3.6. 使用低级 API 进行基础备份
25.3.7. 归档与备份实用建议
25.3.8. 持续归档注意事项

在任何运行时刻,PostgreSQL 都会在数据目录下的 pg_wal/ 中持续顺序追加写入预写式日志(WAL)。WAL 完整记录了数据文件上发生的一切细微物理变更。结合定期的物理基础全量备份(Base Backup)与源源不断连续生成的 WAL 增量日志段,构成了高可用企业级备份的核心架构:基于时间点恢复(Point-in-Time Recovery,简称 PITR)。

PITR 的核心技术优势包括:

25.3.1. 配置 WAL 归档 #

在 postgresql.conf 中配置以下核心参数以激活 WAL 连续归档:

wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

其中 archive_command 是一条 Shell 归档命令字符串,系统在每个 16MB 的 WAL 段文件写满封闭时自动触发调用该命令;%p 会被替换为待归档段文件的完整源路径,而 %f 会被替换为该段文件的文件名。确保归档命令在物理拷贝成功时返回退出码 0,拷贝失败时返回非零退出码。

25.3.2. 制作基础物理备份 #

制作物理基础全备的最简单且标准的方法是使用官方工具 pg_basebackup。它支持在线直连运行中的数据库并生成一致的物理数据快照:

pg_basebackup -h localhost -U replicator -D /backup/base -Fp -Xs -P -v

其中 -Xs 选项确保在备份运行期间将产生的所有 WAL 日志流式打包随同导出,保证备份产物具备完全自闭环的独立一致性。

25.3.3. 制作增量备份 #

自 PostgreSQL 17 起,官方工具 pg_basebackup 新增支持原生的物理级增量备份(通过 --incremental 参数)。它利用 WAL 摘要技术,仅提取自上次全备以来发生过实际物理修改的磁盘块,大幅削减海量数据大库的备份存储开销与传输耗时。恢复时利用官方工具 pg_combinebackup 将全备与增量备份合成重建为可直接启动的完整物理集群。

25.3.4. 执行 PITR 灾难恢复流程 #

当遭遇灾难性事故需要执行基于时间点的回滚恢复时,标准化运维步骤如下:

  1. 安全停止正在运行的异常数据库服务。

  2. 将数据目录下残留的最新尚未归档的 pg_wal/ 内容备份暂存到安全位置。

  3. 彻底清空当前损坏的数据目录及全部表空间目录。

  4. 将最近一份基础全量备份(Base Backup)解压还原到数据目录中,确保文件属主为系统用户 postgres 且权限合规。

  5. 将步骤 2 中暂存的未归档 WAL 段文件复制回还原后的 pg_wal/ 中。

  6. 在数据目录根目录下创建一个名为 recovery.signal 的空白标识文件(指示实例启动时强制进入恢复重放模式)。

  7. 在 postgresql.conf 中指定 WAL 提取还原命令与目标恢复停止时间点:

    restore_command = 'cp /mnt/server/archivedir/%f %p'
    recovery_target_time = '2026-10-15 12:05:00 CST'
    recovery_target_action = 'promote'
    

  8. 启动数据库服务。实例会检测到 recovery.signal 并自动进入恢复流程,调用 restore_command 从归档池中拉取 WAL 并逐一重放,直至精准抵达 recovery_target_time。完成回放后,系统自动删除 recovery.signal 并将实例提升(Promote)为正常接受读写的生产服务。

25.3.5. 时间线(Timelines) #

在完成基于时间点的恢复并重新接受新事务后,数据库的历史状态实际上分裂出了一条全新的时间分支。为了防止新产生的 WAL 覆盖原时间线上的同名日志段,PostgreSQL 引入了时间线(Timeline)标识机制。每次完成 PITR 提升后,时间线 ID(TLI)会自动递增并生成对应的 .history 历史分支索引文件,使系统能够清晰追溯并支持在复杂的多分支历史轨迹之间任意穿越恢复。

25.3.6. 使用低级 API 进行基础备份 #

除使用 pg_basebackup 外,还可以通过低级 SQL 函数(如 pg_backup_start() 与 pg_backup_stop())手动操控文件系统级备份。

25.3.6.1. 备份数据目录 #

在调用 pg_backup_start() 之后,可以使用 tar、cp 或存储快照等工具复制数据目录中的文件(排除不需要的临时文件与日志段),随后调用 pg_backup_stop() 结束备份并生成备份标签文件。

25.3.7. 归档与备份实用建议 #

以下是归档与热备份过程中的若干实用工程技巧。

25.3.7.1. 独立自包含热备份 #

可以将备份期间产生的必要 WAL 段直接打包进备份集中,使备份集具备完全自包含的独立恢复能力。

25.3.7.2. 压缩归档日志 #

在归档命令中使用 gzip 等工具对 WAL 段进行透明压缩,能够大幅削减归档存储空间的开销。

25.3.7.3. 备份脚本自动化 #

通过编写自动化的 cron 调度脚本,定期触发基础备份并清理过期的陈旧历史归档日志。

25.3.8. 持续归档注意事项 #

需要特别注意:归档目录必须具备充分的剩余磁盘空间,若归档命令因目标磁盘满溢而持续返回失败,数据库服务器会因堆积未归档的 WAL 而面临日志区写满停机风险;此外,请务必定期在测试环境演练 PITR 恢复流程以验证备份集的有效性。