pgBackRest 死了，现在怎么办？

pgBackRest is dead. Now what?

多年来，我一直将 pgBackRest 推荐为 PostgreSQL 最好的备份工具。我甚至为此写过一篇博文。我在里昂第一大学（Université Lyon I）的学生们在对该工具零基础的情况下，仅用四个小时就学会了如何进行备份、恢复以及执行 PITR（基于时间点的恢复）。它就是这么出色。我说“曾经”是因为 pgBackRest 的唯一维护者 David Steele 已经在项目的 GitHub 页面上宣布，他将停止该项目的所有工作。他的原话是：不再维护、不再修复 Bug、不再审查 PR、不再开发新功能。从今天起，pgBackRest 已处于无人维护状态。

I have been recommending pgBackRest as the best backup tool for PostgreSQL for years. I even wrote a blog post about it. My students at Université Lyon I were able to backup, restore, and perform PITR in four hours with zero prior knowledge of the tool. That is how good it was. I say “was” because David Steele, the sole maintainer of pgBackRest, has announced on the project’s GitHub page that he is stopping all work on the project. His words: no more maintenance, no more bug fixes, no more PR reviews, no more new features. pgBackRest is, as of today, unmaintained.

在做任何事之前，我要感谢 David 十三年来卓越的工作。我还要提到两位为 pgBackRest 的成就做出巨大贡献的人：Stephen Frost 和 Stefan Fercot（社区中被称为 PGStef），以及许多其他让该项目达到今日高度的贡献者。pgBackRest 是工程领域的杰作。它能在如此精简的核心团队下达到这种质量和可靠性，这本身就非常了不起。David、Stephen、Stefan：谢谢你们。

Before anything else, I want to thank David for thirteen years of exceptional work. I also want to name two people who contributed enormously to making pgBackRest what it is: Stephen Frost and Stefan Fercot, known in the community as PGStef, along with many other contributors whose work made the project what it became. pgBackRest is a masterpiece of engineering. The fact that it reached this level of quality and reliability with such a small core team makes it all the more remarkable. David, Stephen, Stefan: thank you.

发生了什么？

What happened

David 的解释很清晰，没有怨言。Crunchy Data 在 pgBackRest 大部分生命周期里一直为其提供赞助并雇佣了 David，但后来该公司被出售了。此后，David 花了几个月时间寻找能让他继续从事该项目的工作，也尝试过寻求独立赞助，但都没有成功。他需要谋生，而该项目需要持续的投入，如果得不到报酬，他已无法再提供这种投入。这不仅仅是一个人未能获得资助的故事，这是 2026 年 IT 行业及其价值观的缩影。

David explains it clearly, without bitterness. Crunchy Data, which had sponsored pgBackRest for most of its life and employed David, was sold. After that, David spent months looking for a position that would let him keep working on the project. He also tried to secure independent sponsorship. Neither worked out. He needs to make a living. The project needs sustained effort that he can no longer provide without being paid for it. This is not a story about one person failing to find funding. This is a story about the IT industry in 2026, and what it values.

没人愿意大声说出的真相

The thing nobody wants to say out loud

David 是一位杰出的工程师。他花了十三年时间构建了 PostgreSQL 生态系统中最可靠的基础设施之一。他试图找到一家公司雇佣他继续做这件事，但他们不感兴趣。他们忙着购买内存和配置 GPU。AI 的淘金热彻底重塑了公司认为值得付费的项目，显然，“确保你的数据在灾难中幸存的人”并没有入选。写下这些让我很难受，因为 David 是我的朋友，Stefan 和 Stephen 也是。眼睁睁看着一个如此优秀的项目消亡，不是因为技术故障或社区不和，而是因为行业认为大语言模型比数据完整性更重要，这令人愤怒，也令人悲伤。

David is a brilliant engineer. He spent thirteen years building one of the most reliable pieces of infrastructure in the PostgreSQL ecosystem. He tried to find a company that would hire him to keep doing exactly that. They were not interested. They had RAM to buy and GPUs to provision. The AI gold rush has thoroughly reshuffled what companies consider worth paying for, and apparently “the person who makes sure your data survives a disaster” did not make the cut. I find that hard to write, because David is a friend. So are Stefan and Stephen. Watching a project this good die not because of a technical failure or a community falling-out, but because the industry decided that large language models matter more than data integrity, is infuriating. And sad.

关于开源契约

What about the open source contract

大型公司在 pgBackRest 之上赚取了巨额利润。它被部署在数百个组织的生产环境中，其中一些公司直接基于 PostgreSQL 生态系统构建了利润丰厚的数据库服务。项目 README 中有一个赞助链接，但在 David 发布公告时，只有一个活跃的赞助商。我不想说教任何人，但如果贵公司的灾难恢复策略多年来一直依赖 pgBackRest，而你们从未做出任何回馈，现在是时候好好反思一下了。开源模式在消费者也参与维护时才能运作，当每个人都假设别人会支付维护费用时，它就会崩溃。这就是崩溃的样子。

Large companies have made enormous amounts of money on top of pgBackRest. It is deployed in production at hundreds of organizations, including some with very profitable database services built directly on the PostgreSQL ecosystem. The project README had a sponsorship link. There was one active sponsor at the time David made his announcement. I am not going to lecture anyone. But if your company’s disaster recovery strategy has relied on pgBackRest for years and you never contributed anything back, this is a good moment to sit with that. The open source model works when the people consuming the value also contribute to sustaining it. It breaks when everyone assumes someone else will pay for the maintenance. This is what that breaking looks like.

pgBackRest 的本质，以及为什么替代方案不够好

What pgBackRest actually was, and why alternatives fall short

让我明确一下社区正在失去什么，因为我认为大多数人都低估了它。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 归档、备份目录、保留管理和恢复。这是一个合理的选择。

Let me be precise about what the community is losing, because I think most people underestimate it. pg_basebackup is not a backup tool. I have said this many times, and Magnus Hagander, who created pg_basebackup and is a member of the PostgreSQL core team, agreed with me publicly. In this exchange on Twitter, I wrote: “Pg_basebackup thinks backups. People actually need a tool that thinks recovery. The backup is just a step in the middle of the process, not the end of it.” Magnus replied: “That may be one of the best descriptions of the limits both of pg_basebackup and of the postgres apis for backups I’ve seen so far! Fully agreed!” pg_basebackup was designed to clone a running cluster directory. It has no backup catalog, no WAL retention management, no restore command, and no built-in integrity verification before PostgreSQL 13. It is an excellent tool for setting up standbys. It is not a recovery strategy. pg_dump is even further from the mark. Beyond the obvious absence of PITR, meaning that any transaction between the moment your dump started and the moment you need to restore is gone forever, the restore time for a large dump is the time you do not have during an incident. I prefer to call pg_dump an export tool, because that is what it is. Calling it a backup tool creates a false sense of security that has caused real data loss. Barman exists, is actively maintained, and has improved significantly. For organizations that need an alternative today, it is the serious option. It carries the architectural weight of having been built on top of pg_basebackup’s limitations rather than starting from scratch, but it covers the critical gaps: WAL archiving, backup catalog, retention management, and restore. It is a legitimate choice.

pgBackRest 用户接下来该怎么办

What comes next for pgBackRest users

David 本人也预计 pgBackRest 最终会被分叉（fork）。我也这么认为。代码库是扎实的 C 语言，架构合理，PostgreSQL 生态系统中也有具备足够技术深度的公司可以接手。我希望其中一家或几家公司能站出来。正如 David 所指出的，他们需要从零开始建立社区信任，但基础非常出色。目前分叉尚未出现。在此之前，我的建议是：如果你今天正在评估备份工具，请使用 Barman。如果你正在生产环境运行 pgBackRest，你目前没有直接危险，但随着每一个新的 PostgreSQL 版本发布和每一个未修复的 Bug 出现，你的窗口期正在缩小。如果在此期间你在 pgBackRest 中发现了关键 Bug，像 Data Egret 和 Cybertec 这样的公司拥有能够帮助你的 PostgreSQL 专业知识。

David himself expects pgBackRest to be forked eventually. So do I. The codebase is solid C, the architecture is sound, and there are companies in the PostgreSQL ecosystem with the technical depth to take it on. I hope one or several of them step up. They will need to build community trust from scratch, as David notes, but the foundation is exceptional. That fork has not happened yet. Until it does, here is what I recommend. If you are evaluating backup tools today, use Barman. If you are running pgBackRest in production, you are not in immediate danger, but your window is narrowing with every new PostgreSQL release and every bug that goes unpatched. If you find a critical bug in pgBackRest in the meantime, companies like Data Egret and Cybertec have the PostgreSQL expertise to help you.