企业官网建设流程全解析

pgBackRest 已死。接下来怎么办？

** 摘要：** 本文宣布了 pgBackRest 的终止运营。pgBackRest 是顶级的 PostgreSQL 备份工具，在经过十三年的开发后，由唯一的维护者 David Steele 宣布停止维护。本文探讨了该项目终止的原因，包括缺乏商业赞助以及 IT 行业向 AI 优先级倾斜而非数据完整性基础设施的转变，同时为需要迁移的用户提供了 Barman 等替代方案。

2026 年 4 月 27 日 · 1224 字 · 6 分钟阅读

原文链接

多年来我一直推荐 pgBackRest 作为 PostgreSQL 最佳备份工具。我甚至为此写了一篇博客文章。我在里昂第一大学的学生们仅用四个小时就学会了备份、恢复和执行 PITR，且对该工具毫无了解。这就是它的优秀程度。

我说"曾经优秀"，是因为 pgBackRest 的唯一维护者 David Steele 在项目 GitHub 页面上宣布他将停止项目的所有工作。他的原话是：不再维护、不再修复 bug、不再审查 PR、不再开发新功能。从今天起，pgBackRest 处于无人维护状态。

在进入正题之前，我想感谢 David 十三年来的出色工作。我还要提及两位为 pgBackRest 做出巨大贡献的人：Stephen Frost 和 Stefan Fercot，他在社区中被称为 PGStef，以及许多其他贡献者，正是他们的工作成就了这个项目。pgBackRest 是工程学的杰作。考虑到核心团队如此之小，它能达到如此高的质量和可靠性水平，更加令人敬佩。David、Stephen、Stefan：谢谢你们。

发生了什么

David 解释得很清楚，毫无怨气。Crunchy Data 多年来一直是 pgBackRest 的赞助商，并雇佣了 David，后来被出售。之后，David 花了好几个月寻找能够让他继续从事该项目的工作。他也尝试过寻求独立赞助。两者都没有成功。他需要谋生。这个项目需要持续的努力，而他无法在不获得报酬的情况下继续提供。

这不是一个关于某个人找不到资金的故事。这是关于 2026 年 IT 行业以及它所重视的事物的故事。

没人想说出口的事

David 是一位杰出的工程师。他花了十三年时间构建了 PostgreSQL 生态系统中可靠性最高的基础设施之一。他试图找一家公司雇佣他，让他继续做这件事。

他们不感兴趣。他们需要购买 RAM 和配置 GPU。AI 热潮已经完全重塑了公司认为值得付费的东西，显然"确保你的数据在灾难中存活的人"未能入选。

我很难写出这些文字，因为 David 是朋友。Stefan 和 Stephen 也是。看着如此优秀的项目消亡，不是因为技术失败或社区纷争，而是因为行业认为大型语言模型比数据完整性更重要，令人愤怒且悲哀。

开源契约怎么了

大型公司基于 pgBackRest 赚取了大量金钱。它在数百家组织的生产环境中部署，包括一些基于 PostgreSQL 生态系统的盈利性数据库服务。项目 README 中有一个赞助链接。在 David 宣布时，只有一位活跃的赞助商。

我不会教训任何人。但如果你们公司的灾难恢复策略多年来依赖 pgBackRest 而你从未做出任何贡献，现在是时候反思一下了。

开源模式在消耗价值的用户也为维护做出贡献时才能运作。当每个人都认为别人会为此买单时，它就会崩溃。这就是崩溃的样子。

pgBackRest 实际上是什么，为什么替代方案不尽如人意

让我详细说明社区正在失去什么，因为我认为大多数人都低估了这一点。

pg_basebackup不是备份工具。我多次说过这句话，创建 pg_basebackup 且是 PostgreSQL 核心团队成员的 Magnus Hagander 在公开场合同意了我的观点。在Twitter 上的这段交流中，我写道："Pg_basebackup 以备份的思维思考。人们实际上需要一个以恢复思维思考的工具。备份只是过程中的一个步骤，而不是终点。Magnus 回复道：“这可能是我见过的对 pg_basebackup 和 postgres 备份 API 局限性的最好描述之一！完全同意！”

pg_basebackup设计用于克隆运行中的集群目录。它没有备份目录、没有 WAL 保留管理、没有恢复命令，而且在 PostgreSQL 13 之前没有内置的完整性验证。它是设置备库的优秀工具，但不是恢复策略。

pg_dump离题更远。除了明显缺少 PITR（意味着从开始转储到你需要恢复之间的任何事务都永远丢失）之外，大型转储的恢复时间正是你在事故期间没有的时间。我更愿意称 pg_dump 为导出工具，因为它就是这样。称它为备份工具会产生一种虚假的安全感，已经导致了真实的数据丢失。

Barman存在，正在积极维护，而且有了显著改进。对于今天需要替代方案的组织，它是严肃的选择。它继承了因建立在 pg_basebackup 局限性之上而非从头开始而产生的架构负担，但它覆盖了关键空白：WAL 归档、备份目录、保留管理和恢复。这是一个合法的选择。

pgBackRest 用户接下来怎么办

David 本人预计 pgBackRest 最终会被 fork。我也是如此。代码库是可靠的 C 语言，架构也很合理，PostgreSQL 生态系统中有多家公司具备这样的技术深度来接手。我希望他们中有一家或几家站出来。正如 David 所说，他们需要从头开始建立社区信任，但基础是卓越的。

这个 fork 尚未发生。在此之前，这是我的建议。

如果你今天正在评估备份工具，请使用Barman。如果你在生产环境中运行 pgBackRest，你没有立即的危险，但随着每个新的 PostgreSQL 版本发布和每个未修复的 bug，你的窗口正在缩小。如果你在此期间发现 pgBackRest 中的关键 bug，Data Egret 和 Cybertec 这样的公司拥有 PostgreSQL 专业知识来帮助你解决。这不是长期解决方案，但它为你争取了时间，让社区弄清楚接下来会发生什么。

结语

我在 PostgreSQL 生态系统中已经工作了二十年。我见过工具来了又走。我见过项目停滞、被 fork、复兴，偶尔也彻底消失。这是开源运作方式的一部分。

但 pgBackRest 与众不同。它是我整个职业生涯中使用过的设计最精良的工具之一。它以正直的态度构建，以关怀的方式维护，被那些工作依赖于数据在最坏情况下存活的用户所信任。看着它走到这一步，不是因为 David 的任何失败，而是因为行业目前对下一个 AI 产品的兴趣超过了构建可靠基础设施的人，这让我既愤怒又悲伤。

PostgreSQL 生态系统充满了做关键工作的杰出人才，他们的资金往往脆弱或不存在。pgBackRest 不会是最后一个走到这一步的项目。我希望它至少是让公司在把开源基础设施视为没有附加义务的免费资源之前三思而后行的那个。

David 构建的东西将比这个时刻更长久。我确信这一点。我只是希望社区会站出来迎接它。

标签：PostgreSQL、管理、开源