WAL-G在PostgreSQL生态里算是备份数据相当主流的开源工具了，它基于Go语言开发，支持全量备份、增量备份和归档日志的连续上传。不过在真实的生产环境里，备份文件往往要传到对象存储，比如S3或者MinIO，数据一旦离开机房，加密就成了绕不开的话题。与此同时，数据库备份动辄几十上百GB，不压缩的话存储费用会非常高。WAL-G在加密和压缩两个方向都提供了灵活的配置项，这篇文章就来把这些选项逐一梳理清楚。
一、WAL-G的加密选项详解
WAL-G目前支持两种加密后端，一种是基于libsodium的对称加密，另一种是传统的PGP加密。两者的配置方式都是通过环境变量完成的，其中libsodium方式配置最简单，也是目前官方推荐的做法。
使用libsodium加密时，只需要设置WALG_LIB_SODIUM_KEY这一个环境变量即可，它的值是一个base64编码的对称密钥。WAL-G内部会用这个密钥派生出加密密钥和签名密钥，对每个备份分片做加密和完整性校验。需要注意的是，这个密钥一旦丢失，备份文件就彻底无法恢复了，所以密钥本身一定要单独备份到安全的地方，比如专门的密钥管理系统，千万不要和备份文件放在同一个存储桶里。
# 生成一个随机的base64密钥 openssl rand -base64 32 # 配置环境变量 export WALG_LIB_SODIUM_KEY="你的base64密钥" # 执行加密备份 wal-g backup-push /var/lib/postgresql/data
另一种方式是PGP加密，通过WALG_PGP_KEY指定私钥内容，或者用WALG_PGP_KEY_PATH指定私钥文件路径。PGP方式适合已经有现成PGP密钥体系的团队，但配置上要繁琐一些，还需要处理子密钥的问题。从实践经验来看，如果没有特殊需求，直接选libsodium就够了。
二、压缩算法的选择与对比
压缩配置通过WALG_COMPRESSION_METHOD环境变量控制，WAL-G支持的算法包括lz4、zstd、brotli、lzma以及不压缩的none。每种算法都有各自的特点，选择时要在压缩率、压缩速度和解压速度之间做权衡。
lz4是速度最快的选项，压缩率相对低一些，适合备份窗口很短、数据量特别大的场景。zstd是目前最受欢迎的折中选择，它可以通过WALG_COMPRESSION_LEVEL调整压缩级别，默认级别3在速度和压缩率上表现均衡，调到19则能获得接近lzma的压缩率，但耗时也会成倍增长。brotli和lzma压缩率最高，尤其是对文本型的WAL归档文件效果明显，但压缩速度慢，一般只用于归档冷数据。
| 算法 | 压缩速度 | 压缩率 | 适用场景 |
|---|---|---|---|
| lz4 | 极快 | 一般 | 大数据库、备份窗口紧张 |
| zstd | 快 | 较好 | 大多数生产环境 |
| brotli | 慢 | 好 | 冷数据归档 |
| lzma | 很慢 | 最好 | 对体积极致敏感 |
# 使用zstd压缩，级别设为5 export WALG_COMPRESSION_METHOD=zstd export WALG_COMPRESSION_LEVEL=5 # 备份并推送到存储 wal-g backup-push /var/lib/postgresql/data
有个容易被忽略的细节：压缩和加密是分层的，WAL-G会先压缩再加密，所以压缩率不会因为加密而下降。反过来，如果先加密再压缩，加密后的数据接近随机字节，压缩基本失效，这也是WAL-G设计上比较合理的一点。
三、配置示例与常见问题处理
下面给出一套生产环境常用的完整配置，把存储、加密、压缩都整合在一起。建议把这些环境变量写在单独的配置文件里，由备份脚本统一source加载，方便管理和轮换。
# /etc/wal-g.d/server_env.sh export WALG_S3_PREFIX="s3://pg-backup-bucket/prod" export AWS_ACCESS_KEY_ID="备份账号AK" export AWS_SECRET_ACCESS_KEY="备份账号SK" export WALG_LIB_SODIUM_KEY="base64编码的加密密钥" export WALG_COMPRESSION_METHOD=zstd export WALG_COMPRESSION_LEVEL=5 export PGDATA=/var/lib/postgresql/data
配置完成后，务必做一次恢复演练。加密配置错误最常见的表现是wal-g backup-fetch时报解密失败的错误，这时候要优先检查密钥是否与备份时一致。另外，如果修改了压缩算法，旧的备份仍然保持原来的算法，WAL-G在恢复时会自动识别，不需要手工干预，这一点可以放心。
还有一个坑值得提醒：有些同学习惯把加密密钥写进crontab或者脚本里，这样密钥会出现在进程列表和历史记录中，存在泄露风险。比较稳妥的做法是把环境变量文件权限设置为600，仅postgres用户可读，或者直接接入云厂商的KMS服务来托管密钥。备份策略再完善，密钥管理跟不上，整套方案的安全性也会大打折扣。
四、性能调优的几点建议
在调整压缩级别之前，建议先用真实数据做一轮基准测试。可以在测试库上分别用不同级别跑一次backup-push，记录耗时和备份体积，再结合存储费用和备份窗口做决定。一般来说，级别从3调到9，体积可能只减少百分之几，但耗时会明显上升，对多数业务来说默认级别3或者稍高的5就已经够用。
如果备份速度成为瓶颈，还可以关注WALG_UPLOAD_CONCURRENCY这个参数，它控制并发上传的分片数量。并发开大之后，压缩和上传可以流水线式并行执行，整体吞吐会有不错的提升。不过并发也不宜设置过高，否则容易触发对象存储的限流，反而拖慢备份速度。把这些参数组合起来反复测试几次，找到适合自己数据特点的平衡点，备份体系就能既安全又高效地跑起来了。
WAL-G数据库备份加密PostgreSQL备份压缩修改时间：2026-09-15 01:50:31