PostgreSQL备份恢复实战：pg_dump与物理备份方案选型

PostgreSQL的备份方案选型，先要分清逻辑备份与物理备份的边界。pg_dump导出SQL语句，恢复粒度细、跨版本迁移方便，但备份耗时随数据量线性上升；物理备份拷贝数据文件，速度快、能配合PITR恢复到任意时间点，但依赖版本与平台一致性。数据库备份恢复方案的选择，直接决定故障时能找回多少数据。

逻辑备份：pg_dump与pg_restore的日常用法

pg_dump默认输出SQL文本，配合压缩与自定义格式使用更高效：

# 自定义格式（可并行恢复、可选择恢复对象）
pg_dump -h localhost -U postgres -Fc mydb -f mydb.dump

# 恢复
pg_restore -h localhost -U postgres -d mydb --jobs=4 mydb.dump

自定义格式（-Fc）的好处：恢复时支持–jobs并行、可以单独恢复某张表、依赖顺序自动处理。只导数据用pg_dump –data-only，只导结构用–schema-only。单表导出用-t mytable即可。

pg_dump期间默认使用可重复读快照，备份过程不阻塞业务读写，但大库导出耗时长、磁盘占用大。

物理备份：基础备份与WAL归档

物理备份解决大库备份耗时与恢复时间点的问题。流程是：开启WAL归档，用pg_basebackup做基础备份，持续归档WAL日志，恢复时把基础备份和归档WAL按时间点重放。

# 开启归档（postgresql.conf）
archive_mode = on
archive_command = 'test ! -f /backup/wal/%f && cp %p /backup/wal/%f'

# 基础备份
pg_basebackup -h localhost -U postgres -D /backup/base -Ft -z -P

归档目录要放在独立存储或对象存储，防止与数据文件同时损坏。恢复时把基础备份解压到数据目录，配置standby.signal指向归档目录，启动后数据库自动重放WAL到目标时间点。

PITR时间点恢复实战：误删数据找回

PITR（Point-in-Time Recovery）能解决误删数据的问题：把时间点恢复到误删语句执行之前。

# postgresql.conf 或 recovery.conf 中的恢复目标
recovery_target_time = '2026-09-04 10:00:00'
recovery_target_timeline = 'latest'

执行PITR的前提是基础备份加完整WAL链。建议每天做一次基础备份，WAL每5分钟归档一次；恢复演练每月做一次，否则临场找不到归档文件或目录权限问题，恢复就是一句空话。

备份方案选型：逻辑与物理如何搭配

选型结论按数据量与恢复目标分三档：数据量小（百GB内）且恢复粒度要求高，用pg_dump逻辑备份，每天全量加增量；数据量大、要求分钟级RPO，用pg_basebackup加WAL归档，配合流复制做备库；关键业务再做一层：备库快照兜底，快照恢复比重放WAL更快，但会丢失快照后的变更。

备份验证规则固定三条：每日备份后执行pg_restore校验恢复可行性；每周做一次全量恢复演练；备份文件异机保存并保留7天以上。PostgreSQL备份恢复方案做到这三条，故障时心里有底。