リカバリー#

resumeコマンドは、backupコマンドで作成されたバックアップからPostgresサーバー全体を復元するために使用されます。バックアップを作成するときに、バックアップを一意に識別する backup_id が割り当てられます。 resumeコマンドを使用するには、次を実行します。

barman restore [OPTIONS] SERVER_NAME BACKUP_ID DESTINATION_PATH

backup_id を auto として指定することにより、バックアップを復元できます。この場合、 Barmanはカタログから最適なバックアップを自動的に選択します。リカバリターゲットが提供されない場合、デフォルトで最新の使用可能なバックアップが選択されます。復旧ターゲットが指定されている場合、 Barmanはそれを使用して、復旧基準に基づいて適切なバックアップを特定します。

target_time Barmanは、 target_time 、たとえば 2025-01-21 10:00:00 までで使用可能な最新のバックアップを取得します。
target_lsn Barmanは、 target_lsn 、たとえば 3/64000000 までで使用可能な最新のバックアップを取得します。
target_tli Barmanは、タイムライン target_tli 、たとえば 2 から利用可能な最新のバックアップを取得します。
target_tli 、他の2つのターゲットのいずれかと組み合わせた場合Barmanは、 target_tli に属する target_lsn または target_time までで利用可能な最新のバックアップを取得します 2025-01-21 10:00:00 タイムライン 2 から 2025-01-21 10:00:00 。

注釈

Barmanのリカバリーの概念をより明確に理解するためには、リストアとリカバリーを参照してください。
バックアップは指定されたディレクトリに復元され、Postgresインスタンスを起動する準備が整います。
list-backups コマンドを使用して、必要な特定のバックアップIDを見つけます。
Barmanは、PGDATA内のシンボリックリンクを追跡しませんテーブルスペースを除きます。シンボリックリンクを管理し、ディザスターリカバリー計画に含めます。
backup_id を auto として指定する場合、 Barmanは backup_id を考慮しません。選択したバックアップが特定の引数を必要とするか、特定のオプションをサポートしていない場合、復元は失敗する場合があります。このような場合、それに応じてrestoreコマンドを調整するのに役立つエラーメッセージを受け取ります。たとえば、スナップショットバックアップを復元する場合は、 --snapshot-recovery-instance が必要です。

危険

宛先ディレクトリをPostgresインスタンスがアクティブに実行されている場所に設定してrestoreコマンドを実行しないでください。そのディレクトリを再利用する場合は、テーブルスペースディレクトリのリカバリを含む、リカバリを開始する前にPostgresが完全に停止していることを確認してください。

ローカルリカバリー#

--remote-ssh-command が存在しない場合、 Barmanはバックアップをローカルに復元します DESTINATION_PATH で指定されたパス。

すべてのファイルとディレクトリは、 barman ユーザーが所有します。したがって、Postgresを起動してリカバリーを実行するときは、2つのオプションがあります。

barman ユーザーとしてPostgresを起動します。この場合、 --get-wal を使用すると、 restore_command は sudo を必要とせずに get-wal を呼び出すことができます。
postgres ユーザーとしてPostgresを起動します。この場合、サーバーを起動する前に、復元されたすべてのファイルとディレクトリこれにはPGDATAおよびテーブルスペースを含むの所有権を postgres ユーザーに変更する必要があります。 --get-wal を使用する場合、 restore_command は sudo を使用して、 barman ユーザーとして get-wal を実行する必要があります。

WALリストアの設定の詳細については、 Fetching WALs を確認してください。

リモートリカバリー#

--remote-ssh-command COMMAND を使用して、SSHを介してリモートサーバーでリカバリを実行します。リモート復旧のターゲットノードでpostgresユーザーを使用することをお勧めします。

Known Limitations

get-wal が指定されない限り、システムの一時ディレクトリに少なくとも4GBの空き領域が必要です。
SSHは公開キー認証を使用する必要があります
リモートユーザーは、必要なディレクトリ構造を作成できる必要があります。
リモートサーバーにベースバックアップとWALファイル用の十分な空き領域があることを確認します。

テーブルスペースのリマッピング#

--tablespace NAME:DIRECTORY を使用して、表領域を新しい場所に再マップします。 Barmanは、宛先ディレクトリが存在しない場合、作成しようとします。

危険

デフォルトでは、テーブルスペースはソースサーバーにあったのと同じパスに復元されます。 Postgresインスタンスが既に存在する宛先に、リマッピングを行わずにバックアップを復元する場合、既存のテーブルスペースディレクトリをオーバーライドする可能性があるため、注意してください。

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

次のいずれかのオプションを使用してリカバリ target を指定します。

--target-time 特定のタイムスタンプにリカバリーします。
--target-xid 特定のトランザクションIDにリカバリーします。
--target-lsn ログシーケンス番号にリカバリーします。
--target-name 名前付けの復元ポイントにリカバリーします。
--target-tli 特定のタイムラインにリカバリーします。
--target-immediate 一貫した状態に到達したら、リカバリーを終了します。

注釈

復旧ターゲットは、バックアップ終了後の値である必要があります。バックアップ内のポイントインタイムにリカバリするには、以前のバックアップを使用します。
--target-time のタイムスタンプで指定されない場合、タイムゾーンはデフォルトのBarmanホストになります。
--exclusive を使用して、ターゲットの直前で停止するか、ターゲットを含めて停止するかを制御します。
--target-tli は、ターゲットタイムラインを設定します。数値IDまたはショートカット値 latest または current を使用します。
少なくとも1つの`--target-*オプションが指定される場合、バックアップの復元時にBarmanによって ``recovery.signal` ファイルが作成され、ターゲットリカバリを開始するようにサーバーに通知されます。
backup_id を auto として指定する場合、許可されるリカバリターゲットはのみです --target-time 、 --target-lsn および --target-tli 。 --target-time および --target-lsn は相互排他的であるが、 --target-tli は独立してまたは --target-time または --target-lsn とともに使用できることに注意してください。

前述のターゲットは、次の値を取ることができる --target-action で使用できます。

shutdown 目標に到達したら、Postgresをシャットダウンします。
pause ターゲットに到達したら、検査のためにPostgresを一時停止します。
promote ターゲットに到達すると、Postgresをプライマリに昇格させます。

--standby-mode を呼び出すことにより、インスタンスをスタンバイとして構成することもできます。バックアップが復元された後、復元されたノードをリカバリモードで起動する前に、目的の上流ノードに接続するように構成を変更してください。

注釈

--standby-mode を指定すると、 recovery.signal ファイルの代わりに standby.signal ファイルが作成されます。
--standby-mode を使用する場合、可能ですが、 --target-* オプションを設定する必要はありません。

参考

For more information regarding Postgres recovery behavior, refer to Archive Recovery and Recovery Target

BarmanからWALの取得#

--get-wal を使用して、リカバリ中にBarmanからWALを取得するようにPostgresを構成します。設定されていない場合、 Barmanはrestoreコマンドの一部としてPostgresリカバリに必要なすべてのWALをコピーします。

注釈

--target-xid 、 --target-name 、または --target-time などのターゲットで --no-get-wal を使用する場合、 BarmanはWALアーカイブ全体をコピーして可用性を保証します。

もう1つのオプションは、復旧オペレーションの前にグローバル/サーバーレベルで recovery_options 構成内に get-wal を含めて、リカバリプロセス中に --get-wal を指定せずにWALファイルを取得し、 Barmanサーバーを効果的にサーバーのWALハブに変えることです。

recovery_options = 'get-wal'

復元中に get-wal が含まれる場合、 Barmanは、リカバリがローカルかリモートかに応じて、 barman get-wal または barman-wal-restore のいずれかを使用して必要なWALファイルを取得するように restore_command を設定します。

recovery_options で get-wal が指定されているが、特定のリカバリー中には必要ない場合、 barman restore コマンドで --no-get-wal オプションを使用して無効にできます。

ローカルリカバリーでの `get-wal` の使用#

次に、ローカルリカバリの restore_command の例を示します。

restore_command = 'sudo -u barman barman get-wal SERVER %f > %p'

barman get-wal コマンドは、カタログからWALファイルにアクセスするために必要な権限を持つ barman ユーザーとして実行する必要があることに注意してください。この例で sudo -u barman を使用するのはそのためです。

postgres ユーザーが barman ユーザーとして get-wal コマンドを実行できるようにするには、次の行を /etc/sudoers ファイルに追加しますSERVERを実際のサーバー名に置き換えます。

postgres ALL=(barman) NOPASSWD: /usr/bin/barman get-wal SERVER *

リモートリカバリーでの `get-wal` の使用#

リモートリカバリーの場合、 recovery_options を get-wal に設定すると、SSH接続エラーをより堅牢に処理するように設計された recovery_options スクリプトを使用して restore_command が作成されます。

このスクリプトは、WALファイルの自動圧縮および解凍や peek 機能などの便利な機能を提供し、Postgresが以前のWALファイルを処理しているときに今後のWALファイルを取得でき、 PostgresとBarman間の帯域幅を最適化します。

barman-wal-restore は、 barman-cli パッケージに含まれています。次に、 barman-wal-restore の restore_command の例を示します。

restore_command = 'barman-wal-restore -U barman backup SERVER_NAME %f %p'

ここで、 backup は、 Barmanがインストールされているホストを指します。 SSH経由で通信するため、 postgres ユーザーがバックアップサーバーに barman としてログインするには、SSHキー認証が必要です。デフォルト以外のSSHポートを使用する必要がある場合は、 --port オプションで指定できます。

barman-wal-restore がBarmanサーバーに接続できること、および必要なPostgresサーバーがWALファイルを送信するように設定されていることを確認するには、次のコマンドを使用します。

barman-wal-restore --test backup pg DUMMY DUMMY

ここで、 backup はBarmanがインストールされているホストを指し、 pg はBarmanで構成されたPostgresサーバーの名前であり、 DUMMY はプレースホルダーとして機能しますスクリプトには、WALファイル名と宛先ディレクトリの2つの引数が必要ですが、これらは無視されます。

すべてが正しく設定されている場合、次が表示されます。

Ready to retrieve WAL files from the server pg

barman-wal-restore コマンドの詳細については、 barman-cli がインストールされたホストで man barman-wal-restore と入力するか、 barman-wal-restore コマンドリファレンスを参照してください。

Tip

pg_wal ディレクトリと spool ディレクトリの両方が同じファイルシステムにある場合、ファイルはコピーされるのではなく名前が変更されるため、WALファイルの提供が速くなります。ただし、これらのディレクトリが別のファイルシステム上にある場合、操作にはファイルのコピーと元の削除の両方が含まれるため、パフォーマンスの向上はありません。 WALファイル管理効率を最適化するために、ファイルシステムの場所に注意してください。

暗号化されたバックアップの復元#

暗号化されたバックアップとWALは、復元フェーズで最終的な宛先にコピーされる前に復号されます。リストア中に、プライベートキーのパスフレーズを取得するコマンドが encryption_passphrase_command に存在する必要があります。このコマンドは、パスフレーズを標準出力に出力する必要があり、パスワードボールト、外部キー管理サービス、ファイルなどの安全な場所からパスフレーズを取得するために使用できます。

これらは、パスフレーズコマンドを設定する方法のいくつかの例です。

環境変数からの読み取りの例

encryption_passphrase_command="echo $BARMAN_PASSPHRASE"

ファイルからの読み取りの例

encryption_passphrase_command="cat /path/to/barman_passphrase"

HashiCorp Vaultからの読み取り例

encryption_passphrase_command="vault kv get -field=<FIELD> <KEY>"

AWS Secret Managerからの読み取り例

encryption_passphrase_command="aws secretsmanager get-secret-value --secret-id
<SECRET_NAME>  --profile <AWS_PROFILE> --output text --query SecretString | jq -r
'.<SECRET_KEY>'"

バックアップの復号化は次のように発生します。

バックアップは、 Barmanサーバー上のステージングディレクトリに復号されます。この場所は、 local_staging_path オプションで定義されます。
解凍や組み合わせなど、インクリメンタルバックアップの場合など、追加の操作が必要な場合、それらはステージングディレクトリのコンテンツをソースとして使用して実行されます。それ以外の場合、復号化されたファイルは最終的な宛先に直接コピーされます。
ステージングディレクトリは、復元が完了すると削除されます。

WALファイルの復号化は、リカバリ中にファイルが取得される方法によって異なります。

--no-get-wal オプションデフォルトを使用する場合、必要なWALファイルはすべてステージングディレクトリに復号され、最終的な宛先にコピーされます。これは、 encryption_passphrase_command が1回呼び出され、出力がすべてのWALファイルに再利用されることを意味します。また、コマンドは barman restore コマンドの実行中にのみ必要であり、Postgresリカバリプロセス中には必要ありません。
--get-wal オプションを使用すると、復旧プロセス中に必要に応じて、WALファイルがPostgresサーバーに提供されます。このシナリオでは、 BarmanはPostgresサーバーに送信する前に、各WALファイルをローカルで復号化します。これは、 restore_command を介して取得されるWALファイルごとに encrytion_passphrase_command が1回呼び出されることも意味します。

圧縮バックアップの復元#

backup_compression オプションを使用してバックアップが圧縮されている場合、 Barmanはリストア中にそれを解凍できます。

このプロセスには、いくつかの手順が含まれます。

圧縮されたバックアップファイルは、Rsyncを使用してローカルまたはリモートサーバーのステージングディレクトリにコピーされます。
これらのファイルは、復元先ディレクトリに解凍されます。
リモートリカバリーの場合、特別な処理を必要とする構成ファイルは、復元先ディレクトリからbarmanノードのローカル一時ディレクトリにコピーされ、必要に応じて編集および変更されて、Rsyncを使用してリストアディレクトリに戻されます。ローカル復旧の場合、ローカル一時ディレクトリは復元先自分自身であるため、編集とマングリング操作はインプレースで実行されます。バックアップディレクトリには圧縮されたtarballファイルのみが含まれているため、 Barmanは復元ディレクトリ内の個々のファイルにのみアクセスできるため、この中間手順が必要です。
ステージングディレクトリは、復元が完了すると削除されます。

Barmanは展開環境の知識がないため、 recovery_staging_path オプションに依存してステージングディレクトリの適切な場所を決定します。グローバル/サーバー構成でオプションを設定するか、 barman resumeコマンドで --recovery-staging-path オプションを使用します。 Barmanは自分自身で適切な場所を推測できないため、そうしないとエラーが発生します。

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

ブロックレベルのインクリメンタルバックアップから復旧する場合、 Barmanは pg_combinebackup を使用してバックアップチェーンを結合します。このチェーンは、ルートバックアップと、リカバリされるものまでの後続のすべての増分バックアップで構成されています。

ブロックレベルのインクリメンタルバックアップから正常にリカバリーするには、グローバル/サーバー構成で local_staging_path を指定するか、 barman resumeコマンドで --local-staging-path オプションを使用する必要があります。 Barmanは適切なステージング場所を自動的に決定できないため、そうしないとエラーが発生します。

このプロセスには、次の手順が含まれます。

Barmanは、バックアップのチェーンを組み合わせて、合成バックアップを作成します。これは、 Barmanサーバー上のステージングディレクトリで pg_combinebackup を使用して実行されます。 Barmanは、バックアップのIDを使用してステージングディレクトリ内にサブフォルダーを作成します。
復旧がローカルの場合、合成バックアップはターゲットの場所に直接移動します。リモートリカバリの場合、合成バックアップはRsyncを使用してターゲット場所に転送されます。
復元が完了すると、バックアップの結合に使用されるローカルステージングディレクトリの一時サブフォルダーが削除されます。ローカルステージングディレクトリ自分自身は保持されます。

重要

チェーン内のバックアップがチェックサムを無効にして取得されたが、最終的なバックアップでチェックサムが有効になっている場合、結果の合成バックアップには、無効なチェックサムを含むページが含まれる場合があります。詳細については、 pg_combinebackup documentation の制限を参照してください。

.partial WALファイルの制限#

streaming_archiver を使用する場合、 Barmanは pg_receivewal を利用して、ネイティブストリーミングレプリケーションプロトコルを介してPostgresサーバーマスターまたはスタンバイからトランザクションログを継続的に受信します。デフォルトでは、 pg_receivewal はこれらのログを .partial サフィックスを持つファイルに書き込み、これらがまだ完了していないことを示します。 Barmanは、 streaming_wals_directory でこれらの .partial ファイルを探します。 pg_receivewal はファイルが完了すると、 .partial サフィックスを削除し、永続的なストレージと圧縮のためにBarmanの archive-wal コマンドに渡します。

マスターPostgresサーバーに突然障害が発生し、復旧できない場合、 Barmanにストリーミングされた .partial ファイルには、アーカイブプロセスに配信されなかった重要なデータが含まれている可能性があります。

Barmanバージョン2.10以降、 get-wal コマンドは、 --partial または -P オプションを使用して、現在の .partial WALファイルのコンテンツを取得できます。これは、完全な復元を実行するか、ポイントインタイムリカバリーを実行するかにかかわらず、リカバリーに役立ちます。 get-wal を使用し、 --standby-mode を使用せずにrestoreコマンドを開始すると、 Barmanは barman-wal-restore コマンドに -P オプションを自動的に含めて、 .partial ファイルを処理します。

さらに、 get-wal は、 incoming ディレクトリをチェックして、 Barmanに送信されたがまだアーカイブされていないWALファイルがないかを確認します。

外部構成ファイルの管理#

Barmanは、バックアップが最初に取得された方法に応じて、異なる方法で外部構成ファイルを復元します。 rsync バックアップを復元する場合、外部ファイルは元の場所ではなく、rsyncを介して`PGDATA`ディレクトリに復元されます。構成ファイルに関連するものを含む、潜在的に危険な設定に関する警告が発行されます。対照的に、 postgres バックアップを復元する場合、外部ファイルはバックアップされていないため、復元されません。警告は、復元されなかったファイルについてユーザーに通知します。

バックアップの章の Managing external configuration files セクションを参照して、バックアップを作成するときに外部ファイルがどのように処理されるかを理解します。

スナップショットバックアップからの復旧#

Barmanは現在、スナップショットバックアップからの完全な自動リカバリーをサポートしていません。この制限は、スナップショットのリカバリーには、新しいインフラストラクチャのプロビジョニングと管理が必要であり、このタスクは、TerraformやOpenTofuのような専用の`IAC`ソリューションで処理するのに最適なタスクであるために発生します。

ただし、 barman resumeコマンドを使用して、スナップショットリカバリインスタンスを検証し、安全でない設定のPostgres構成を確認したり、必要なPITRオプションの構成などのリカバリ後のタスクを実行することはできます。また、このコマンドは、 backup_label ファイルはボリュームスナップショットに含まれていないため、 backup_label ファイルをコピーし、必要なWALファイルを転送します。 --get-wal リカバリオプションが指定されていない場合、 WAL。

barman-cloud-backup で作成したバックアップから復元する場合、 barman restore の代わりに barman-cloud-restore コマンドを使用する必要があります。

注釈

クラウドプロバイダーを使用する場合、同じ要件と構成が復元に適用されます。 Requirements and Configuration セクションと、 Requirements and Configuration セクションで作業している特定のクラウドプロバイダーを参照してください。