PostgreSQL：使用pg_basebackup全备后如何备份WAL日志并确保完整性

嗨，我来帮你梳理下如何配置WAL日志备份并保证完整性，结合你已经在用的pg_basebackup全量备份方案，一步步来：

这是备份WAL的基础，你需要修改postgresql.conf里的几个核心参数：

• 修改wal_level = replica（如果不需要逻辑复制，replica足够；要是以后需要逻辑备份可以设为logical），默认的min级别不支持归档和复制。
• 开启归档模式：archive_mode = on
• 配置归档命令archive_command，这是告诉PostgreSQL怎么把写完的WAL文件复制到备份存储。举几个实用例子：
  • 本地归档：'cp %p /mnt/backup/wal_archive/%f'，其中%p是WAL文件的绝对路径，%f是文件名
  • 远程归档（用rsync）：'rsync -a --quiet %p backup_user@backup_server:/remote/wal_archive/%f'

  注意：这个命令必须返回0才会被PostgreSQL认为归档成功，如果失败，PostgreSQL会不断重试，直到成功或者你手动干预。

你已经每周做全量备份，建议在执行pg_basebackup时加上-X stream参数，这样在备份过程中会实时流式复制WAL日志，避免备份期间生成的WAL没被归档而导致备份不完整：

pg_basebackup -D /mnt/backup/full_backup_$(date +%Y%m%d) -X stream -P -U backup_user

• -D 指定全量备份的存储目录，加日期后缀方便区分不同备份
• -X stream 实时流式传输备份期间的WAL，确保备份的一致性
• -P 显示备份进度，方便监控

WAL文件损坏会导致恢复失败，你可以从这几个层面保障：

• 归档时即时校验：修改archive_command，在复制完成后用pg_waldump验证WAL文件的合法性，只有验证通过才返回成功：

  archive_command = 'cp %p /mnt/backup/wal_archive/%f && pg_waldump /mnt/backup/wal_archive/%f > /dev/null 2>&1'
  

  这样如果WAL文件损坏，pg_waldump会返回非0值，PostgreSQL会重试归档，你也能及时发现问题。
• 定期批量校验：写个脚本定期遍历归档目录里的WAL文件，用pg_waldump或者pg_checksums（如果你的数据库开启了数据校验和）做批量检查，比如：

  for wal in /mnt/backup/wal_archive/000000*; do
    pg_waldump "$wal" > /dev/null || echo "WAL file $wal is corrupted!"
  done
  

• 依赖PostgreSQL内置校验：WAL文件本身带有CRC校验，PostgreSQL在写入、归档、恢复时都会自动验证这个校验和，如果文件在传输或存储中损坏，恢复时会直接报错并停止，你能立刻定位到损坏的文件。
• 用可靠的存储和传输方式：归档目录尽量用带冗余的存储（比如RAID1/5），远程传输用rsync、scp这类可靠的协议，避免用容易丢包的方式。

当你需要恢复数据库时，先恢复全量备份，然后在postgresql.conf里配置restore_command指向你的归档目录：

restore_command = 'cp /mnt/backup/wal_archive/%f %p'

启动PostgreSQL后，它会自动从归档目录读取需要的WAL文件并逐一验证CRC，如果遇到损坏的WAL，会直接抛出错误，告诉你具体哪个文件有问题，这时候你可以从其他备份源（比如异地归档）替换损坏的文件，再继续恢复。

• 不要手动删除归档的WAL文件，建议用pg_archivecleanup工具，它可以根据你的全量备份时间自动清理掉不需要的旧WAL，避免误删导致恢复失败。
• 监控归档目录的磁盘空间，WAL的生成速度取决于数据库的写入量，要是空间满了会导致PostgreSQL停止服务。
• 如果你的业务对RPO要求很高，除了归档WAL，还可以考虑搭配流式复制搭建备用服务器，和归档备份形成互补。

内容的提问来源于stack exchange，提问作者user3161584