PostgreSQL的WAL归档日志是时间点恢复和流复制的重要基础，但默认的归档命令通常采用scp或rsync将WAL文件推送到远端目录，如果只依赖网络层防护，归档内容存在被监听截获的风险。要实现归档日志加密传输，需要从传输层和应用层同时入手，明确不同方案的保护边界。本文会从归档命令工作机制切入，逐一介绍SSH加密隧道、GnuPG文件加密和pgBackRest内置加密三种方案，并讨论密钥管理与恢复验证。
一、归档日志传输的暴露面与加密目标
PostgreSQL通过archive_command参数调用外部命令来归档已完成的WAL段。常见的配置是使用scp、rsync或直接挂载NFS目录。这类命令默认不会对WAL内容做额外加密，即使scp底层使用了SSH协议，但如果SSH配置不当，比如没有校验主机指纹、允许了弱算法或使用了空密码，依然可能被中间人攻击。而在内网环境中，ARP欺骗、交换机镜像端口或恶意的内部用户同样可以抓取到WAL文件。WAL段里不只是SQL语句，还包含插入、更新和删除操作的具体值，甚至包括COPY导入的整批数据，一旦泄露，业务敏感信息会直接暴露。
加密目标应当覆盖机密性、完整性和身份认证三个方面。机密性要求WAL文件在传输过程中不可被明文读取；完整性要求文件没有被篡改或替换；身份认证要求归档命令只会把文件发送给经过验证的备份服务器。传输层加密可以解决链路安全，但无法保护已经写到备份服务器磁盘上的文件。文件级加密则可以弥补这一缺口，即使备份服务器被入侵，攻击者拿到的也是密文。两种方式并不互斥，组合使用可以形成更完整的防护。
下面这段配置展示了一个最基础的归档命令，它使用scp直接推送WAL文件，虽然scp本身走SSH，但默认配置没有强制强加密算法，也没有对备份服务器进行额外限制，只能视为最低级别的保护。
# postgresql.conf archive_command = 'scp %p backup@192.168.1.10:/pgwal/%f'
要提升安全性，需要显式指定密钥、算法和命令限制，避免使用密码认证，禁止备份用户执行任意远程命令。接下来会分别介绍具体的实现方案。
二、基于SSH隧道的归档日志加密传输
SSH隧道是最容易落地的归档加密传输方案，因为scp和ssh本身已经内置了加密通道，关键在于配置是否足够严格。推荐做法是在数据库服务器上为postgres系统用户生成一对专用的ed25519密钥，仅用于归档传输，不使用默认的id_rsa，避免与日常运维密钥混用。生成密钥时设置空密码，因为归档命令由postgres进程自动执行，没有交互输入密码的机会。
在备份服务器上创建一个专用系统用户，例如archivebackup，并限制该用户只能使用ssh的强制命令。authorized_keys文件中可以使用command=参数，强制所有使用该公钥的连接只执行接收归档文件的命令，而无法登录shell。这样可以防止数据库服务器被攻陷后，攻击者利用归档密钥登录备份服务器执行任意操作。
# 在数据库服务器上生成专用密钥 sudo -u postgres ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519_archive # 将公钥复制到备份服务器 sudo -u postgres ssh-copy-id -i ~/.ssh/id_ed25519_archive.pub archivebackup@192.168.1.10 # 在备份服务器上编辑authorized_keys，限制该密钥只能执行接收命令 command="cat > /pgwal/$(date +%s)" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... postgres@db-server
接下来在postgresql.conf中配置archive_command，显式指定密钥文件、主机指纹校验、加密算法和MAC算法。SSH客户端支持Ciphers和MACs选项，可以强制使用AES-CTR和HMAC-SHA2系列，避免使用已经被认为不安全的CBC模式或SHA1算法。同时关闭密码认证、禁止使用代理转发，并把连接超时和自动确认主机指纹的参数设置好。下面是一个可用的配置示例。
# postgresql.conf archive_command = 'ssh -i /var/lib/postgresql/.ssh/id_ed25519_archive \ -o StrictHostKeyChecking=yes \ -o UserKnownHostsFile=/var/lib/postgresql/.ssh/known_hosts \ -o PasswordAuthentication=no \ -o Ciphers=aes256-ctr,aes128-ctr \ -o MACs=hmac-sha2-512,hmac-sha2-256 \ archivebackup@192.168.1.10 "cat > /pgwal/%f"'
这种方案的优点是部署简单、无需额外软件，恢复时WAL文件在备份端已经是明文，不需要解密步骤。缺点是只保护了传输链路，备份服务器上的文件仍然是明文，如果备份服务器被入侵或者运维人员误操作，WAL内容还是可能泄露。此外，SSH加密会消耗一定CPU，如果归档频率很高，需要关注数据库服务器的CPU负载。
三、使用GnuPG对归档文件先加密再传输
如果希望备份服务器上存储的归档文件本身就是密文，可以在archive_command中先对WAL文件进行加密，再把密文发送出去。GnuPG是Linux环境下常用的加密工具，支持对称加密和非对称加密。对称加密速度快，适合WAL这种频繁产生的小文件，但密钥需要同时保存在数据库服务器上；非对称加密可以把公钥放在数据库服务器上，私钥只放在恢复环境中，备份服务器即使拿到密文也无法解开。
使用GnuPG对称加密时，需要将密码短语保存在一个只有postgres用户可读的文件里，并确保archive_command调用时不会把密码暴露在进程列表中。gpg提供了passphrase-file参数，可以避免在命令行中直接写密码。加密算法选择AES256，同时使用batch模式避免交互式确认。下面是一个完整的归档命令示例，先将WAL加密为.gpg文件，再通过scp发送到备份服务器，最后删除本地密文以节省空间。
# postgresql.conf archive_command = 'gpg --batch --yes --symmetric \ --cipher-algo AES256 \ --passphrase-file /etc/pgwal/gpg_passphrase \ --output %p.gpg %p && scp %p.gpg archivebackup@192.168.1.10:/pgwal/%f.gpg && rm -f %p.gpg'
这个方案减少了链路被嗅探的风险，同时保证了备份端文件的机密性。不过要注意，恢复时需要先使用同样的密码短语解密，才能把WAL文件用于PITR。如果密码短语丢失，所有归档将无法恢复，因此密钥管理变得非常重要。另外，gpg加密每个WAL文件都会产生额外的进程和CPU消耗，在归档高峰期可能拖慢WAL切换速度。可以在备库上执行归档，避免影响主库性能，但前提是备库有完整的WAL产生机制。
如果使用非对称加密，archive_command可以写成使用recipient参数指定公钥，数据库服务器上不需要保存私钥。这样即使数据库服务器被入侵，攻击者也只能加密而不能解密历史归档。缺点是恢复时需要私钥，必须妥善保管，并且非对称加密的CPU开销明显高于对称加密。
四、借助pgBackRest实现归档加密与备份一体化
pgBackRest是一款功能完整的PostgreSQL备份与恢复工具，它内置了归档推送、压缩、加密和重试机制。与手写scp或gpg脚本相比，pgBackRest可以统一管理归档和全量备份，支持并行处理多个WAL文件，并且经过大量生产环境验证。启用归档加密只需要在pgBackRest的配置文件中指定加密类型和密码，然后把archive_command指向pgBackRest的archive-push命令即可。
pgBackRest支持AES-256-CBC加密，密码可以通过repo1-cipher-pass直接写在配置文件中，也可以通过环境变量或外部密钥文件提供。建议不要把密码直接写在PostgreSQL的postgresql.conf里，而是放在pgBackRest自己的配置文件中，并设置权限为600。配置完成后，pgBackRest会在归档推送时自动对WAL文件和后续备份进行加密，恢复时也会自动解密，不需要手动介入。
# /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/var/lib/pgbackrest repo1-cipher-type=aes-256-cbc repo1-cipher-pass=ChangeThisToStrongPassphrase [mycluster] pg1-path=/var/lib/postgresql/data
# postgresql.conf archive_command = 'pgbackrest --stanza=mycluster archive-push %p'
pgBackRest的方案特别适合同时需要备份和归档加密的环境，因为它把加密、压缩、校验和保留策略放在一个工具里完成，减少了多个脚本之间不一致带来的风险。它的archive-push命令支持异步归档和队列重试，如果备份服务器暂时不可达，归档可以排队等待，而不是直接让PostgreSQL报错。这个机制对生产环境的稳定性帮助很大。
不过，pgBackRest部署和配置比单纯的scp方案复杂，需要额外维护pgBackRest版本和配置文件。另外，如果之前已经使用了其他归档方式，迁移时需要规划一段并行归档期，确保所有旧WAL都被正确处理，避免出现归档漏洞。
五、密钥管理、性能与恢复验证
无论选择哪种加密方案，密钥和密码的管理都是安全闭环中最薄弱的一环。建议把归档加密密码或私钥存放在与数据库服务器、备份服务器分离的第三方位置，例如KMS、硬件HSM或受控的密码库中。对于SSH方案，专用私钥文件权限应设为600，并定期轮换。对于GnuPG和pgBackRest，密码不能出现在shell历史、cron任务或日志文件中。加密策略还应该考虑密码过期和应急恢复场景，防止因为密码丢失导致整个PITR链路失效。
加密对性能的影响主要来自CPU加解密开销和额外的进程调度。现代Intel和AMD处理器大多支持AES-NI指令集，AES加密速度很快，通常不会成为归档瓶颈。但如果数据库产生WAL非常频繁，比如大量小事务、高并发更新，每个WAL文件都单独启动gpg或pgBackRest进程，可能会增加延迟。可以通过调整archive_timeout、增大wal_keep_size减少归档频率，或者在备库上执行归档来分散压力。实践中建议在测试环境用pgbench模拟高负载，观察归档命令是否出现积压。
恢复验证是很多团队容易忽略的环节。加密归档必须定期做恢复演练，确认备份端文件能够正确解密并用于恢复到指定时间点。对于SSH方案，恢复时直接从备份目录复制WAL文件即可；对于GnuPG方案，需要先用相同的密码解密，再复制到恢复目录；对于pgBackRest，恢复命令会自动处理解密和校验。建议至少每季度执行一次异机恢复测试，记录恢复时间和遇到的问题，确保加密没有破坏归档的可用性。
综合来看，如果只要求传输链路安全，SSH隧道方案足够简单可靠；如果要求备份端文件也必须是密文，可以叠加GnuPG加密；如果正在建设完整的备份体系，pgBackRest是更系统化的选择。无论采用哪种方式，都应该把密钥管理、性能监控和恢复演练纳入日常运维流程，才能真正发挥归档日志加密传输的价值。
PostgreSQL归档日志加密传输修改时间：2026-10-03 12:15:46