WAL-G是GitHub上开源的PostgreSQL备份与恢复工具，由原Yandex团队维护，基于Go语言开发。它最大的特点是支持多种云存储后端，包括S3、Azure Blob、Google Cloud Storage、Swift等，同时也支持本地文件系统存储。相比传统的pg_basebackup，WAL-G提供了增量备份、并行上传、压缩加密等企业级特性，目前已成为生产环境中部署PostgreSQL高可用方案时的热门选择。
WAL-G的核心特性与工作原理
要理解WAL-G的价值，先要明白PostgreSQL的WAL机制。WAL全称是Write-Ahead Logging，即预写式日志，数据库每次修改数据时都会先在WAL日志中记录一条，这样即使数据库崩溃，也能通过重放WAL日志恢复到一致状态。WAL-G正是利用这一机制，将数据文件和WAL日志归档到远端存储，从而实现完整备份与基于时间点的恢复（PITR）。
WAL-G的增量备份设计非常巧妙。它通过读取数据页面的LSN（日志序列号）来判断页面是否发生过修改，只备份那些LSN大于上次备份时间点的页面，这属于页面级的增量备份，粒度远比文件级增量要细。在实际使用中，如果数据库规模达到数百GB，采用增量备份可以把备份时间和存储成本压缩到原来的几分之一甚至更低。
在传输层面，WAL-G默认对数据进行压缩后再上传，支持LZ4、ZSTD、Brotli等压缩算法。其中LZ4速度快但压缩率一般，ZSTD则在速度和压缩率之间取得了不错的平衡，配合等级参数可以灵活调整。此外，WAL-G支持多线程并行上传，对于网络带宽充足的场景，开启并行可以显著缩短备份窗口。
安装与环境变量配置
WAL-G提供了预编译的二进制包，安装最简单的方式是直接从GitHub的release页面下载对应平台的可执行文件。以Linux为例，下载后放到/usr/local/bin目录并赋予执行权限即可。如果机器上有Go编译环境，也可以通过源码自行编译，这样便于使用一些未发布的特性。
# 下载并安装wal-g二进制文件 wget https://github.com/wal-g/wal-g/releases/download/v3.0.3/wal-g-pg-ubuntu-22.04-amd64.tar.gz tar -xzf wal-g-pg-ubuntu-22.04-amd64.tar.gz mv wal-g-pg-ubuntu-22.04-amd64 /usr/local/bin/wal-g chmod +x /usr/local/bin/wal-g # 验证安装 wal-g --version
WAL-G的所有配置都通过环境变量完成，没有单独的配置文件，这一点和pgBackRest不同。最核心的变量是WALG_S3_PREFIX，用来指定备份存储路径，其余的AWS访问密钥变量用于身份认证。下面的例子展示了对接S3兼容存储（比如MinIO）时的典型配置，建议将这些变量写入一个专用脚本，方便在定时任务中source调用。
# /var/lib/postgresql/walg_env.sh export WALG_S3_PREFIX="s3://pg-backup-cluster01" export AWS_ENDPOINT="http://192.168.1.100:9000" export AWS_ACCESS_KEY_ID="backupuser" export AWS_SECRET_ACCESS_KEY="your_secret_key" export AWS_REGION="us-east-1" export WALG_COMPRESSION_METHOD=zstd export PGDATA=/var/lib/postgresql/16/main export PGUSER=postgres
接下来需要配置WAL归档。编辑postgresql.conf，将archive_mode设为on，并把archive_command指向wal-g的wal-push子命令。同时要确保archive_timeout设置合理，比如60秒，这样即使写入不频繁，WAL段也能按时归档，避免时间点恢复时出现较大的延迟窗口。
# postgresql.conf中的归档配置 archive_mode = on archive_command = 'envdir /etc/wal-g.d/env wal-g wal-push %p' archive_timeout = 60 wal_level = replica
执行备份与恢复操作
配置完成后就可以执行备份了。基础备份使用backup-push命令，WAL-G会自动识别是全量备份还是增量备份：如果之前存在全量备份，直接执行backup-push默认会生成增量备份；想强制做全量，可以加上--full参数。备份完成后用backup-list命令查看备份集，输出中会显示每个备份的时间、增量类型和WAL区间。
# 执行全量备份 wal-g backup-push /var/lib/postgresql/16/main --full # 执行增量备份（默认行为） wal-g backup-push /var/lib/postgresql/16/main # 查看备份列表 wal-g backup-list # 删除7天前的旧备份，保留最近的全量链 wal-g delete retain FULL 7 --confirm
恢复操作分为两种场景。第一种是整库恢复到某个备份点，先停掉数据库，清空或移走原PGDATA目录，然后用backup-fetch拉取备份，完成后启动数据库即可。第二种是基于时间点的恢复，需要在拉取备份后创建recovery.signal文件，并在postgresql.conf或已废弃的recovery.conf中配置restore_command和recovery_target_time，数据库启动后会自动重放WAL日志直到目标时间点。
# 停库并移走原数据目录 sudo systemctl stop postgresql mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main_broken # 拉取最新备份 wal-g backup-fetch /var/lib/postgresql/16/main LATEST # 配置时间点恢复 touch /var/lib/postgresql/16/main/recovery.signal
# postgresql.conf追加恢复配置 restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p' recovery_target_time = '2024-06-15 14:30:00+08' recovery_target_action = 'promote'
恢复完成后记得检查数据是否完整，确认无误再对外提供服务。一个容易被忽视的细节是权限问题：恢复出来的目录属主必须是postgres用户，否则数据库启动会直接报错，建议恢复后统一执行一次chown修正。
备份策略与常见问题建议
在生产环境中，建议每周做一次全量备份，每天做增量备份，同时配合delete retain命令自动清理过期备份，避免存储成本无限增长。备份任务可以通过cron定时执行，脚本中务必加入备份后的校验逻辑，比如调用wal-g verify命令，确保备份链完整可用。备份不做验证等于没有备份，这是数据库运维中血的教训。
监控方面，要重点关注WAL归档延迟。可以通过查询pg_stat_archiver视图获取最近一次成功归档的时间，如果归档持续失败，WAL会在pg_wal目录不断堆积，最终撑爆磁盘。常见原因包括网络不通、密钥过期、存储桶配额满等，建议为归档失败配置告警。
和pgBackRest相比，WAL-G的优势在于轻量、部署简单、对云原生环境友好；而pgBackRest在备份仓库管理、多副本支持和文档完善度上更胜一筹。中小规模集群或者已经在使用对象存储的团队，选WAL-G通常更省心；超大规模、需要复杂保留策略的场景，可以评估pgBackRest。无论选哪个工具，定期做恢复演练都是必不可少的环节，只有真正恢复过的备份才值得信任。
WAL-GPostgreSQL备份数据库恢复修改时间：2026-09-07 09:26:44