PostgreSQL 数据库迁移与备份策略总结

2026年3月 · 约14分钟 · 标签：PostgreSQL · 备份 · 迁移

数据库备份和迁移是运维中绕不开的基础工作。PostgreSQL 提供了丰富的备份和恢复工具，本文结合实际操作经验，整理了几种常见的备份策略和跨服务器迁移方案。

一、逻辑备份：pg_dump / pg_restore

pg_dump 是最常用的备份工具，导出 SQL 文件或自定义格式：

# 导出为 SQL 文本格式

pg_dump -h localhost -U appuser -d appdb > appdb_backup.sql

# 导出为自定义格式（支持压缩和并行恢复）

pg_dump -h localhost -U appuser -d appdb -Fc -f appdb_backup.dump

# 只导出指定表的数据

pg_dump -h localhost -U appuser -d appdb -t users -t orders -a > users_orders_data.sql

恢复时对应使用 psql（SQL 格式）或 pg_restore（自定义格式）：

# 恢复 SQL 格式

psql -h newhost -U appuser -d appdb < appdb_backup.sql

# 恢复自定义格式（使用 4 个并发作业加速）

pg_restore -h newhost -U appuser -d appdb -j 4 appdb_backup.dump

pg_dump 的优点是不需要停机，导出的是某个时间点的快照。对于大数据库，建议使用 -Fc 自定义格式，支持压缩，体积更小，并且 pg_restore 支持并行恢复。

二、物理备份与 PITR 时间点恢复

对于需要更低 RPO（恢复点目标）的场景，可以使用 PostgreSQL 的 WAL 归档实现连续归档备份和时间点恢复：

# postgresql.conf 配置

wal_level = replica

archive_mode = on

archive_command = 'cp %p /backup/wal/%f'

配置好后执行 pg_basebackup 做一次全量备份：

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

当需要恢复时，就可以恢复到任意时间点：

# 恢复配置 restore_command = 'cp /backup/wal/%f %p'

# 设置 recovery_target_time = '2026-03-15 14:30:00'

# 启动 PostgreSQL，自动应用 WAL 直到目标时间点

PITR 的优点是恢复粒度精细到秒级别，但需要额外配置 WAL 归档存储空间。建议全量备份每天执行一次，WAL 归档保留 7 天。

三、跨服务器迁移方案

PostgreSQL 14 及以上版本提供了 pg_dump 的并行导出功能，对大数据量迁移很有帮助：

小数据量（< 10GB）：直接使用 pg_dump + psql 管道传输，最简洁。
中等数据量（10-100GB）：使用 -Fc 格式 + pg_restore -j，配合 rsync 传输 dump 文件。
大数据量（> 100GB）：建议使用 pg_basebackup 做物理备份，在新服务器上直接恢复，速度最快。

迁移时需要注意几个问题：

新旧服务器的 PostgreSQL 主版本号要一致，跨版本迁移需要先用 pg_upgrade 工具。
迁移前记录好自定义配置参数（shared_buffers、work_mem 等），迁移后重新应用。
迁移完成后要对关键表执行 ANALYZE，更新统计信息，确保查询计划正确。

四、定期备份脚本自动化

生产环境需要配置自动化的定期备份。以下是一个简单的备份脚本：

#!/bin/bash

BACKUP_DIR="/backup/postgres"

DATE=$(date +%Y%m%d_%H%M%S)

DB_NAME="appdb"

# 创建备份目录

mkdir -p $BACKUP_DIR/$DATE

# 执行备份

pg_dump -h localhost -U backup_user -d $DB_NAME -Fc \

  -f $BACKUP_DIR/$DATE/$DB_NAME.dump

# 压缩

gzip $BACKUP_DIR/$DATE/$DB_NAME.dump

# 删除 7 天前的备份

find $BACKUP_DIR -type d -mtime +7 -exec rm -rf {} \;

配合 crontab 每天凌晨执行：

0 3 * * * /usr/local/bin/backup-postgres.sh >> /var/log/backup.log 2>&1

五、备份验证的重要性

没有经过验证的备份，等于没有备份。

定期检查备份文件的完整性非常重要。建议每月做一次恢复演练，在测试环境中实际恢复备份数据并验证数据完整性。遇到过备份文件损坏或备份时数据库连接异常导致备份不完整的情况，如果没有恢复演练，真到需要时才发现备份不可用，后果很严重。

六、总结

PostgreSQL 的备份工具链非常成熟，关键在于根据数据量和业务要求选择合适的方案。逻辑备份灵活简便，适合中小规模数据库；物理备份+PITR 恢复能力更强，适合对 RPO 要求高的核心业务。无论选择哪种方案，定期验证备份可用性都是必须坚持的底线。