pgBackRest 停维：PostgreSQL 备份不能只靠维护者硬扛

pgBackRest 的 GitHub 仓库首页，现在最刺眼的不是功能介绍，而是一段“NOTICE OF OBSOLESCENCE”。作者说，经过长期考虑，决定停止维护这个 PostgreSQL 备份恢复项目。

当前稳定版停在 v2.58.0。现有部署不会因为公告就马上失效，备份任务也不会自动停掉。但对生产系统来说，最麻烦的往往不是软件还能不能跑，而是谁继续替你承担维护承诺。

pgBackRest 不是边角料。它承担的是 PostgreSQL 的可靠备份与恢复，支持并行备份恢复、WAL 归档、对象存储、加密、多版本兼容。高写入量、大库、云对象存储归档场景里，这类工具就是灾备链路的一部分。

现有用户别慌，但要立刻盘点

公告里的事实很短：pgBackRest 不再维护，稳定版是 v2.58.0。作者还明确建议，如果有人 fork，请使用新的项目名。新维护者需要重新建立信任。

这句话很重。备份工具不是换个仓库地址就能继承信用。它处理的是最后一道防线。恢复失败时，没人会因为“代码开源”就少追责。

PostgreSQL 运维和 DBA 现在该做四件事。

• 确认线上 pgBackRest 版本、配置和依赖环境。
• 抽样做一次真实恢复演练，不要只看备份日志成功。
• 检查 WAL 归档链路，尤其是对象存储权限、生命周期策略和加密配置。
• 给出短期留用、中期替代、长期迁移的窗口，不要等事故来催。

技术管理者要看的不是“要不要今天换工具”。更现实的问题是：谁负责判断继续用的风险，谁批准迁移成本，谁在恢复失败时承担业务后果。

小团队可能会先观望，维持当前版本，补恢复演练。大团队更可能延后新项目采购，先把备份方案重新评审一遍。金融、SaaS、重数据业务则不该只观望，至少要把替代路线放进季度计划。

作者不是甩手，是拒绝继续透支

公告里，作者把原因讲得很清楚：pgBackRest 是他过去 13 年的 passion project。期间有企业赞助，也有大量深夜和周末投入。Crunchy Data 被出售之后，他继续维护项目，也寻找能让自己继续做这项工作的职位，但没有成功。赞助也不足以让项目继续可行。

这不是突然弃坑。更像是一个维护者终于把账摊开：生产级责任，不能无限挂在个人热情上。

维护这种项目很脏，也很重。修 bug，审 PR，处理 issue，跟 PostgreSQL 新版本兼容，跟对象存储和加密链路磨合。每一项都不性感，但每一项都可能决定恢复时能不能救命。

我更认可作者这次的 hard stop。最危险的开源状态不是停更，而是假装还活着。issue 堆着，PR 晾着，兼容性没人兜底，用户却以为“社区还在”。对数据库基础设施来说，半维护比明牌停维更容易误导人。

限制也要说清。现在没有证据说明 pgBackRest 已经不可用，也没有证据说明出现了安全事故或企业弃用潮。材料只能支持一个判断：原维护者的长期承诺结束了，用户需要重新承担判断成本。

这已经足够严重。

真风险不是免费代码，是免费信任

“天下熙熙，皆为利来。”这句话放在开源里不好听，但准。它不是贬低开源，而是提醒企业：生产级责任必须有生产级付费结构。

很多公司用开源基础设施时，会形成一种顺手的幻觉：代码免费，社区可用，出了问题总有人补。可真正撑住项目的，往往是少数维护者、少数赞助、少数长期不可见的劳动。

备份恢复工具尤其残酷。前端框架坏了，可以回滚。报表系统慢了，可以延迟。备份链路出事，压下来的是业务连续性、数据完整性和合规责任。

所以 pgBackRest 停维后，接下来要观察的不是谁第一时间 fork。更关键的是三件事：

这事也有一点铁路史的影子。不完全一样，但逻辑相似。早期大家兴奋于铁轨铺到哪里，后来才明白，基础设施最贵的不是第一根铁轨，而是几十年养护不出事。

开源也是这样。发布代码只是开端。长期维护才是账单。

pgBackRest 这次停维，把账单递到了 PostgreSQL 用户面前。它不吓人，但很现实：如果你的生产备份链路依赖它，现在就该开一场短会。议题不用大，三句话就够。

还能不能恢复？谁继续负责？如果明天必须迁移，窗口在哪里？