PostgreSQLのオープンソースバックアップ管理の現状

PostgreSQLクラスターのバックアップを取ることに対処する方法はたくさんあります。 PostgreSQLに貴重なデータを保存するためのさまざまなテクノロジーを紹介する記事やブログがいくつかあります。論理バックアップソリューション、OSレベル、ファイルシステムレベルなどの物理バックアップがあります。このブログでは、さまざまなブログや記事、および公式ドキュメントで十分にカバーされている理論的な部分については説明しません。

このブログは、利用可能なさまざまなツールとソリューションの状態に焦点を当てており、実際の経験に基づいて徹底的な比較を提示する取り組みを行っています。この記事は、特定の製品を宣伝するものではありません。このブログで説明されているすべてのツール、ソリューション、テクノロジーが本当に気に入っています。ここでの目的は、長所と短所を書き留め、エンドユーザーに、環境、インフラストラクチャ、および特定の要件に最適なツールを案内することです。これは、さまざまなレベルでのPostgreSQLのバックアップツールについて説明しているすばらしい記事です。

このブログでは、さまざまなツールの使用方法については説明しません。この情報は、上記のブログ、公式ドキュメント、およびネット上の他のリソースに記載されているためです。しかし、私が実際に経験したときの長所と短所について説明します。このブログでは、以下に依存する従来のPITRベースの物理PostgreSQLバックアップのみを扱っています。

• pg_basebackupまたはpg_start_backup（）/ pg_stop_backup
• 物理的なコピー
• WALのアーカイブまたはストリーミングレプリケーション

いくつかの優れた製品とソリューションがあり、オープンソースで無料で使用できるものもあれば、商用のものもあります。私の知る限り、それらは次のとおりです。

• pgbarman by 2ndquadrant（無料）
• pgbackrest（無料）
• Postgres Professionalによるpg_probackup（無料）
• BART by EDB（商用）

BARTは、使用していないLinuxのフレーバーで実行されるため、試す機会がありませんでした。このブログでは、最初は通常過小評価される非常に重要な側面であるため、各ソリューションのそれぞれの作成者/コミュニティ/メンテナと対話しながら、私自身の考えや印象を含めます。各ツールのさまざまな用語をよりよく理解するための用語：

pgbarman

Pgbarmanまたは単にbarmanは、これらのツールの中で最も古いものです。最新のリリースは2.6です（このブログを作成中にリリースされました！これは素晴らしいニュースです）。

Pgbarmanは、次の2つの方法でベースバックアップをサポートしています。

• pg_basebackup（backup_method =postgres）
• rsync（backup_method =rsync）

およびWAL転送：

• WALアーカイブ
  • rsync経由
  • barman-wal-archive /put-wal経由
• レプリケーションスロットを使用したスト​​リーミングレプリケーションを介したWAL
  • 非同期
  • 同期

これにより、barmanを使用できる8つのすぐに使用できる組み合わせが得られます。それぞれに長所と短所があります。

pg_basebackup（backup_method =postgres）によるベースバックアップ

長所：

• 最新/最新の方法
• 実績のあるコアPostgreSQLテクノロジーに依存しています
• 公式ドキュメントで推奨

短所：

• 増分バックアップなし
• 並列バックアップなし
• ネットワーク圧縮なし
• データ重複排除なし
• ネットワーク帯域幅の制限なし

rsyncによるベースバックアップ（backup_method =rsync）

長所：

• 古くて実績のある
• 増分バックアップ
• データ重複排除
• ネットワーク圧縮
• 並列バックアップ
• ネットワーク帯域幅の制限

短所：

• （作成者が）推奨する方法ではありません

WALアーカイブを介した（rsyncを介した）WAL転送

長所：

• セットアップが簡単

短所：

• RPO =0なし（データ損失ゼロ）
• 長く続くネットワーク障害から回復する方法はありません

WALアーカイブを介したWAL転送（barman-wal-archive / put-walを介して）

長所：

• 最新の推奨される方法（2.6で導入）
• rsyncよりも信頼性が高く安全です

短所：

• RPO =0なし（データ損失ゼロ）
• 長く続くネットワーク障害から回復する方法はまだありません

レプリケーションスロットを使用したWALストリーミングを介したWAL転送（pg_receivewalを介して）

長所：

• より現代的な（そして推奨される）
• 同期モードでのRPO=0（データ損失ゼロ）

短所：

• 常にレプリケーションスロットに関連付けられています。ネットワーク障害が発生した場合に拡大する可能性があります

したがって、pg_basebackup（postgresメソッド）はpgbarmanの未来のように見えますが、実際には、すべての優れた機能にrsyncメソッドが付属しています。それでは、Barmanのすべての機能をさらに詳しくリストしましょう：

• リモート操作（バックアップ/復元）
• 増分バックアップ。バーマンの優れた機能の1つである増分バックアップは、データベースファイルとカタログ内の最後のバックアップのファイルレベルの比較に基づいています。バーマンでは、「差分」という用語は別の概念を指します。バーマンの用語では、差分バックアップは最後のバックアップ+最後のバックアップからの個々の変更です。 Barmanのドキュメントによると、WALを介して差分バックアップを提供します。 Barmanの増分バックアップはファイルレベルで機能します。つまり、ファイルが変更された場合、ファイル全体が転送されます。これはpgbackrestに似ており、ブロックレベルの差分/増分バックアップをサポートするpg_probackupやBARTなどの他の製品とは異なります。 Barmanの増分バックアップは、 reuse_backupを介して指定されます。 =リンクまたはコピー。 「コピー」を定義することにより、変更されたファイルのみが転送およびバックアップされるため、バックアップの時間が短縮されますが、変更されていないファイルは前のバックアップからコピーされるため、スペースは削減されません。 「リンク」を定義することにより、変更されていないファイルは最後のバックアップからハードリンクされます（コピーされません）。このようにして、時間の短縮とスペースの削減の両方を実現します。これをさらに混乱させたくはありませんが、実際には、barmanは増分バックアップを（リンクまたはコピーを介して）完全バックアップとして効果的に処理するため、barman増分バックアップはpgbackrest増分バックアップと直接比較できます。したがって、どちらのシステムでも、増分バックアップは最後のバックアップ以降に変更されたファイルを処理します。ただし、差分バックアップに関しては、以下に示すように、前述の各システムで異なることを意味します。
• スタンバイからのバックアップ。 Barmanは、スタンバイからベースバックアップ操作の大部分を実行するオプションを提供し、追加されたIO負荷からプライマリを解放します。ただし、それでもWALはプライマリから取得する必要があることに注意してください。レプリケーションスロットを介してarchive_commandまたはWALストリーミングを使用するかどうかは関係ありませんが、このタスクをスタンバイにオフロードすることはまだできません（barmanがバージョン2.6になっているこの記事の執筆時点）。
• バックアップとリカバリの並列ジョブ
• 次のいずれかに基づく豊富で包括的な保持設定のセット：
  • 冗長性（保持するバックアップの数）
  • リカバリウィンドウ（過去にどの程度バックアップを保持する必要があるか）
  ユーザーの観点からの私の意見では、上記は素晴らしいです。ユーザーはreuse_backup=linkとリカバリウィンドウを定義し、barman（そのcronジョブ）に残りを処理させることができます。心配したり、スケジュールしたり、管理したりするdiff / incr/fullなどのバックアップはありません。システム（バーマン）は正しいことを透過的に実行します。
• 独自のイベント前後フックスクリプトのプログラミング。
• テーブルスペースの再マッピング

それらはバーマンの最高の強みです。そして実際、これは平均的なDBAがバックアップおよびリカバリツールに求めるものをほぼ上回っています。ただし、改善できる点がいくつかあります。

• メーリングリストはそれほど活発ではなく、メンテナが質問を書いたり回答したりすることはめったにありません
• 失敗した/中断されたバックアップを再開する機能はありません
• ネットワークの障害やバックアップサイトの他の障害の場合、レプリケーションスロットまたはアーカイブのためのrsync/barman-wal-archiveの使用は許容されません。いずれの場合も、ネットワークの停止が十分に長く、DBの変更が多くの​​WALファイルに値する場合、プライマリは「デバイスにスペースが残っていない」という問題が発生し、最終的にクラッシュします。 （良いことではありません）。ここで有望なのは、barmanがWALを転送するための代替（rsyncの）方法を提供することです。 pg_walスペースの枯渇は将来実装される可能性があり、バックアップの履歴書とともに、少なくとも私にとってはバーマンを本当に完璧にするでしょう。

pgbackrest

Pgbackrestは、オープンソースバックアップツールの現在の傾向です。これは主に、非常に大量のデータを処理する効率と、作成者がチェックサムを介したバックアップの検証に細心の注意を払っているためです。この記事の執筆時点では、バージョンv2.09であり、ドキュメントはここにあります。ユーザーガイドは少し古くなっているかもしれませんが、残りのドキュメントは非常に最新で正確です。 Pgbackrestは、独自のarchive_commandと、rsyncよりも優れた安全な独自のファイル転送メカニズムを使用したWALアーカイブに依存しています。したがって、pgbackrestは、barmanが提供するより多くの選択肢を提供しないため、かなり前向きです。同期モードが含まれていないため、当然pgbackrestはRPO =0（データ損失ゼロ）を保証しません。 pgbackrestの概念を説明しましょう：

• バックアップには次のものがあります：
  • フル。完全バックアップは、データベースクラスタ全体をコピーします。
  • 差分（diff）。差分バックアップは、最後の完全バックアップ以降に変更されたファイルのみをコピーします。復元を成功させるには、差分バックアップと以前の完全バックアップの両方が有効である必要があります。
  • インクリメンタル（増分）。増分バックアップは、最後のバックアップ（完全バックアップ、差分バックアップ、または増分バックアップの場合もあります）以降に変更されたファイルのみをコピーします。差分バックアップと同様に、復元を正常に実行するには、以前に必要だったすべてのバックアップ（このバックアップ、最新の差分、以前の完全バックアップを含む）が有効である必要があります。
• スタンザは、PostgreSQLクラスターに必要なすべてのパラメーターの定義です。通常のPostgreSQLサーバーには独自のスタンザがありますが、バックアップサーバーにはバックアップするPostgreSQLクラスターごとに1つのスタンザがあります。
• 構成は、スタンザに関する情報が保持される場所です（通常は/etc/pgbackrest.conf）
• リポジトリは、pgbackrestがWALとバックアップを保持する場所です

ユーザーは、ドキュメント自体が示唆しているように、上から下までドキュメントに従うことをお勧めします。 pgbackrestの最も重要な機能は次のとおりです。

• 並列バックアップと復元
• PostgreSQLサーバーへの直接SQLアクセスは必要ありません
• ローカル/リモート操作
• 保持に基づく：
  • 完全バックアップの保持（保持する完全バックアップの数）
  • diffバックアップの保持（保持するdiffバックアップの数）
  増分バックアップには独自の保持がなく、前のバックアップの有効期限が切れるとすぐに有効期限が切れます。そのため、ユーザーは完全バックアップとそれらの間の差分バックアップのローリングセットを作成するスケジュールを定義できます。
• スタンバイからのバックアップ。一部のファイルは引き続きプライマリから取得する必要がありますが、バルクコピーはスタンバイで実行されます。それでも、WALはプライマリから発信する必要があります。
• バックアップの整合性。 pgbackrestの背後にいる人々は、バックアップの整合性に関して非常に注意を払っています。各ファイルはバックアップ時にチェックサムされ、復元後にもチェックされ、問題のあるハードウェアまたはソフトウェアのバグが復元の失敗につながる可能性がないことを確認します。また、PostgreSQLクラスターでページレベルのチェックサムが有効になっている場合は、ファイルごとにチェックサムも計算されます。さらに、チェックサムはすべてのWALファイルに対して計算されます。
• 圧縮が無効でハードリンクが有効になっている場合は、カタログから直接クラスターを起動できます。これは、マルチTBの大規模データベースにとって非常に重要です。
• 失敗/中断されたバックの再開。信頼性の低いネットワークの場合に非常に便利です。
• デルタ復元：クラスター全体をクリーンアップせずに、大規模なデータベースを超高速で復元します。
• バックアップサーバーへの非同期および並列WALプッシュ。これはpgbackrestの最大の強みの1つです。 PostgreSQLアーカイバは、archive-pushと転送の重いジョブを介してのみスプールにコピーし、処理は別のpgbackrestプロセスで行われます。これにより、PostgreSQLの応答時間を短縮しながら、大量のWAL転送が可能になります。
• テーブルスペースの再マッピング
• AmazonS3のサポート
• 最大WALキューサイズのサポート。バックアップサイトがダウンしている場合やネットワークに障害が発生している場合、このオプションを使用すると、アーカイブが成功したかのようにモックが作成され、PostgreSQLがWALを削除して、pg_walがいっぱいになるのを防ぎ、潜在的なPANICからpgsqlサーバーを保存できます。

そのため、機能面でのpgbackrestは、データの検証とパフォーマンスに関して多くの重点を置いています。これは、最大かつ最もビジーなPostgreSQLインストールで使用されるのは当然のことです。ただし、改善できることが1つあります。

• 保持に関する限り、より「リベラルな」オプションがあると非常に便利です。つまり、保持期間を宣言的に指定し、pgbackrestに必要に応じて完全/差分/増分バックアップを処理させる方法を提供します。
>

pg_probackup

Pg_probackは、バックアップ用のもう1つの有望なツールです。もともとはpg_armanに基づいています。その重点は、バックアップのパフォーマンスにあります。これはカタログとインスタンスに基づいており、他のツールと非常によく似ているので、持っています。その主な機能は次のとおりです。

• 次の範囲の豊富なバックアップレベルのサポート：
  • 完全バックアップ
  • 3つのタイプの増分：
    • PAGEバックアップ。 WALスキャンで見つかったレベルの変化。前回のバックアップ以降、中断されていないWALシーケンスへのフルアクセスが必要です。
    • DELTAバックアップ。変更されたページのみがバックアップにコピーされます。 WALアーカイブから独立しており、サーバーに一定の負荷をかけます。
    • PTRACKバックアップ。特別なpgsqlコアパッチが必要です。ページが変更されるとすぐにその場でビットマップを維持することによって機能します。サーバーへの負荷を最小限に抑えた、非常に高速なバックアップ。
• バックアップは次のように分割することもできます。
  • 自律バックアップ。これらには、バックアップ以外のWALに関する要件はありません。 PITRはありません。
  • バックアップをアーカイブします。それらは継続的なアーカイブに依存し、PITRをサポートします。
• マルチスレッドモデル（マルチプロセスモデルに従うbarman、pgbackrest、そしてもちろんPostgreSQL自体とは対照的）
• データの一貫性と復元なしのオンデマンド検証
• プライマリにアクセスせずにスタンバイからバックアップします。
• ウィンドウとともに冗長性をAND方式で使用できる表現力豊かな保持ポリシー仕様。バックアップのマージ（マージによる）は、スペースを解放し、バックアップをスムーズにローテーションする方法を提供する方法として、以前の増分バックアップを完全に変換することでサポートされます。

したがって、pg_probackupは、大規模なインストールに役立つパフォーマンスに重点を置いた一連の優れた機能を提供します。ただし、まだ不足していることがいくつかあります。つまり、次のとおりです。

• リモートバックアップをサポートする公式リリースはありません。これは、pg_probackupがpgsqlクラスターと同じホストで実行される必要があることを意味します。 （リモートサイトからのバックアップとリモートバックアップサーバーへのアーカイブを処理する開発ブランチがあります）
• 失敗したバックアップ履歴書はサポートされていません。

上記の段落は、以下のような機能マトリックスで要約できます。

ClusterControl

ClusterControlは、即時バックアップを生成するか、バックアップをスケジュールし、タスクを簡単かつ迅速に自動化する機能を提供します。

pgdump（論理）とpg_basebackup（バイナリ）の2つのバックアップ方法から選択できます。バックアップの保存場所（データベースサーバー、ClusterControlサーバー、またはクラウド）、圧縮レベル、暗号化を指定することもできます。

また、ClusterControlを使用すると、ポイントインタイムリカバリ機能とバックアップ検証を使用して、生成されたバックアップを検証できます。