2024 年底，PostgreSQL 社区最具影响力的开源备份工具 PgBackRest 在其 GitHub 仓库发布了正式的「弃用声明」（Notice of Obsolescence），宣布项目正式停止维护。这一消息对于全球数万家依赖 PgBackRest 进行数据库灾备的企业而言，意味着必须重新审视备份架构的长期可持续性。本文将从工程实践角度，分析停更对生产环境的具体影响，提取 PostgreSQL 备份工具选型的关键评估维度，并给出从 pgBackRest 迁移至替代方案的可执行路径。
PgBackRest 停更的核心影响
PgBackRest 由开发者 Cynthia（crunchydata 前员工）独立维护长达十三年，曾获得 Crunchy Data、Supabase 和 Resonate 的赞助。在 2.58.0 版本之后，项目正式进入「不再维护」状态，这意味着三件事直接关系到生产系统的安全。
首先是安全更新的断裂。PostgreSQL 每年发布一个大版本，每个版本有五年的支持周期。pgBackRest 需要跟进这些版本变化以确保兼容性，尤其是涉及新版本特有的系统目录结构、WAL 格式变更和新增配置参数。没有后续维护意味着当企业升级 PostgreSQL 主版本时，备份工具可能无法正确识别新的数据库结构，导致备份失败或恢复时数据丢失。
其次是故障支持的缺失。pgBackRest 的设计复杂度较高 —— 支持并行备份与恢复、多仓库架构、块级增量备份、S3/Azure/GCS 对象存储集成、仓库加密等功能。在实际生产中，运维团队经常会遇到备份卡住、仓库一致性校验失败、WAL 归档延迟等非预期问题。社区活跃时，这些问题通常能在 GitHub Issue 中快速获得响应或找到 workaround；但项目停更后，运维团队只能依靠内部力量排查，或者在社区论坛中寻找历史记录，响应效率大幅下降。
第三是生态兼容性的滞后。随着云原生技术栈的普及，Kubernetes Operator、GitOps 流程、Prometheus 监控集成等需求日益普遍。pgBackRest 缺乏官方的 Operator 支持，虽然社区有一些非官方的实现，但缺乏持续更新。云厂商的托管 PostgreSQL 服务（如 Amazon RDS、Azure Database for PostgreSQL、Google Cloud SQL）也在持续引入新特性，停更的工具无法保证与这些新特性的兼容性。
备份工具选型的工程化评估维度
面对 pgBackRest 的停更，企业有两条主要路径：一是在内部 Fork 并自主维护该项目，二是迁移到其他活跃维护的开源或商业备份方案。对于大多数企业而言，后者是更务实的选择。当前 PostgreSQL 生态中，活跃维护且功能完备的替代工具主要是 Barman 和 WAL-G 两者。以下六个维度构成工程化评估的核心框架。
一、备份类型与增量能力。 pgBackRest 的核心优势之一是支持全量、差异和增量三种备份模式，且增量备份可在文件级和块级执行。Barman 通过 rsync 实现增量备份，在网络条件良好的环境下效率尚可，但在跨地域备份场景中不如 pgBackRest 的块级增量高效。WAL-G 的设计哲学不同 —— 它强调持续归档 WAL 段到对象存储，配合增量 base backup 实现类似效果，在云存储环境中的增量效率非常出色。如果企业的核心诉求是 TB 级数据库的增量备份效率，WAL-G 更接近 pgBackRest 的体验。
二、存储后端与云原生集成。 三款工具都支持 S3、Azure Blob、GCS 等对象存储，但集成深度有差异。pgBackRest 和 WAL-G 将对象存储作为一等公民设计，备份数据直接写入存储桶，无需额外的中间层。Barman 传统上以文件系统为中心，虽然通过 barman-cloud 子命令也支持云存储，但配置复杂度较高。对于已深度绑定 AWS S3 或 Google Cloud Storage 的云原生架构，WAL-G 的对接成本最低；如果企业仍在使用本地存储或 NFS，Barman 的成熟文件系统操作经验更具参考价值。
三、恢复点目标（RPO）与恢复时间目标（RTO）的支撑能力。 pgBackRest 支持并行恢复和增量恢复（delta restore），在 TB 级数据库的恢复场景中表现优异。Barman 的恢复能力同样成熟，但并行度配置相对复杂。WAL-G 在持续 WAL 归档方面有天然优势 ——WAL 段一旦生成即推送至对象存储，理论上可以实现秒级的 RPO；但在超大规模数据库的并行恢复方面，WAL-G 的性能略逊于 pgBackRest。评估时需要结合企业的 RPO/RTO 指标：如果 RPO 要求极高（如金融交易系统），WAL-G 的持续归档机制更匹配；如果 RTO 极端敏感（如 24/7 业务系统），pgBackRest 的并行恢复能力是重要参照。
四、运维复杂度与团队学习曲线。 pgBackRest 的配置以 ini 风格配置文件为主，命令行直观，单一实例的管理门槛较低。Barman 的设计目标是「企业级集中备份管理」，支持通过单一控制平面管理数十台 PostgreSQL 实例，配置模型更复杂，功能更丰富但学习曲线更陡。WAL-G 的配置极度简洁，大量使用环境变量，适合偏好代码化运维（Infrastructure as Code）的团队。三者的监控接口均为 Prometheus friendly，集成难度相当。
五、许可证与商业支持。 pgBackRest、Barman 和 WAL-G 均为开源项目，采用 PostgreSQL 社区通用的许可证（pgBackRest 为 GPLv3，Barman 为 GPLv3，WAL-G 为 Apache 2.0）。如果企业需要商业级的技术支持，Crunchy Data 为 Barman 提供商业支持服务，ElephantSQL（EDB）也有相关的企业服务产品；WAL-G 目前主要依赖社区支持，商业支持选项较少。
六、社区活跃度与长期可持续性。 截至 2025 年底，Barman 由 2ndQuadrant（现为 EDB 旗下）持续维护，更新频率稳定；WAL-G 由 widatama（俄罗斯团队）主导开发，GitHub Star 数已超过 pgBackRest，功能迭代活跃。两者都有健康的贡献者社区，可预见的未来不存在停更风险。
从 pgBackRest 迁移的实施路径
迁移备份工具是一项高风险操作，必须在测试环境充分验证后再推进生产。以下是推荐的迁移步骤。
第一步是完整审计现有配置。运维团队需要导出 pgBackRest 的全部配置文件（通常位于 /etc/pgbackrest.conf 或用户家目录），梳理所有备份策略参数：repo 路径、存储类型、压缩算法（lz4/zstd）、加密密钥、保留策略（retention-full、retention-diff）、WAL 归档参数（archive-push、archive-get）、以及任何自定义的 stanza 配置。这一步的目的是确保迁移后的新工具能够完整覆盖原有功能。
第二步是选型验证与概念验证（PoC）。在测试环境中搭建与生产相同规模的 PostgreSQL 实例，分别使用 Barman 和 WAL-G 执行完整的备份 - 恢复循环。重点验证三个场景：全量备份与恢复、增量备份与增量恢复（针对 WAL-G）、以及 Point-in-Time Recovery（PITR）到任意时间点。记录每种工具的备份耗时、存储空间占用、恢复耗时三个核心指标，与 pgBackRest 的历史数据进行对比。如果企业有多个 PostgreSQL 集群，建议选取业务压力最大的集群进行最严格的测试。
第三步是双跑期（Dual Run）。在生产环境启动新工具的备份任务，同时保留 pgBackRest 的现有备份任务，周期建议为两到四周。双跑期间，两套备份系统并行运行，日常恢复测试优先使用新工具的备份，验证数据一致性和恢复流程的完整性。这一阶段的目标是建立对替代工具的信心，并排查可能遗漏的配置细节。
第四步是切换与监控。确认新工具的备份稳定可用后，将生产环境的备份任务切换到新工具，同时保留 pgBackRest 的备份作为应急备份（在新的备份出现问题时可以回滚）。新工具上线后需要强化监控：备份任务执行状态、备份大小趋势、WAL 归档延迟、恢复测试结果。建议将备份监控指标纳入现有的 Prometheus + Alertmanager 告警体系，设置「备份失败超过 X 小时」的告警阈值。
第五步是清理与归档。确认切换成功后，可以安排清理旧的 pgBackRest 仓库数据（注意按照保留策略计算好需要保留的最老备份时间点，避免误删仍需保留的历史备份）。建议将 pgBackRest 的配置文件和迁移过程文档归档，以备未来审计或回溯需要。
评估清单与关键参数
以下是面向工程团队的快速评估清单，可在选型时逐项核对。
在功能覆盖方面，需要确认新工具是否支持全量 / 差异 / 增量三种备份模式，是否支持并行备份与恢复，是否支持 S3/Azure/GCS 对象存储，是否支持仓库端加密，是否支持 PITR 恢复至任意时间点，是否支持备份一致性校验（checksum 验证）。在运维友好性方面，需要评估配置复杂度（是否支持配置文件或仅支持环境变量），是否有官方 Docker 镜像或 Kubernetes Operator，是否有完善的官方文档和社区示例，是否支持 Prometheus 监控指标导出。在性能基准方面，建议在测试环境中跑出全量备份吞吐量（MB/s）、增量备份时间占比、恢复耗时（TB 级数据库）三个数据，与 pgBackRest 的历史数据做对比。
此外，一些具体的参数配置值得在迁移时特别关注。WAL-G 方面，推荐配置 WAL_COMPRESSION 方法为 lz4 或 zstd（zstd 压缩比更高但 CPU 开销略大），环境变量 WALG_S3_PREFIX 设置存储路径，WALG_PGP_KEY_PATH 指向加密密钥文件（如果使用加密），backrest 后台建议使用 systemd timer 定时执行。Barman 方面，barman.conf 中的 bandwidth_limit 和 bwlimit_bytes_per_second 控制网络带宽，retention_policy 按天或按备份数设置，backup_options 中启用 parallel_backup 可开启并行备份，cron job 中通过 barman check 和 barman backup 进行调度。
小结
PgBackRest 的停更不是意外，而是开源项目生命周期管理的常态案例。对于依赖该工具的企业，关键是尽快完成影响评估并启动迁移计划。Barman 和 WAL-G 是当前最成熟的两条替代路径 —— 前者适合多实例集中管理的传统企业运维场景，后者适合云原生、对象存储优先的现代架构。无论选择哪条路径，都应在测试环境完成完整的备份 - 恢复验证，在生产环境经历双跑期后再正式切换，确保灾备能力在过渡期间不出现空窗期。备份是数据库安全的最后一道防线，工具的更替不应成为风险敞口，而应成为优化备份架构的契机。
参考资料
- PgBackRes t GitHub 仓库官方停更声明（Notice of Obsolescence）：https://github.com/pgbackrest/pgbackrest
- 2ndQuadrant Barman 官方文档：https://docs.pgbarman.org/
- WAL-G 项目 GitHub 仓库：https://github.com/wal-g/wal-g