コンセプト#

ディザスターリカバリー計画の作成は、特にバックアップ管理に関係するさまざまな概念に慣れていない人にとって、難しい場合があります。バックアップにはさまざまな方法があり、それぞれに独自の長所、短所、および技術的要件があります。適切なアプローチの選択は、リソース、環境、および技術的知識によって異なります。誰もがこのコンテキストで十分な基礎を持っているわけではないことを承知で、このセクションでは、特にPostgresとBarmanのコンテキストで、データベースのバックアップに関する最も基本的な概念を説明することに専念しています。

バックアップの概念、Postgresの論理的および物理的バックアップに既に慣れている場合は、 Barman concepts and terminology セクションに進んでください。

はじめに#

完璧な世界では、バックアップは必要ありません。ただし、特に重要なビジネス環境では、予期せぬことが発生した場合に備えることが重要です。データベースシナリオでは、/"unexpected/"は次のいずれかの形式を取ることができます。

データの破損。
システム障害ハードウェア障害を含む。
人的エラー。
自然災害。

このような場合、 :term:`ICT`マネージャーまたは :term:`DBA`は、可能な限り最短の時間でインシデントを修正し、データベースを復旧できる必要があります。私たちは通常、この分野をディザスターリカバリーと呼び、より広範にはビジネス継続性と呼んでいます。

ビジネス継続性の範囲では、Wikipediaで定義されている2つの基本的なメトリックをよく理解することが重要です。

目標復旧ポイントRPO 重大なインシデントによりITサービスからデータが失われる可能性のある最大目標期間。
目標復旧時間RTO 災害または中断後に、ビジネス継続性の中断に関連する受け入れがたい結果を回避するために、ビジネスプロセスを復元する必要がある目標期間とサービスレベル。

一言で言えば、RPOは損失してもよいデータの最大量を表し、RTOはサービスに許容できる最大ダウンタイムを表します。

当然のことながら、たとえそれが祖母のレシピウェブサイトであったとしても、私たち全員がRPO=0データ損失ゼロとRTO=0ダウンタイムゼロ、理想郷を望んでいます。実際には、ビジネス継続性の要件を決定するには、注意深いコスト分析フェーズが必要です。

幸いなことに、 BarmanとPostgresで構成されるオープンソーススタックを使用すると、同期ストリーミングレプリケーションのおかげでRPO=0を達成できます。 RTOは、 Patroni や repmgr のような高可用性ソリューションの焦点です。したがって、 Barmanをこれらのツールのいずれかと統合することにより、RTOをほぼゼロに劇的に削減できます。

いずれにせよ、実際のツールではなく、ディザスターリカバリーに関連する文化的な側面をより強調することが重要です。人間のいない道具は役に立ちません。 Barmanとの私たちの使命は、次のようなディザスターリカバリーの文化を促進することです。

バックアップ手順に焦点を当てます。
リカバリー手順にさらに焦点を当てます。
チームメンバーのPostgresクラッシュリカバリー、バックアップ、ポイントインタイムリカバリー、およびレプリケーションの強力な理論的および実践的な概念に関する教育とトレーニングに依存します。
手動または自動で、バックアップのテストを促進しますテストされたバックアップのみが有効であると考えられます。Barmanのフックスクリプトを使用して創造力を発揮してください。
Devopsチームのすべてのメンバーによる、リカバリ手順の定期的な練習を促進しますはい、開発者も、システム管理者や`DBA < DBA>`だけでなく。
3〜6か月ごとに、チームとの定期的にスケジュールされた訓練とディザスターリカバリーシミュレーションを募集します。
PostgresとBarmanの継続的なモニタリングに依存し、異常を迅速に特定できます。

さらに、災害が発生した場合に自分自身とチームを準備するためにできる限りのことを行ってください。なぜなら、それが発生した場合

それは金曜日の夕方であり、おそらくあなたがオフィスを出ようとしているときです。
それは、あなたが休暇中であり、世界一周クルーズの真っ最中で、他の誰かがそれに対処しなければならないときです。
確かにストレスがたまるでしょう。
最後に利用可能なバックアップが有効であることを確認しないと後悔するでしょう。
回復するまでにおよそどれくらいの時間がかかるかを知らなければ、一秒一秒が永遠のように見えるでしょう。

2011年、これらの目標を念頭に置いて、2ndQuadrantは現在Postgresで最も使用されているバックアップツールの1つであるBarmanの開発を開始しました。 Barmanは、/"Backup and Recovery Manager/"の頭字語です。

準備をしてください、怖がらないでください。

一般的なバックアップの概念#

各データベースシステムには独自の用語がある場合がありますが、すべてのリレーショナルデータベースで一貫した基本的なバックアップ原則があります。このセクションでは、バックアップがどのように動作するかを理解するために必要な中核概念の概要を提供します。

物理的および論理的バックアップ#

リレーショナルデータベースのコンテキストでは、論理バックアップは、実行時に、バックアップが取られたときの正確な状態でデータを再作成する一連の操作に他なりません。簡単に言うと、データベースの構造とデータを再構成する一連のSQLステートメントです。この方法は、データベースバージョンやシステムアーキテクチャなどの特定の環境仕様に依存しないため、互換性のないシステム間でデータを移行する場合に適した選択です。また、特定のデータベースオブジェクトまたはテーブルの復元を許可することにより、柔軟性が向上します。

ただし、論理バックアップには時間がかかる場合があり、データベースのサイズによっては、数時間または数日かかる場合があります。また、バックアップはバックアッププロセスの開始時のデータベースの状態を反映するため、バックアップ中に行われた変更はキャプチャされず、データ損失の潜在的なウィンドウが発生します。その結果、この方法は、通常、小さくて複雑でないデータベースに推奨されます。 Postgresでは、論理バックアップは pg_dump および pg_dumpall ユーティリティを介して実装されます。

一方、物理バックアップは、ファイルシステムからデータベースファイルを直接コピーすることにより機能します。したがって、このメソッドは通常、環境仕様に関連付けられます。物理的バックアップには、 cp のような基本的なUnixツールを使用したものから、 Barmanのようなバックアップマネージャーを使用したより洗練されたソリューションに至るまで、さまざまなアプローチがあります。バックアップ管理ツールは、ファイルがデータベースの一貫した状態を表すことを保証し、サーバーを通常に実行したままにすることは、手動で行うと困難であるため、物理的バックアップにおいて重要な役割を果たします。

物理的バックアップは、データベースを再作成するために操作を完全に再生する必要がないため、バックアッププロセス中だけでなく、特にリカバリー中にも論理バックアップよりもはるかに高速です。また、インクリメンタルバックアップの可能性が有効になり、時間とストレージの使用量が大幅に削減され、より頻繁なバックアップが可能になります。最後に、このアプローチの最大の利点の1つは、ポイントインタイムリカバリーPITRを実行できることです。これにより、データベースを現在時刻とバックアップ時刻の間の特定の時点に復元できます。この機能は、トランザクションログが物理的バックアップとともにアーカイブされる場合にのみ可能です。

お気づきのとおり、物理バックアップはより堅牢ですが、より複雑です。このため、 PostgresのBarmanのような補助バックアップ管理ツールは、ディザスターリカバリー計画でこのプロセスが効果的かつ確実に処理されるようにする上で重要な役割を果たします。

バックアップの種類#

物理バックアップに関しては、基本的に3つの異なるタイプに分類できます。フル、インクリメンタル、差分。

フルバックアップはベースバックアップとも呼ばれ、特定の時点ですべてのデータをキャプチャし、基本的にデータベース全体の完全なスナップショットを作成します。このタイプのバックアップには、システムをバックアップが取られたときの正確な状態に復元するために必要なすべての情報が含まれています。この意味で、一貫した完全な物理バックアップからのリカバリは、本質的に完全であるため、可能な限り最速です。

一方、インクリメンタルバックアップは、以前のバックアップ以降に発生した変更のみをキャプチャするように設計されています。以前のバックアップは、完全バックアップまたは別のインクリメンタルバックアップのいずれかです。インクリメンタルバックアップにより、時間とストレージの使用量が大幅に削減され、より頻繁なバックアップが可能になり、その結果、データ損失のリスクが削減されます。通常、インクリメンタルバックアップは、ファイルや内部データブロックなどの低レベルのデータ構造に依存して、実際に何が変更されたかを判断するため、物理的バックアップでのみ可能です。インクリメンタルバックアップからのリカバリーには、ベースから最新のインクリメンタルまでのすべてのバックアップのチェーンが必要です。

最後に、差分バックアップは、以前のバックアップ以降に行われた変更のみをキャプチャするという点でインクリメンタルバックアップに似ています。ただし、主な違いは、差分バックアップは常に完全バックアップを基準として変更を記録し、インクリメンタルまたは別の差分バックアップとは決して相対しないことです。実際、すべての差分バックアップは増分バックアップですが、すべての増分バックアップが差分バックアップであるわけではありません。この場合のリカバリーには、最新の差分バックアップとそれに関連するベースバックアップのみが必要です。

トランザクションログ#

トランザクションログは、ほとんどのリレーショナルデータベースの基本的な部分です。これは、データベース内のすべての操作を実行前に記録する一連の連続したファイルで構成されています。その結果、彼らは一定期間にデータベースで発生したすべての変更を所有します。これは、主に、クラッシュ前にディスクにフラッシュされていない操作を再生できることにより、データベースがクラッシュから効果的に回復できることを保証し、データの損失を防ぎます。これは、データベースレプリケーションの多くの実装のキーコンポーネントでもあります。

トランザクションログは、すべての操作が永続化された後、リサイクルされます。ただし、これらのログを事前にアーカイブできる場合は、基本的にデータベースに行われたすべての変更の完全な記録を保持し、いつでも再生できます。トランザクションログのアーカイブとともにベースバックアップがあることにより、継続的なバックアップが可能になります。これは、完全なバックアップを定期的に取得することができない大規模なデータベースで特に役立ちます。差分バックアップと同様の目標を達成しますが、ポイントインタイムリカバリーなどのより堅牢な機能も有効にするため、さらに多くの機能を備えていることに気づくでしょう。

ポイントタイムリカバリー#

ポイントインタイムリカバリーを使用すると、ベースバックアップの終了時間からアーカイブされたトランザクションログでカバーされる最も遠いポイントまでの特定の瞬間にデータベースを復元できます。トランザクションログの継続的なアーカイブを維持することにより、現時点までにデータベースに加えられたすべての変更を再生できます。これは、ベースバックアップに基づいてすべてのトランザクションログを再生することにより実行され、たとえば、目的のタイムスタンプまたはトランザクションIDに基づいて、任意の時点で再生を停止する機能も提供します。 PITRでは、秒未満の精度が可能で、通常毎日実行される標準の完全バックアップと比べて、大きな利点があります。

この機能は、誤った削除や変更など、人的エラーまたは意図しない変更が発生した状況で特に役立ちます。 PITRは、データベースを不要なイベントの直前の正確な状態に復元することにより、RPOを大幅に削減します。強力な安全装置を提供し、データベースを以前の完全バックアップに戻したり、その後のすべての正当な変更を失うリスクを負うことなく、重要なデータを迅速かつ正確にリカバリーできます。

ただし、PITRがすべての問題の解決策であることを意味するわけではありません。トランザクションログの再生は、ベースバックアップからの距離によっては、依然として時間がかかる場合があります。したがって、最適なソリューションは、実際にはすべての戦略の組み合わせです。完全バックアップと頻繁なインクリメンタルバックアップ、およびトランザクションログのアーカイブ。このように、最新の状態への復元は、最新のバックアップを復元し、その後に後続のトランザクションログを再生することになります。同様に、特定のポイントへの復元は、ターゲットポイントに最も近い以前のバックアップを復元し、その後に目的のターゲットまでの後続のトランザクションログを再生することです。

Postgresバックアップの概念と用語#

このセクションでは、Postgres、その実装、および特定の特性のコンテキストでバックアップの概念を説明します。コンテンツは主に Backup and Restore section from the Postgres official documentation に基づいていますので、 Postgresがバックアップを処理する方法についてのより詳細な説明が必要な場合は、それを読むことを強くお勧めします。

pg_dump vs pg_basebackup#

Postgresでバックアップを取るための基本的に2つの主要ツール pg_dump および pg_basebackup 。それらの違いは、基本的に、論理バックアップと物理バックアップの違いです。つまり、 pg_dump pg_dumpall を含むは論理バックアップを取得し、 pg_basebackup は物理的バックアップを取得します。

注釈

Barmanは、論理バックアップで動作しないため、 pg_dump または pg_dumpall をまったく利用しません。 pg_basebackup は、構成されたバックアップ方法に応じてBarmanによって使用されます。

pg_basebackup は、基本的に、 pg_basebackup を使用して、Postgresクラスターから宛先ディレクトリにテーブルスペースがある場合を含むすべてのファイルをコピーします。クラスター全体をバックアップすることのみができ、特定のデータベースまたはオブジェクトをバックアップすることはできません。 pg_basebackup は、データベースサーバーをバックアップモードにおよび解除し、一貫性のために必要なすべてのトランザクションログがベースバックアップとともに保存されていることを確認します。そのため、 pg_dump とは異なり、 pg_basebackup で取得されたバックアップには、バックアップの進行中に発生した変更も含まれます。これは、頻繁に高負荷が発生するデータベースにとって大きな利点です。 pg_basebackup の詳細については、 pg_basebackup で読むことができます。

注釈

実際には、Postgresの物理バックアップは、少なくともバックアッププロセス中に生成されたトランザクションログPostgresのWALもある場合にのみ完全/自己完結型です。それ以外の場合、バックアップ自分自身は、新しいPostgresインスタンスを復元して起動するには不十分です。

pg_basebackup を使用して、 pg_basebackup と同様の結果を達成することもできます。これは、Postgresで物理的バックアップを取るさらに別の方法です。低レベルAPIは、代替コピーツールを使用して物理的バックアップを手動で取得する場合に使用されます。このシナリオでは、データベースサーバーを手動でバックアップモードにおよび終了し、一貫性のために必要なすべてのトランザクションログが正しくアーカイブされていることを確認する必要があります。

注釈

Barmanは、構成されたバックアップ方法に応じてPostgresの低レベルAPIを使用します backup_method = rsync 。

先行書き込みログ#

ログの先行書き込みWALは、Postgresおよびその他のデータベースがトランザクションログを参照する方法です。 Postgresでは、各WALファイルは16 MB相当の変更構成可能をサポートします。 WALファイルは次々にシークエンシャルに書き込まれ、チェックポイントが実行されるまで同時に維持されます。 Postgresのチェックポイントは、すべての変更をディスクに永続化して、後でWALをリサイクルできるようにする行為です。チェックポイントは通常5分ごと、または1GBのWALファイルが生成された後に発生し、両方のオプションを構成可能です。 WALは、クラッシュリカバリー、データベースレプリケーション、PITRに役立つだけでなく、良好なパフォーマンスを保証するための重要なコンポーネントでもあります。そうしないと、各トランザクションがコミットした後に変更をディスクに同期する必要があり、巨大なI/Oが発生します。 WALでは、データベースの一貫性を保証するために十分であるため、変更をチェックポイント時に延期できます。

WALアーカイブとWALストリーミング#

トランザクションログのアーカイブは、Postgresでは/"継続的アーカイブ"または/"WALアーカイブ"として知られています。 WALアーカイブとは、本質的に、WALファイルがリサイクルされる前に他の場所に保存できることを意味します。 Postgresでは、これを行う伝統的な方法は、サーバー構成の archive_command パラメーターを使用することです。

archive_command は、任意のシェルコマンドを値として受け入れ、完全に入力されるとWALファイルごとに実行されます。このようなコマンドは、各ファイルが目的の場所に安全にコピーされることを確認します。これにより、Postgresがこれらのファイルを保存する方法または場所について仮定を行わないという意味で、非常に高い柔軟性を提供し、必要なコマンドまたはライブラリを使用できます。このコマンドは、成功を示すゼロの終了ステータスを返す必要があります。それ以外の場合、Postgresはアーカイブが失敗したことを理解し、正常にアーカイブされるまでこれらのファイルをリサイクルしません。これは安全性の確保には役立ちますが、再び機能するか、ディスク領域が不足するまでWALファイルは蓄積され続けるため、コマンドが何らかの理由で失敗し始めると悪夢になる可能性があります。 archive_command の詳細については、こちらをご覧ください。

WALをアーカイブする別の方法は、ストリーミングレプリケーションプロトコルを使用してWALファイルを目的の場所に転送するために使用されるネイティブPostgresユーティリティである pg_receivewal を使用することです。一般にWALストリーミングとして知られるこの方法の大きな利点は、従来の archive_command 方法と比較して、ファイルがリアルタイムで転送されることです。つまり、転送を開始するためにWALセグメントが完全に満たされるまで待機する必要がないことですこれにより、データ損失の可能性が大幅に減少します。

archive_command とは異なり、デフォルトでは、この方法だけでは、WALファイルがリサイクルされる前に正常にアーカイブされることは保証されません。これは、WALファイルをアーカイブする前にリサイクルでき、基本的にログが永久に失われることを意味します。このため、このシナリオでは、レプリケーションスロットの使用を強くお勧めします。レプリケーションスロットは、主にデータベースレプリケーションのコンテキストで使用され、プライマリサーバーが後続のレプリカが必要とするWALファイルを正常に受信するまで保持し、レプリカがオフラインになるか切断された場合の安全性を高めます。 pg_receivewal とともに使用すると、同じ目標を達成します。つまり、レシーバーに正常に転送されるまで、WALファイルがリサイクルされないようにします。

リカバリー#

Postgresの復旧プロセスは、バックアップの種類によって異なります。論理バックアップの場合、このプロセスは、バックアップファイルの形式に応じて、 pg_restore を実行するか、バックアップファイルからすべてのSQLコマンドを実行するだけで簡単です。ただし、物理的バックアップの場合、プロセスは少し複雑です。

物理バックアップから正常にリカバリーするには、クラスターファイルとそのWALアーカイブの両方が必要です。少なくとも、バックアッププロセス中に生成されたWALファイルが必要です。バックアップが pg_basebackup で取得された場合、特に指定しない限り、必要なWALファイルは既に出力ディレクトリに含まれています。ただし、 Postgres低レベルAPIを使用して手動で取得した場合、リカバリ中に必要なすべてのWALファイルが利用できることを確認するのは自分の責任です。

リカバリーの準備をするには、いくつかの手順に従う必要があります。これには、 :term: PITR, among others. For a detailed explanation of this process, refer to the Postgres official documentation を実行する場合、WALアーカイブとターゲットポイントからWALファイルを取得するコマンドなど、バックアップクラスターディレクトリの構成ファイルでのいくつかのパラメーターの指定が含まれます。すべてが正しければ、バックアップから新しいインスタンスを起動できます。Postgresは、必要なWALがすべて適用されていることを確認します。

リカバリーにPostgresのインクリメンタルバックアップが含まれる場合、最初に pg_combinebackup を使用してすべてのバックアップを結合する必要があります。合成フルバックアップが生成され、標準のフルバックアップと同じ方法でリカバリーに使用できます。

Barmanの概念と用語#

このセクションでは、 Barmanの重要な概念の概要を提供し、以前のセクションで説明した概念の一部をBarmanが利用する方法を示します。

サーバー#

Barmanは、複数のデータベースサーバーのバックアップを同時に管理できます。このため、バックアップサーバーの論理的分離が必要になります。 Barmanでは、バックアップサーバーまたは単にサーバーは、特定のデータベースサーバーのバックアップコンテキストを表します。 Barmanがデータベースインスタンスと対話する方法、バックアップが管理される方法、その保持ポリシーなどを定義します。各サーバーには、すべてのバックアップとWALファイルが保存される独自の専用ディレクトリと、ほとんどのBarmanで指定する必要がある一意の名前があります。コマンドを使用して、どのコンテキストで実行するかを指定します。

バックアップ方法#

Postgres backup concepts and terminology で概要を示したように、Postgresサーバーをバックアップする方法は複数あります。 Barmanのコンテキストでは、これらはバックアップ方法と呼ばれます。 Barmanは、さまざまなバックアップ方法をサポートしており、それぞれが異なるPostgres機能に依存し、独自の要件、長所、短所があります。サーバーの構成ファイルの backup_method パラメーターを使用して、目的のバックアップ方法を指定できます。

注釈

Barmanサーバーを管理するときは、単一のバックアップ方法を使用することを強くお勧めします。バックアップ方法を変更する必要がある場合は、新しいBarmanサーバーをセットアップすることをお勧めします。

Rsyncバックアップ#

backup_method = rsync で取得されたバックアップ。このバックアップ方法を使用する場合、 BarmanはPostgres低レベルAPIとRsyncを使用して、SSH接続を介してクラスターファイルを手動で転送します。 Rsyncは、2つの場所間でファイルとディレクトリを同期できる強力なコピーツールです。同じホスト上またはネットワーク上の別のホスト上。 Barmanは、低レベルAPIを使用してサーバーをバックアップモードにおよびオフにし、同時にRsyncを使用してすべての関連ファイルをBarmanのサーバーの指定されたディレクトリにコピーします。このプロセスの最後に、 BarmanはデータベースサーバーでWALスイッチを強制して、必要なすべてのWALファイルがアーカイブされるようにします。最後に、完全性チェックが実行されて、バックアップが一貫していることを確認します。

ストリーミングバックアップ#

backup_method = postgres で取得されたバックアップ。このバックアップ方法を使用する場合、 Barmanはデータベースサーバーをバックアップするために pg_basebackup を呼び出します。 Barmanは、すべてのテーブルスペースをBarman上のサーバーの専用ディレクトリにマップします。このプロセスの最後に、 BarmanはデータベースサーバーでWALスイッチを強制して、必要なすべてのWALファイルがアーカイブされるようにします。最後に、完全性チェックが実行されて、バックアップが一貫していることを確認します。

スナップショットバックアップ#

スナップショットバックアップは、 backup_method = snapshot を設定するか、BarmanのクラウドCLIツールを直接使用して実行できます。これらのバックアップは、 Barmanをデータベースサーバーが存在するクラウドプロバイダーと統合することにより機能します。データベースのストレージボリュームのスナップショットが物理的バックアップとして取得されます。このセットアップでは、 Barmanはクラウドでバックアップを管理し、主にWALファイルとバックアップカタログのストレージサーバーとして機能します。

ファイルレベルのインクリメンタルバックアップ#

rsync バックアップを使用する場合、ファイルレベルのインクリメンタルバックアップが可能です。これは、ファイルシステムのハードリンクに依存する重複排除のRsyncネイティブ機能を使用します。ファイルレベルのインクリメンタルバックアップを実行する場合、 Barmanは最初に使用可能な最新のサーバーバックアップへのハードリンクを作成し、基本的に追加のディスク領域を消費せずにそのコンテンツを別のディレクトリにレプリケートします。次に、Rsyncを使用してその内容をPostgresクラスターのコンテンツと同期し、変更されたファイルのみをコピーします。ハードリンクを使用せずにファイルレベルのインクリメンタルバックアップを持つこともできます。この場合、 Barmanは最初に以前のバックアップの内容を新しいバックアップディレクトリにコピーします、基本的にそれを複製して追加のディスク領域を消費しますが、変更されたファイルのみをコピーしますデータベースサーバー。

ブロックレベルのインクリメンタルバックアップ#

streaming backups を使用する場合、ブロックレベルのインクリメンタルバックアップが可能です。 Postgres 17で導入された、インクリメンタルバックアップのネイティブ pg_basebackup 機能を活用します。この機能には、ネイティブのインクリメンタルバックアップ用に適切に構成されたバージョン17以降のPostgresインスタンスが必要です。ブロックレベルのインクリメンタルバックアップでは、有効な backup_manifest ファイルを含むバックアップを重複排除のリファレンスとして使用できます。重複排除はブロックレベルPostgresのページで発生するため、ブロックレベルのインクリメンタルバックアップはファイルレベルのインクリメンタルバックアップよりも効率的です。

`archive_command` を介したWALアーカイブ#

これは、WALファイルをBarmanに転送する2つの方法の1つです。一般的に rsync バックアップとともに使用されるこのアプローチには、 Postgresの archive_command パラメーターを構成して、WALファイルをBarmanのサーバーの専用ディレクトリに直接アーカイブすることが含まれます。コマンドは、 BarmanホストでサーバーのWALディレクトリを手動で指定するRsyncコマンド、またはサーバー名のみを必要とし、 Barmanが残りを処理する barman-wal-archive ユーティリティのいずれかです。さらに、 barman-wal-archive は、ファイルを受信するとすぐにfsyncを実行することにより、安全性を向上させます。

WALストリーミング#

これは、WALファイルをBarmanに転送する2つの方法の1つです。一般的に streaming backups とともに使用されるこのアプローチは、 pg_receivewal ユーティリティに依存してWALファイルを転送します。データベースサーバーで手動構成が必要ないため、構成が非常に簡単です。 streaming backups で述べたように、WALストリーミングを使用する場合、レプリケーションスロットをお勧めします。バックアップサーバー構成で create_slot から auto を設定することにより、事前に手動でスロットを作成するか、 Barmanにスロットを作成させることができます。

フックスクリプト#

Barmanを使用すると、開発者は操作前および/または後として特定の操作に沿ってフックスクリプトを実行できます。この機能は、開発者に、調整された多様な動作を実装する柔軟性を提供します。 rsyncを使用する場合、バックアップ後スクリプトを利用してバックアップのマニフェストを生成できます。または、バックアップ後 hook scripts with barman-cloud コマンドを組み合わせることで、バックアップをクラウドストレージにコピーできるハイブリッド分散アーキテクチャを作成できます。

このトピックのより詳細な説明については、 hook scripts のメインセクションを参照してください。

リストアとリカバリー#

Barmanでは、リカバリーは、新しい場所に必要なすべてのWALファイルとともにバックアップを復元し、リカバリーのためにPostgresインスタンスを効果的に準備するプロセスです。

リカバリーで概要を示したように、 Postgresの復旧プロセスは、ベースディレクトリの準備からサーバー自分自身の起動までのいくつかの手順で構成されています。 Barmanは、バックアップを復旧する準備に必要なすべての手順を実行できます。これは、Barmanの用語で/"restore/"と呼ばれます。この場合、復旧の完了は、通常、サーバーを起動するだけで済みますので、Postgresは必要なWALを適用してライブ開始できます。