PG 備份事實標準 pgBackRest 停止維護

4 月 27 日，PostgreSQL 生態里最重要的備份工具 pgBackRest 被作者 David Steele 正式歸檔了。

聲明發在 GitHub 和 LinkedIn 上，干凈利落：

停止維護公告

簡而言之：pgBackRest 已不再維護。如果你基于 pgBackRest 創建分叉項目，請為你的項目另取一個新的名稱。

經過反復思量，我決定停止繼續維護 pgBackRest。這并不是一個輕率的決定。過去十三年里，pgBackRest 一直是我傾注熱情的個人項目；期間我很幸運，在相當長的一段時間里得到了企業贊助，但我也投入了無數個深夜和周末，和眾多貢獻者一道，才把 pgBackRest 做成了今天的樣子。每一位開源開發者都明白我在說什么，也都知道，一個真正珍視的項目會占據生命中多大的一部分。

自 Crunchy Data 被出售以來，我一直在繼續維護 pgBackRest，同時也在尋找一份能夠讓我延續這項工作的職位，但到目前為止并未如愿。同樣，我為項目爭取贊助的努力，也遠未達到讓這個項目可持續運轉所需的程度。

和所有人一樣，我也需要謀生，而與 pgBackRest 相關的崗位選擇非常有限。現在我可以考慮更廣泛的機會，但這些機會不會給我留下足夠時間繼續投入 pgBackRest。這個項目的維護、缺陷修復、PR 審查、問題回復等等，都需要相當多的時間，更不用說開發新功能了，而那才是我真正熱愛的部分。與其勉強地、斷斷續續地把事情做得不夠好，我認為不如明確地停下來。

我想，pgBackRest 終有一天可能會被分叉出去。但那將是一個由新維護者負責的新項目，他們也需要像我們當初一樣，重新建立起大家的信任。

最后，再次感謝多年來所有 pgBackRest 的貢獻者。能與你們共事，是我的榮幸。

對PG用戶來說，這不是一件小事

pgBackRest 是 PostgreSQL 備份恢復的事實標準，也是很多 DBA 心里最能打的恢復工具。 許許多多多 PostgreSQL DBaaS 都用它作為備份方案，Pigsty 的默認備份方案也是它。

pgBackRest 把 PostgreSQL 備份這件事做到了極致：

?并行備份與并行增量恢復，將恢復窗口縮短至極致。?把原本繁瑣的 PITR（基于時間點恢復）壓縮成一條簡單的命令?優雅地解決了備份歸檔、倉庫管理、對象存儲集成 等問題?全量、差異、增量備份，塊級壓縮與加密，多倉庫異步歸檔，從 standby 備份…… 所有 DBA 在備份場景上能想到的需求，它都做了，做得穩，做得好

老馮十年前第一次給數據庫選備份方案的時候選了它，前陣子重新做了一次選型，把市面上所有活躍方案重新評估了一遍，結果還是它。 當年 2.0 剛出來時，我還手工翻譯了它的文檔。上個月還用 Claude 。

這個工具用了快十年，我非常信賴它。而現在它的唯一維護者把倉庫歸檔了。

故事的真正背景

David 在告別聲明里說得很清楚：他沒有融到能讓自己繼續做這件事的錢。

David 之前是 Crunchy 的架構師，Crunchy 是一家 PostgreSQL 服務公司。 去年 6 月，數據湖倉巨頭 。

收購完成之后，David 花了幾個月時間，想在新東家或別處找一個能讓他繼續維護這個項目的崗位，然而失敗了。 他也嘗試自籌獨立贊助，但離能維持生活的水平差得很遠。他得養家糊口，于是決定干凈利落地停下，而不是斷斷續續敷衍下去。

這里有一個讓人非常不舒服的事實：Snowflake 是當下數據基礎設施領域市值最高的幾家公司之一， 他們公開說要做 “AI-native Postgres”，花了 2.5 億美元買下 Crunchy。但從結果看，并沒有繼續支持 David 維護 pgBackRest。 一個原本在小公司里都能養得起的人，到了大公司反而養不起了。

如果這個推測成立，說損人不利己都算客氣的。Snowflake 省不下多少錢，卻順手把整個 PostgreSQL 生態最重要的一根承重柱給抽了，這不是商業理性，這是吃相太難看。

這一波 AI 淘金熱已經把企業的預算清單徹底重塑了。買內存、買 GPU、買 token，是確定能講出 ROI 故事的； 養一個保證你的數據庫炸了之后還能恢復回來的人，沒有 ROI 故事，只有“什么壞事都沒發生”，而“什么壞事都沒發生”在董事會面前是不算分的。

大家在討論什么

事件發生后這幾天，PG 社區已經熱鬧起來了：Hacker News 上 200 多分的討論、各家廠商博客的連環回應、郵件列表里的 “接下來怎么辦”。 討論大致分幾個方向。

一是開源可持續性的診斷。 主流觀點是：開源可持續性靠的不是施舍，而是下面的良性循環： “公司投資工程師 → 軟件創造價值 → 用戶購買商業支持 → 公司再投資”。 pgBackRest 的失敗，是這個閉環沒建立起來。 只有一家公司的工程師在維護，沒有形成多家廠商商業支持的網絡。 一旦這家公司被并購、戰略調整，整條鏈路就斷了。

二是要不要立刻 fork。 大廠的態度高度一致：先不要急著 fork。 “不要出現十個 fork、每個由一個人維護。” 這種碎片化才是最糟糕的結局。 Linux Foundation 推出 Valkey 替代 Redis 用了六天緊急協調，多廠商共治這種事，慢一點比亂一點要好得多。

三是 fork 的命名問題。 David 在告別聲明里明確表態： “我希望它早晚會被 fork，但那將是一個新項目、由新的維護者負責，他們需要像我們當年那樣從頭建立信任。” 也就是說，新項目不能再叫 pgBackRest。

老馮個人是站 David 這個要求的。這恰恰是他離開時最負責任的一個動作。 備份工具是供應鏈攻擊的最高價值靶子之一：一個被廣泛信任的備份程序，如果在某次升級里被植入惡意代碼， 能在幾乎所有部署它的 PostgreSQL 實例里獲得核心權限，接觸到全部歷史數據。 把 “幾千 stars 積累的信任” 原封不動轉讓給一個未知接班人，不是慷慨，是不負責任。 讓 fork 重新換個名字，是逼著用戶重新做一次信任評估，這是安全工程的基本要求。

老馮的看法

老馮看到這個新聞的第一反應是相當遺憾。

畢竟我自己就是 pgBackRest 的深度用戶：如果沒有人來接盤，老馮自己也愿意接手把這個事情扛起來。

老馮之前已經，也是因為我自己要用，原廠 Rug-Pull 跑路之后，我只能自己 fork 了一份維護下去。 我覺得在不搞新功能的前提下，接手 pgBackRest 維護也不算特別離譜。

不過，老馮覺得 pgBackRest 還不至于走到那一步。這件事接下來大概有幾種走向。

首先可以確定的是，5 月在溫哥華的 PGConf.Dev 大概率會把這件事作為重要話題之一來討論。 一個涉及到 PG 生態主要廠商核心利益的工具，社區不會放任不管。

現實的預期，是社區通過協商產生一個新的 fork， 就像 Redis 改協議之后社區另起爐灶搞了 Valkey 一樣。 鑒于不能用原名，新項目可能叫 pgbackrest-ng，pgbacknext 或者別的什么。 這個方向的核心問題是要有一個或幾個長期承諾的廠商挑頭并達成共識。

比較壞的情況，是既沒有牽頭者，也沒有進 PGDG，廠商間也沒有達成共識。 那就會進入“各家維護一份內部 fork”的狀態：Percona 一份、EDB 一份、各家云廠商一份。這個結局是最糟的，真正的“Fork Wars”。

最理想的結果，是 PGDG 內核團隊接手，做成 contrib 模塊，或者放進 PGDG Global Development Group 的項目集里。 但老實說有難度，而且其他備份工具的維護者不見得會樂意。

目前的現狀是，Percona 已經明確表態會繼續向自己的客戶提供 pgBackRest 的支持。 這意味著至少在客戶層面，pgBackRest 不會立即失去所有支撐。Crunchy 現有產品和文檔仍然深度集成 pgBackRest，但截至目前，我沒有看到它對項目長期維護給出新的公開承諾。

老馮也在這里明確表態：如果沒有其他人來維護，我會接手維護下去。 當然如果有其他人維護得好，那我也很樂意將其作為上游，進行驗證與打包分發，提供用戶反饋。

不要著急忙慌的跳車

往近處說，老馮給各位 PostgreSQL DBA 的建議是：如果你在用 pgBackrest，也不用擔心。先別慌，更不要急著跳車。

pgBackRest 是一個非常成熟的軟件，歸檔的是倉庫，不再接受 PR、不再修 bug、不再發新版本，但代碼本身還在那里，今天用得好好的，明天還能繼續用。

你現在用 pgBackRest 能有什么問題？ 如果你一直用現在的 PostgreSQL 18，配合現在的 pgBackRest v2.58，可以繼續跑到地老天荒。

風險要出現，也是幾個月與一兩年后的事情了。比如今年 9 月之后 PG19 發布，或者再往后的一兩個大版本之后。 pgBackRest 當前版本對 PG 18 是兼容的，但新大版本如果出現需要適配的內核改動，或者對象存儲、依賴庫、安全漏洞需要后續修復，事情就會變得棘手。 但這是中長期需要擔心的事，不是今天立刻需要擔心的事。

更重要的是，沒有能與之完全匹敵的替代：目前沒有任何一個工具能直接原位替代 pgBackRest 的功能完備度。

?Barman（EDB 維護）是最可靠的備選項之一， 3.18 版本新增了云存儲塊級增量備份能力，但這部分能力仍然比較新， 離 pgBackRest 的成熟度和一體化體驗還差一段距離?WAL-G 是實用的云上歸檔與恢復工具，在 K8s/云原生場景里尤其常見， 但與 pgBackRest 的完整備份倉庫治理能力并不完全重疊

?pg_probackup（Postgres Professional）當年是唯一能在功能維度上和 pgBackRest 并列的對手， 塊級 PTRACK 增量備份甚至更激進。 但作者公司是俄羅斯背景，2022 年之后境況復雜； 更要命的是，這個工具歷史上有過恢復后數據丟失、無效頁面等嚴重 issue 記錄 （例如[1]、 [2]）。 對一個備份工具來說，這是相當致命的污點，讓我個人非常猶豫推薦它

所以，最好的操作就是不要急著動，亂折騰反而是最大的風險。 該用還是繼續用，把 v2.58 當作未來一段時間的穩定基線； 同時把恢復演練做扎實，關注 PGConf.Dev 之后社區是否出現明確接班分支，再做下一步決定。

更深層的觀點

David 的故事特別值得反思的地方在于：他不是某個個人愛好者燃燒殆盡的故事，他是在 Crunchy Data 里被付費做開源這件事的。 這恰恰是開源社區里反復推崇的“健康開源模式”。 然后這個模式被 Snowflake 的并購給端掉了。

2025 年以來，PostgreSQL 世界出現了密集資本動作：Databricks 宣布收購 Neon，媒體報道稱交易約 10 億美元； Snowflake 宣布收購 Crunchy Data，媒體報道稱交易約 2.5 億美元；Databricks 隨后又收購 Mooncake Labs；Supabase 也被報道正在洽談以約 100 億美元估值融資。

這是一把雙刃劍。 一方面，它把更多的資本引到了數據庫這個相對不那么性感的領域里， 另一方面，這些原本小而美、做得好好的公司，被資本一攪和、一折騰，就出現了今天這種離譜現象。 原本健康運轉的開源贊助閉環，因為一次并購就被切斷了。

老馮自己做這件事，也有云廠商找過來談收購。但我會反復掂量一個問題： 如果我被收購了，開源這件事還能不能做下去？ 這是每一個有點情懷創始人都該問自己的問題。

對絕大多數普通開發者來說，“工具好不好用”才是硬道理，誰會去關心維護者的工資條？ 但對企業來說，態度應當不一樣。

現在的現狀非常魔幻：這么多 Postgres 公司、DBaaS 廠商、托管服務都在用 pgBackRest，幾乎可以算得上是事實標配。 但你去看 pgBackRest 項目頁的贊助商列表，目前只列了 Supabase 一家。 比這些公司有錢得多的云廠商有的是，但很多都心安理得地白嫖。 這就是公地悲劇的精確寫照：當所有人都假定“會有別人去付維護成本”的時候，這套模式就崩了。

背后更深層的原因是開源世界一個固有矛盾：價值創造和價值捕獲的分離，做出東西的人和拿這個東西賺錢的人不是一撥人。 AWS 這些云廠商每年從托管 Postgres 與相關數據庫服務里，賺取數億乃至數十億美元級別的收入， 但 Postgres 核心團隊不會從中分到一個銅板。 同樣的邏輯反復在 Redis、Elasticsearch、MongoDB 上演過，劇情大同小異。

PG 生態里像 pgBackRest 這種不算內核、但實質上撐起整個生態的支柱性項目** 還有很多：

?Patroni：PG 高可用的事實標準之一，在大量自建集群和一部分 K8s Operator 后面都是它?PgBouncer：PG 連接池的事實標準，在稍大規模的 Postgres 部署里極其常見?加上各種 FDW、各種 contrib 擴展、各種監控組件……

PG 世界里 “并不缺” 備份、連接池、高可用工具，每一個領域可能都有好幾個選擇。 但如果我們就是要用 “最好” 的方案，那其實選項就唯一了。 如果這些項目得不到良好的維護和反饋循環，這會是 PostgreSQL 生態真正的風險。

最后聊聊 Pigsty

老馮對 pgBackRest 這件事感觸特別深，David 的故事給了我很多啟示。

老馮搞 PG 發行版 Pigsty，它作為一個開源的 PostgreSQL 發行版，做到現在算得上相當成功。 按 GitHub stars、社區口碑、企業部署量來看，在 Linux 原生發行版這個細分賽道上，我認為 Pigsty 已經做到了頂尖。

但它也是老馮一個人維護的，一個人寫代碼、一個人發版本、一個人寫文檔、一個人答疑，寫文章，錄教程。老馮之所以能把這件事做下去，本質上是因為兩件事同時成立：

1.我確實熱愛這件事。 數據庫、Postgres、運維自動化、開源，這是我從大廠出來之后一直在干的事，干得很爽，愿意繼續干。2.更重要的是，確實有企業客戶給我付費支持，跑通了商業循環。

我能吃飽飯、不愁生計，又能做自己喜歡做的事，在精神和物質層面雙重滿足，所以能維護下去。 但如果這兩件事之一不成立，Pigsty 也許就是下一個 pgBackRest。

所以 David 這件事對我來說，遠不只是一篇行業新聞。它是關于項目如何接班、如何可持續生長的活生生的案例。 商業客戶那一面，付錢意味著辦事，是非常扎實的承諾與責任約束； 開源那一面，本質上是在依賴 Goodwill（善意）做事，而善意是會被白嫖與惡語磨損的，會被并購裁員吞掉的。

老馮如果以后做大不差錢了，我也很樂意拿出錢來贊助 Postgres 上游項目， 以及生態里這些撐起整個世界的支柱項目：pgBackRest 的接班人、Patroni、PgBouncer…… 這是一種基本的責任感。

今天這些項目還能用，是因為有人在替你扛著。他們扛不動了，你的房子也會塌。

最后，回到 David Steele。

我們這些受惠于 pgBackRest 十幾年的人，欠他一句很正式的：

謝謝。

希望他早日找到一份合適的下家工作。也希望他打造的這件作品，能在新的形態下繼續陪伴 PostgreSQL 走過下一個十年。

References

[1] : https://github.com/postgrespro/pg_probackup/issues/474
[2] : https://github.com/postgrespro/pg_probackup/issues/249

數據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群（搜pigsty-cc）