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

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

聲明發(fā)在 GitHub 和 LinkedIn 上，干凈利落：

停止維護公告

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

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

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

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

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

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

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

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

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

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

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

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

故事的真正背景

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

David 之前是 Crunchy 的架構(gòu)師，Crunchy 是一家 PostgreSQL 服務公司。 去年 6 月，數(shù)據(jù)湖倉巨頭 。

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

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

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

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

大家在討論什么

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

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

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

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

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

老馮的看法

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

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

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

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

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

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

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

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

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

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

不要著急忙慌的跳車

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

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

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

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

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

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

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

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

更深層的觀點

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

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

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

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

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

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

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

PG 生態(tài)里像 pgBackRest 這種不算內(nèi)核、但實質(zhì)上撐起整個生態(tài)的支柱性項目** 還有很多：

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

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

最后聊聊 Pigsty

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

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

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

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

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

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

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

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

最后，回到 David Steele。

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

謝謝。

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

References

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

數(shù)據(jù)庫老司機

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

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

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