備份，不是倦怠：我們在 Postgresus 2.0 中發布了什麼（以及我們放棄了什麼）

\ Postgresus 首次發布已經過了 6 個月。在這段時間內，專案收到了 247 個提交、新功能，以及在 GitHub 上獲得約 2.8k 顆星和從 Docker Hub 下載約 42k 次。專案社群也有所成長，現在有 13 位貢獻者和 90 人加入 Telegram 群組。

在本文中，我將介紹：

• 專案在這六個月內發生了哪些變化；
• 出現了哪些新功能；
• 接下來的計劃是什麼。

\

什麼是 Postgresus？

對於第一次聽說這個專案的人：Postgresus 是一個帶有使用者介面的開源 PostgreSQL 備份工具。它可以執行多個資料庫的排程備份，將備份儲存在本地或外部儲存空間，並在備份完成或失敗時通知您。

這個專案可以通過 Docker 中的單一命令部署。它可以通過 Shell 腳本、Docker 命令、docker-compose.yml 安裝，現在還可以通過 Kubernetes 的 Helm 安裝。更多關於安裝方法的資訊。

除了「建立備份」這個主要功能外，該專案還可以：

• 將備份儲存在本地、S3、CloudFlare R2、Google Drive、Azure Blob Storage 和 NAS 中。更多詳情請點擊這裡。
• 將狀態通知發送到 Slack、Discord、Telegram、MS Teams、通過電子郵件以及可配置的 Webhook。更多詳情請點擊這裡。
• 通過工作區分隔資料庫，授予其他使用者存取權限並儲存審計日誌。更多詳情請點擊這裡。
• 加密備份和憑證。更多詳情請點擊這裡。
• 同時支援自託管資料庫和雲端管理的資料庫。

網站 - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (非常感謝您的星標 ⭐️)

專案介面如下所示：

概覽影片：https://www.youtube.com/watch?v=1qsAnijJfJE

對於想參與開發的人，文檔中有一個專門的頁面。如果有人想幫助這個專案但不想寫程式碼 — 只需向您的同事和朋友介紹這個專案！這也是對專案的重大幫助和貢獻。

我知道如何開發，但即使是推廣開源專案也相當困難。這個專案獲得認可要感謝那些製作影片評論和在社交媒體上談論這個專案的人。謝謝你們！

2.0 版本中出現的新功能

在這六個月中發生了很多變化。專案在四個方向上得到了改進：

• 擴展了基本功能；
• 改進了使用者體驗；
• 為團隊提供了新功能（DBA、DevOps、團隊、企業）；
• 改進了保護和加密以滿足企業需求。

讓我們逐一了解。

1) 資料庫健康檢查

除了備份外，Postgresus 現在還監控資料庫健康狀況：它顯示運行時間並在資料庫不可用時提醒您。

健康檢查可以禁用和配置。

如果資料庫不可用 — 系統將發送相關通知。

2) 儲存備份和發送通知的新來源

最初 Postgresus 只能在本地和 S3 中儲存備份。現在增加了 Google Drive、CloudFlare R2、Azure Blob Storage 和 NAS。計劃包括增加 FTP，可能還有 SFTP 和 NFS。

對於通知，最初專案只有 Telegram 和電子郵件（SMTP）。現在還支援 Slack、Discord、MS Teams 和 Webhook。此外，Webhook 現在可以靈活配置以連接到不同平台：

3) 工作區和使用者管理

之前系統只有一個使用者（管理員），資料庫對整個系統是全局的。現在 Postgresus 支援建立工作區來分隔資料庫並將使用者添加到工作區。角色分離為：

• 僅查看（可以查看備份歷史記錄，下載備份文件）；
• 編輯（除了讀取外，還可以添加\刪除\修改資料庫）。

因此，您現在可以分隔資料庫：

• 客戶 X 的資料庫；
• 初創公司 Y 的資料庫；
• 團隊 Z 的資料庫；

DBA 團隊和大型外包公司開始使用 Postgresus，所以這成為了一個重要功能。它使專案不僅對個別開發人員、DevOps 或 DBA 有用，還對整個團隊和企業有用。

審計日誌也出現了：

如果有人決定刪除所有資料庫或因某種原因下載了所有資料庫的所有備份 — 這將是可見的 🙃

4) 加密和保護

在第一個版本中，老實說，我沒有時間考慮安全性。我將所有備份文件儲存在本地，沒有人可以存取它們，而且我的專案也不是絕對機密的。

但當 Postgresus 成為開源後，我很快了解到團隊經常將備份保存到共享的 S3 儲存桶中，並且不希望其他人讀取它們。資料庫密碼也不應該儲存在 Postgresus 自己的資料庫中，因為許多人可以存取其伺服器。~~而且彼此之間存在一些不信任。~~ 僅僅不通過 API 暴露機密已經不夠了。

因此，整個專案的加密和安全性成為 Postgresus 的主要優先事項。保護現在在三個層面上運作，並且有一個專門的文檔頁面介紹這方面的內容。

1) 所有密碼和機密的加密

所有資料庫密碼、Slack 令牌和 S3 憑證都以加密形式儲存在 Postgresus 的資料庫中。它們只在需要時解密。密鑰儲存在與資料庫分開的文件中，所以即使有人入侵了 Postgresus 的資料庫（無論如何它也不會對外暴露）— 他們仍然無法讀取任何內容。加密使用 AES-256-GCM。

2) 備份文件的加密

備份文件現在也被加密（可選，但默認啟用加密）。如果您丟失了文件或將其保存在公共 S3 中 — 現在就不那麼可怕了。

加密同時使用鹽值和唯一的初始化向量。這可以防止攻擊者找到模式來猜測加密密鑰，即使他們竊取了您所有的備份文件。

加密以流模式進行，這裡也使用 AES-256-GCM。

3) 使用只讀使用者進行備份

儘管有前兩點，但沒有 100% 的保護方法。仍然有微小的可能性：

• 您的伺服器被完全入侵，他們獲得了密鑰和合法的 IP 地址來存取資料庫；
• 黑客會以某種方式解密 Postgresus 內部資料庫中的密碼並找出您的資料庫密碼；
• 或者更糟的是，不是黑客而是內部人員；
• 他們會破壞您的資料庫，並且之前已刪除備份。

因此 Postgresus 應該幫助使用者將損害降到最低。這種入侵的可能性可能接近零，但如果您是受害者，這並不能給您帶來安慰。

現在當您向 Postgresus 添加具有寫入權限的資料庫使用者時，系統會提供自動建立只讀使用者並通過它運行備份的選項。當只需點擊一下而不是在資料庫中手動設置時，人們更有可能建立只讀角色。

以下是 Postgresus 的提供方式：

非常堅持地提供：

採用這種方法，即使您的 Postgresus 伺服器被入侵，所有內容被解密，攻擊者獲得了對您資料庫的存取權 — 他們至少無法破壞資料庫。知道並非一切都失去了是一種相當好的安慰。

5) 默認壓縮，最佳選擇

Postgresus 的第一個版本提供了 PostgreSQL 支援的所有壓縮算法：gzip、lz4 和 zstd，壓縮級別從 1 到 9。老實說，我並不真正理解為什麼有人需要所有這些選項。我只是選擇了 gzip 級別 5，因為它看起來是一個合理的中間值。

但一旦專案成為開源，我不得不實際研究這個問題。所以我在所有可能的組合中運行了 21 個備份，找到了速度和大小之間的最佳平衡。

所以現在對於所有備份，如果 PostgreSQL 版本是 16 及以上，默認設置為 zstd 壓縮級別 5。如果更低 — 仍然是 gzip（順便說一下，再次感謝貢獻者對 PG 12 的支援）。這是 zstd 5 與 gzip 5 的比較（它在底部）：

平均而言，備份相對於實際資料庫大小壓縮了約 8 倍。

6) Kubernetes Helm 支援

這一點很簡單 — 我們增加了使用 Helm 安裝的原生 k8s 支援。在雲端運行 k8s 的團隊現在可以更輕鬆地部署 Postgresus。三位貢獻者幫助實現了這個功能。

7) 深色主題

我並不是深色主題的粉絲。但有很多請求，所以我增加了一個（~~感謝 Claude 的幫助和設計師的眼光~~）。令人驚訝的是，它比淺色主題更好，並成為了默認主題。我甚至將網站從淺色重新設計為深色 — 它看起來非常好。

之前：

之後：

8) 放棄增量備份和 PITR（時間點恢復）

首先，一些背景：

• 邏輯備份 — 是指 PostgreSQL 自身導出其數據（到一個文件或一組文件）。
• 物理備份 — 是指我們連接到 PostgreSQL 的硬碟並製作其文件的副本。
• 支援 PITR 的增量備份 — 是物理備份 + 變更日誌（WAL），從磁碟複製或通過複製協議。

我相信 Postgresus 最終應該支援增量備份。畢竟，這是嚴肅的工具所做的！甚至 ChatGPT 也說嚴肅的工具可以精確到秒和交易進行恢復。

所以我開始著手這項工作。但現實打擊了我：

• 在使用者體驗和開發者體驗方面很難使其便捷。因為您需要物理連接到資料庫的磁碟，或設置複製。

對於恢復 — 沒有選項不連接到資料庫的磁碟。要從增量備份恢復，備份工具只需恢復 pgdata 文件夾（更準確地說，是其中的一部分）。

如果資料庫真的很大，例如，幾個 TB 或更多 — 需要在配置中進行微調。在這裡，UI 更多是一種阻礙而非幫助。

• 大多數雲服務（AWS、Google、Selectel）不會與外部增量備份配合工作，如果它們需要磁碟存取。理論上，通過一些變通方法，通過複製 — 它們會。但從這樣的備份恢復到受管理的雲仍然無法工作。
• 所有雲服務都提供開箱即用的增量備份。一般來說，這是它們收費的原因之一。即使它們通常也不允許精確到秒或特定交易時刻進行恢復。如果您不在雲端 — 您的專案需要這種精度的可能性就更小了。

因此，如果 Postgresus 正在備份受管理的資料庫 — 大約每週一次就足夠了。以防不可預見的緊急情況或雲不允許儲存足夠長時間的備份。否則，依賴雲自己的增量備份。

• 對於大多數專案，增量備份並不是真正必要的。對於小型資料庫，如果需要頻繁備份，備份之間一小時的粒度就足夠了。對於大型資料庫 — 至少每天一次。這對於 99% 的專案來說足以找回丟失的數據或完全恢復。這些需求完全由邏輯備份覆蓋。

但如果您是銀行或受管理資料庫的開發者，您確實需要為數十和數百 TB 的數據提供最精細的備份配置。在這裡，Postgresus 在控制台便利性和 TB 以上體積資料庫的效率方面永遠無法超越 WAL-G 或 pgBackRest 的物理備份。但在我看來，這些已經是由 PostgreSQL 本身的天才和維護者製作的專門工具。

在我看來，增量備份在兩種情況下確實需要：

• 在過去，當沒有這麼多雲管理資料庫的選擇，大型專案需要自己託管所有內容。現在同樣的銀行、市場和電信公司都有內部雲，開箱即用 PITR。
• 您是一個受管理的雲。但這裡的任務比僅僅進行備份和從中恢復要複雜得多。

考慮到這一切，我做出了放棄增量備份開發的深思熟慮的決定。相反，我專注於使邏輯備份對開發人員、DevOps、DBA 和公司的日常使用盡可能方便、可靠和實用。

9) 許多小改進

上述幾點遠非全部。80% 的工作通常是不可見的。我能想到的一些簡短列表：

• 緩衝和 RAM 優化。Postgresus 不再嘗試緩衝 pg_dump 發送的所有內容，同時等待 S3 趕上（從資料庫下載通常比上傳到雲端更快）。RAM 使用現在限制為每個並行備份 32 MB。
• 各種穩定性改進和小錯誤修復。
• 增加了無用戶名和無密碼的 SMTP。我甚至不知道這種情況會發生...
• 增加了向 Telegram 群組發送通知的主題。
• 文檔出現了！
• PostgreSQL 12 支援。

還有更多。

什麼沒有成功？

當然，並非所有事情都能成功，有些事情必須放棄。我在業餘時間建立 Postgresus，而這幾乎不存在。所以我不能分散精力或用不必要的功能使使用者體驗複雜化。功能太多也不好。

1) 完整的資料庫資源監控

我想讓 Postgresus 也成為一個 PostgreSQL 監控工具。包括運行 PostgreSQL 的伺服器的系統資源：

• CPU
• RAM
• ROM
• IO 速度和負載

我甚至為收集指標（任何）和圖表模板建立了基礎：

結果發現 PostgreSQL 只開箱即用地暴露 RAM 使用和 IO 指標。

監控其他資源需要擴展。但並非每個資料庫都能安裝我需要的擴展，所以我只能收集部分指標。然後我發現雲資料庫通常根本不允許安裝擴展。

然後我意識到指標應該儲存在 VictoriaMetrics 或至少 TimescaleDB 中，而不是在 Postgresus 自己的 PostgreSQL 中，這會使鏡像構建複雜化。

最終，這個非必要功能會增加：

• 顯著的代碼複雜性，意味著更難維護；
• 更多的鏡像構建要求（額外組件）；
• 複雜的使用者體驗（正如我所說，功能太多是不好的）；
• ~~不明確的定位：我們是備份工具、監控工具，還是試圖做所有事情？~~

所以我放棄了資源監控，專注於使 Postgresus 成為最好的備份工具。

2) SQL 控制台

我還想增加一個 SQL 控制台。既然 Postgresus 已經連接到資料庫，為什麼不直接從中運行查詢呢？這會很方便 — 不需要每次都打開 PgAdmin、DataGrip 或 DBeaver。

我從未找到時間來做這個，只是計劃。一位貢獻者開始了這個功能並提交了一個 PR。但正如複雜功能所預期的那樣，出現了許多需求和邊緣情況：

• 需要增加 SQL 語法支援；
• 增加自動完成和提示；
• 實現懶加載，使即使 100MB 的行也不會全部傳輸到瀏覽器；
• 至少增加幾個導出到 CSV 和 XLSX 的功能。

這基本上是一個完整的專案，而不僅僅是一個標籤頁。

我們決定放棄這個功能並節省精力。這證明是正確的決定，因為我們增加了不允許 INSERT、UPDATE 和 DELETE 的只讀角色。

結論

這就是 Postgresus 在六個月內走過的旅程。它從一個小眾專案成長為一個企業級工具，幫助個別開發人員和整個 DBA 團隊（順便說一下，我很驚訝在第一次發布後約 2 個月就了解到這一點）。我真誠地感到高興，數千個專案和使用者依賴 Postgresus。

專案不會止步於此。我現在的目標是使 Postgresus 成為世界上最方便的 PostgreSQL 備份工具。有大量的功能和改進正在逐步推出。

我的主要優先事項仍然是：

• 專案安全性 — 這是關鍵，沒有它一切都沒有意義；
• 在使用專案本身方面的便捷使用者體驗，沒有過多的功能（我們只做一件事，但做得非常好）；
• 在部署方面的便捷使用者體驗：使一切都能用一個命令部署，開箱即用不需要配置；
• 專案開放性 — 完全開源，對任何人或公司都是免費的。

如果您喜歡這個專案或發現它有用 — 我會感謝您在 GitHub 上給予星標或與朋友分享 ❤️

\