pgbackrest/pgbackrest
(github.com/pgbackrest)- PostgreSQL向けのバックアップ・リストアツールとして大規模環境まで拡張できるよう設計されていたが、現在はメンテナンス終了状態
- bug fix、PR review、issue対応、新機能開発はすべて停止しており、不規則に継続するよりも明確に止める選択をした
- フル・differential・incrementalバックアップとblock-level backup、中断された作業の再開、delta restoreをサポートし、変更された部分だけを保存・復元できる
- ローカル・リモート環境をまたぐprotocol layerとmultiple repositoriesを備え、TLS・SSH接続とS3・Azure・GCS互換object storeを通じて運用範囲を広げている
- checksum、WAL segment待機、fsync、page checksum検証などの整合性保証の仕組みを幅広く備えたツールだったが、今後forkが現れても別途信頼を新たに築く必要がある
メンテナンス終了とプロジェクトの状態
- pgBackRestはPostgreSQL向けのバックアップ・リストアツールだが、現在はもはや保守されていない
- プロジェクト作業を停止しており、今後はbug fix、PR review、issue対応、新機能開発に時間を使わないと表明している
- 既存の支援や雇用形態が途切れたあとも保守を続けようとしたが、プロジェクトを維持し続けるだけの職務機会とスポンサーシップを確保できなかった
- 保守を不規則または不完全に続けるより、明確に終了するほうがよいと判断した
- 今後誰かがforkする可能性はあるが、その場合は新しいプロジェクトと見なされ、新たなメンテナーが別途信頼を築く必要がある
プロジェクトの主要機能
- 大規模なPostgreSQL環境まで拡張可能なバックアップ・リストアを目標としており、現在の安定版はv2.58.0
- 並列処理とlz4、zstdのような圧縮方式を活用し、バックアップ時にボトルネックになりやすい圧縮コストを減らすよう設計されている
- フル、differential、incrementalバックアップをサポートし、ファイル単位だけでなくblock-level backupで変更部分のみをコピーして保存容量を節約する
- 中断されたバックアップを再開でき、manifestのチェックサムと比較して、すでにコピー済みのファイルの整合性を再確認する
- delta restoreではバックアップにないファイルを先に削除し、残ったファイルのチェックサムを照合して、一致するファイルはそのまま残し、必要なファイルだけを復元する
リモート運用とリポジトリ設計
- 独自のprotocol layerにより、ローカル環境とリモート環境の両方でバックアップ、リストア、アーカイブ作業を実行でき、リモート接続にはTLS/SSHを使用する
- 同じprotocol layerでPostgreSQLクエリインターフェースも提供し、PostgreSQLへ直接リモート接続しなくても作業できるため、セキュリティを高められる
- multiple repositoriesをサポートし、高速リカバリ向けのローカルリポジトリと、長期保管・冗長性確保向けのリモートリポジトリを併用できる
- リポジトリはS3、Azure、GCS互換object storeにも配置でき、容量と保持期間を大きく拡張できる
- リポジトリ自体を暗号化できるため、バックアップデータをどこに保存しても保護できる
整合性と一貫性の保証方法
- バックアップ内のすべてのファイルについてchecksumを計算し、restoreやverify時に再検査する
- ファイルコピー完了後は、バックアップを一貫した状態にするために必要なすべてのWAL segmentがリポジトリに到着するまで待機する
- すべての作業でファイルおよびディレクトリレベルのfsyncを使用し、耐久性を確保する
- PostgreSQLでpage checksumが有効な場合、フルバックアップではすべてのファイルのページチェックサムを検証し、differential・incrementalバックアップでは変更されたファイルのみを検証する
- ページチェックサム検証に失敗してもバックアップは中断されないが、どのページが失敗したか警告を残すことで、有効なバックアップが失効する前にpage-level corruptionを早期発見できる
WAL処理と復旧性能の最適化
- WAL push/get専用コマンドを提供し、どちらも並列処理と非同期実行をサポートして、PostgreSQLの応答時間をできるだけ短く保つよう設計されている
- WAL pushでは同一のWAL segmentが複数回入ってくると自動で重複排除し、内容が異なる場合はエラーを発生させる
- 非同期WAL pushでは別プロセスが転送を担当し、WAL segmentを並列圧縮するため、書き込み量が非常に多いデータベースで特に重要となる
- 非同期WAL getは展開済みのWAL queueをローカルに保持し、replay前にすぐ供給できるようにするため、レイテンシの大きい接続やS3のようなストレージで特に効果が大きい
- WAL pushとgetはいずれもPostgreSQLバージョンとsystem identifierを比較して、データベースとリポジトリが一致しているか確認するため、WAL archiveの保存先を誤設定する可能性を大きく減らせる
運用の柔軟性と互換性
- backup retentionとarchive expirationポリシーをfull、differential、WAL単位で分けて設定でき、望む保持期間の範囲をカバーできる
- バックアップをPostgreSQL cluster形式のまま保存でき、圧縮を無効にしてhard linkを有効にすれば、リポジトリsnapshot上でPostgreSQL clusterを直接起動することもできる
- この方式は、従来のrestoreに時間がかかるterabyte-scale databaseで有利
- tablespaceを完全にサポートし、restore時に各tablespaceを別の場所へ移したり、1か所へまとめてremapしたりできる
- ファイルおよびディレクトリリンクもサポートし、restore時に元の場所を維持する、一部または全部をremapする、通常のファイル・ディレクトリとして変換復元することも可能
- PostgreSQL 10個のバージョンをサポートし、現在サポート中の5バージョンとEOL済みの直近5バージョンを含め、アップグレード期間に十分な余裕を持てるよう構成されている
参考リソースとスポンサー状況
- User guides
- Command reference
- Configuration reference
- 現在のスポンサーはSupabase
- 過去のスポンサーにはCrunchy Data、Resonateがいた
1件のコメント
Hacker Newsのコメント
会社の支援もあったが、夜間や週末まで費やしてきて、Crunchy Data売却後も維持を続けながらこの仕事を引き継げるポジションを探したものの、うまくいかなかったという
生計のためにもっと広い機会を見なければならず、そうなると保守・バグ修正・PRレビュー・issue対応に必要な時間をもう割けないため、リポジトリをアーカイブするという立場
ガイドは https://github.com/freakynit/postgre-backup-and-restore-guide で、これまで注ぎ込まれた時間と努力には本当に感謝している
そこにトークンへ資金をつぎ込んでしまった人も多く、余剰資金も時間も一緒に減っている場合がある
これが趣味プロジェクトを超えて、商用環境で実際の価値を出すプロダクト級のツールだったなら、その隙間を埋める営利企業が参入する余地も確実にある
ただし利用者が顧客になって実際にお金を払う必要があり、無償メンテナにバグレポートや不満を送り続けるだけでは持続可能ではない
FOSSの財政的持続可能性について新しい解決策が必要で、寄付だけでは足りないように見える
地元の店でもオープンソースプロジェクトでも同じこと
ただし貢献者ごとに著作権が関わっている可能性があるので、ACLの有無や法域次第では権利整理が必要で、収益分配のような合意も必要かもしれない
企業スポンサーがある間は回っていたのに、会社が売られて新しいオーナーが優先順位を変えた途端、3.8k-starのインフラツールがすぐ不安定になった。つまり利用者は、自分のバックアップツールの資金源が他人のM&A戦略に依存していたことを知らなかったわけだ
そのため自分も少しずつ、SQLiteとgitで追跡するファイル寄りの構成へ移っている
マネージドPostgresスタックも結局は、資金事情の見えない人たちが保守する複数のツールの上に成り立っているからだ
ただし資金構造が脆弱だという大きな流れ自体は、依然としてその通りだ
そのついでに、失いたくない依存プロジェクトを見直して、今すぐ支援設定をするのがよいと思う
みんな悲しいとは言うけれど、本当に悲しいなら寄付するほど悲しいのかをまず自問すべきだ
特に単にバックアップするだけでなく、復旧と検証まで真剣に扱っていた点は珍しく、それを軽視して職場で大きな痛い目を見たこともある
詳しい話は https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/ にある
だからこれはかなり大きな損失に感じる
WAL-GやBarmanと比べるとどうなのか気になる
https://github.com/wal-g/wal-g
https://github.com/EnterpriseDB/barman
毎晩Barmanで復元したnightly DBを作り、ユーザー教育やテスト用にも回して、バックアップが実際に壊れていないか継続的に検証しているが、何年も問題は出ていない
数年非アクティブだったあと再びmanaged Postgresの領域に戻ってきており、wal-gが独自のブロック比較で提供するdelta backupに加えて、pg17 incremental backupにも対応してほしいと思っている
そしてdaemon modeはぜひ使うべきだ
競合ツールが消えるのは残念だが、この領域にはまだ改善の余地が多く、Postgresがovercommitなしのシステムで動きたがるときには、CはGolangより優れている面もある
約9年前に検討した時点では、streaming PITRの特性のため、pgBackRestよりこちらのほうに魅力を感じた
そうなると、最も近い代替はwal-gなのか、barmanなのか、databasusなのか気になる
DBAのふりをしているだけとは言ったが、実際には選択はかなり重要だ
ちなみに私はDBREだ
関連ドキュメントは https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
https://github.com/aiven-open/pghoard も良さそうだが、まだ自分では検証していない
だからこそ今回の件はなおさら残念で、この優れたツールと機能同等性を揃えるのは簡単ではなさそうだ
可能なら撤回可能な決定であってほしいし、そうでなければPostgreSQLプロジェクトがcontribとして取り込む道もあってほしい
作者もたぶん、人々が今すぐ捨てるのではなく、本当に動かなくなるまでは使い続けてほしいと思っているはずだ
forkが必要なのか、それとも既存リポジトリにコントリビューターとして入って引き継げるのかはよく分からない