在 PostgreSQL 备份领域，Barman（Backup and Recovery Manager）凭借其对多服务器集中管理、WAL 归档与 PITR（Point-in-Time Recovery）的原生支持，已成为企业级灾备架构的核心组件。继前文探讨 WAL 归档机制后，本文聚焦 Barman 两大核心技术能力：基于 rsync 的文件级增量去重备份机制，以及面向 S3 兼容对象存储的云端备份集成方案。这两项能力共同支撑了大规模 PostgreSQL 集群在存储成本与恢复效率之间的平衡设计。
rsync 文件级增量去重的技术原理
Barman 的增量备份能力分为两条技术路径：文件级增量备份（rsync-based）与块级增量备份（pg_basebackup with PostgreSQL 17+）。本文重点阐述前者，因其实现机制独特且对存储效率提升显著。
核心实现依赖于硬链接（hard link）机制。当首次执行全量备份时，Barman 将 PostgreSQL 数据目录完整复制至备份存储路径。后续执行增量备份时，rsync 进程逐文件比对源端与目标端的差异仅传输变更数据块，而对于未变更的文件，Barman 通过创建硬链接将其指向上一备份中对应的物理文件。这意味着多个备份版本可以共享同一份未变更的数据库文件，磁盘占用仅为一份真实数据的空间。
启用该特性需在 Barman 配置中设置 reuse_backup 参数。作用域可设为全局（barman.conf）或单服务器配置（/etc/barman.d/pg-server.conf）。典型配置片段如下：
[pg-server]
backup_method = rsync
reuse_backup = link
retention_policy = RECOVERY POINT OF TIME '2026-05-03 00:00:00'
参数 reuse_backup = link 即触发硬链接复用逻辑；设为 copy 则退化为传统全量复制模式。需特别注意的是，rsync 文件级增量备份与 PostgreSQL 17 引入的块级增量备份（--incremental 参数）属于互斥策略，同一备份链中严禁混用，否则会导致恢复时数据不一致。
工程实践中有两个关键监控点：其一，备份链完整性 —— 当父备份被意外删除而子备份仍保留硬链接时，会产生 “孤岛文件”，Barman 在执行 barman check 时会检测并报警；其二，磁盘 inode 消耗 —— 硬链接虽不占用额外磁盘空间，但仍消耗 inode 节点，极端大量备份场景下需关注文件系统 inode 配额。
barman-cloud-backup 与 S3 兼容存储的集成架构
传统 Barman 部署将备份存储于本地磁盘或 NFS 挂载卷，但现代云原生架构越来越多地将备份数据推送至 S3 兼容对象存储，以实现跨区域灾备与更低成本的长期保留。Barman 通过 barman-cloud-backup 工具链提供云端备份能力，该工具独立于主 Barman 守护进程运行，支持将基线备份（base backup）与 WAL 归档上传至云端。
配置流程涉及三个层面：一是凭证管理，Barman 支持通过环境变量（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY）或 IAM 角色（EC2 实例角色）进行 S3 认证，生产环境推荐使用 IAM 角色以避免硬编码密钥；二是目标存储定义，需在 Barman 配置中指定 endpoint、bucket 名称及路径前缀；三是备份策略编排，结合 retention_policy 实现本地缓存与云端归档的分层存储。
以下为云存储后端的典型配置：
[pg-server-cloud]
backup_method = postgres
cloud_provider = aws-s3
s3_bucket = barman-backup-prod
s3_endpoint_url = https://s3.amazonaws.com
s3_region = us-east-1
incoming_wals_directory = /var/lib/barman/pg-server/incoming
其中 backup_method = postgres 指定使用 pg_basebackup 进行基线备份；cloud_provider 可选值包括 aws-s3、azure-blob、google-gcs 等主流云存储。Barman 3.15+ 版本进一步增强了云端 WAL 归档能力，支持将 WAL 段直接流式上传至 S3，实现 RPO（恢复点目标）趋近于零的连续归档。
恢复操作与本地备份一致。执行 barman recover 时指定云端备份 ID，Barman 自动从 S3 下载所需数据至本地临时目录，再完成恢复流程。对于大规模数据库，可通过 barman-cloud-restore 的并行下载参数（--parallel）加速数据传输。
工程落地的关键参数与监控清单
综合上述两大技术方向，以下是生产环境部署的核心参数建议：
rsync 去重备份：启用 reuse_backup = link；设置合理的 retention_policy（建议保留至少 2 个全量备份周期）；每月执行一次 barman check --check-all 验证备份链完整性；监控 /var/lib/barman 所在分区的 inode 使用率。
S3 云端备份：生产环境启用 server-side-encryption（SSE-KMS）；配置 backup_compression = gzip 减少上传流量与存储成本；设置生命周期策略（如 Glacier Deep Archive 规则）自动归档超过 90 天的备份；监控 S3 请求费用与数据转出流量。
两项能力可协同工作：本地 rsync 备份链提供快速恢复能力，云端对象存储作为异地灾备目的地，形成「本地增量去重 + 云端冷存储」的双层架构。此架构已在多个大型互联网企业的 PostgreSQL 集群中验证，典型场景下可实现 60% 以上的存储成本节约。
参考资料
- Barman 官方文档：Backups — Barman 3.17.0（https://docs.pgbarman.org/release/3.17.0/user_guide/backup.html）
- EnterpriseDB：Barman Cloud - Part 2: Cloud Backup（https://www.enterprisedb.com/blog/barman-cloud-part-2-cloud-backup）