リカバリー#

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 が必要です。

ローカルリカバリー#

--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ファイル用の十分な空き領域があることを確認します。

デルタリカバリー#

--delta-restore を使用して、barmanがカスタムテーブルスペースとともに既存の宛先ディレクトリにバックアップを上書きして復元できるようにします。

もう1つのオプションは、リカバリ操作の前にグローバル/サーバーレベルで recovery_options 構成内に delta-restore を含めて、 --delta-restore フラグを指定せずにデルタリカバリを実行することです。

recovery_options = 'delta-restore'

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

注釈

get-wal を有効にしてデルタリカバリーを実行している場合、両方を recovery_options = get-wal,delta-restore として構成に追加できます。

重要

delta-restore オプションは、次のシナリオでサポートされています delta-restore 。

Local restore of plain backups - インクリメンタル、圧縮、暗号化、またはマルチフォーマットのバックアップはサポートされていません。
Remote restore with staging_location=local - staging_location=remote の使用はサポートされていません。

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

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

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

次のいずれかのオプションを使用してリカバリ 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 を有効にしてデルタリカバリーを実行している場合、両方を recovery_options = get-wal,delta-restore として構成に追加できます。

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

barman get-wal コマンドは、 Barmanによって管理されるWALカタログへのアクセスが必要であるため、ローカルリカバリでは常に barman ユーザーとして実行する必要があります。

restore_command = 'barman get-wal SERVER_NAME %f > %p'

これは、 PostgreSQLサーバーが barman ユーザーとしても実行されることを前提としています。

別のユーザーたとえば postgres でPostgreSQLを実行する場合、あなたには以下の責任があります。

サーバーを実行するユーザーに一致するように PGDATA およびすべての表領域の所有権を更新します。
barman ユーザーとして barman get-wal を呼び出すことができるように restore_command を調整しますたとえば、そのユーザーになるように sudo または他のメカニズムを構成することにより。

言い換えれば、 barman 以外のユーザーを使用してローカルリカバリーでPostgreSQLを実行する場合、追加の構成でWALファイルを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>'"

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

バックアップは、 staging_location=remote が設定されているかどうかに関係なく、 Barmanサーバー上のステージングディレクトリに復号されます。これは、復号化がBarmanノードでローカルに発生するように設計されているためです。復号化に使用されるディレクトリは、 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回呼び出されることも意味します。

重要

staging_location=remote を使用する場合、 staging_path は、ローカルノードでの読み取りおよび書き込みのためにアクセス可能な場所を指す必要があります。これは、復号化が常にローカルノードで発生するためです。

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

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

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

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

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

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

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

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

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

Barmanは、バックアップのチェーンを組み合わせて、合成バックアップを作成します。ローカルに復元する場合、バックアップのチェーンは復元先ディレクトリに直接結合されます。リモートで復元する場合、動作は staging_location 設定によって異なります。
- staging_location=local バックアップのチェーンはBarmanサーバー上の staging_path で結合され、rsyncを使用してリモートの復元先にコピーされます。
- staging_location=remote バックアップのチェーンは、rsyncを使用してリモートサーバーの staging_path にコピーされ、リモートの復元先で結合されます。
追加の操作が必要な場合、後続の操作が完了した後にステージングディレクトリは削除されます。

重要

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

結合モード#

結合バックアップにファイルを作成するために使用される方法は、 --combine-mode コマンドの --combine-mode オプションで制御できます。

サポートされているモードは次のとおりです。

copy — チェーン内のファイルごとに標準のファイルコピーを実行します。これはデフォルトモードであり、すべてのシステムで動作します。生成されるバックアップのファイルは元のファイルから完全に独立しているため、最高レベルの安全性を提供しますが、より多くの時間、追加のディスク領域とI/Oが犠牲になります。

copy-file-range — copy_file_range システムコールを使用して、効率的なファイルコピーを行います。一部のファイルシステムでは、これは物理ディスクブロックを共有することにより --clone と同様の結果を達成できますが、他のファイルシステムでは、最適化されたパスを介してフルコピーを実行します。このモードは、現在LinuxとFreeBSDでサポートされています。バックアップマニフェストが利用できないか、互換性のあるチェックサムが含まれていない場合でも、ファイルはコピーされますが、チェックサム検証のためにブロックごとに読み取られます。

link — 可能な場合、ファイルを合成バックアップにコピーする代わりに、ハードリンクを作成します。このアプローチは場合によってはより速く、ディスク領域を節約できますが、潜在的なリスクをもたらします。復元ディレクトリに加えられた変更は、元のバックアップディレクトリにも影響を与えます。その逆も同様です。したがって、このモードは、入力ディレクトリが結合後に削除される使い捨てコピーである場合にのみ使用する必要があります。入力バックアップと出力ディレクトリは、同じファイルシステムに存在する必要があります。バックアップマニフェストに互換性のあるチェックサムが含まれていない場合、ハードリンクは作成されますが、ファイルはチェックサム計算のためにブロックごとに読み取られます。

clone — 一部のファイルシステムが提供するファイルクローン機能reflinkなどを使用して、最初にデータブロックを共有するファイルの軽量コピーを作成します。このアプローチは、リンクの速度と領域効率とコピーの分離を組み合わせます。いずれかのコピーを変更しても、他方には影響しません。このモードのサポートは、基になるファイルシステムによって異なりますたとえば、XFSおよびBtrfsはクローンをサポートしています。

これらのモードの動作の詳細については、 pg_combinebackup documentation を参照してください。

マルチフォーマットバックアップのリカバリパイプライン#

バックアップは、圧縮、暗号化、インクリメンタル、またはこれらの組み合わせが可能です。 Barmanは、復元中に必要に応じて解凍、復号、およびインクリメンタルなバックアップチェーンの組み合わせを自動的に処理することにより、復旧プロセスを合理化します。 barman restore コマンドを発行すると、 Barmanはバックアップタイプを検出し、必要なすべての操作を正しい順序で実行し、手動介入を削除します。

例

バックアップが暗号化されている場合、 Barmanは構成された encryption_passphrase_command を使用してバックアップを復号します。
バックアップが圧縮されている場合、 Barmanはデータファイルを復元する前にそれを解凍します。
バックアップがブロックレベルのインクリメンタルの場合、 Barmanは pg_combinebackup を使用してバックアップチェーンを結合して、復元可能な完全なバックアップを生成します。
バックアップが暗号化、圧縮、およびインクリメンタルの両方である場合、 Barmanは次の順序で自動的に処理します。復号、解凍、およびインクリメンタルチェーンの組み合わせ。ステップごとに、 Barmanは選択した場所に一時的なステージングディレクトリを作成します。ステップが完了すると、前のステップのステージングディレクトリが削除されます。これは、3つまでのステージングディレクトリが同時にディスク領域を使用しないことを意味します。

構成ファイルまたはコマンドライン引数として staging_path および staging_location オプションを使用して、これらの操作の場所を制御できます。この柔軟性により、特にリモート復旧シナリオで、使用可能なディスク領域とネットワーク帯域幅を最適化できます。

たとえば、バックアップが暗号化、圧縮、およびインクリメンタルであり、 staging_location=remote および staging_path=/tmp を使用したリモートリカバリーの場合

チェーン内のすべてのバックアップは、 Barmanノードのステージングパスたとえば /tmp/decrypt-staging-location に復号されます。
次に、それらはrsyncでリモートノードたとえばリモートノードの /tmp/rsync-staging-location のステージングディレクトリにコピーされ、コピーが完了すると、 Barmanノードのステージングパス /tmp/decrypt-staging-location が削除されます。
次に、コピーされたバックアップは別のリモートステージングディレクトリなどに解凍されます。リモートノード上の /tmp/decompress-staging-location 、解凍後、リモートノード上のステージングパス /tmp/rsync-staging-location が削除されます。
最後に、解凍されたファイルは、復元先を出力として使用する合成バックアップに結合されます。
この後、解凍ステージングディレクトリ /tmp/decompress-staging-location も削除されます。

staging_location=local の場合、すべての操作はBarmanサーバーで実行されますが、順序はわずかに異なります。rsyncコピーは最後に遅延されます。結合オペレーションは独自の staging_path を使用し、最後のステップは、合成バックアップをリモートノードのリストア先に転送することです。

.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ファイルがないかを確認します。

no-get-wal でリカバリーする場合、 BarmanはアーカイブされたすべてのWALを宛先ノードにコピーします。この場合、部分的なWALファイルはコピーされず、トランザクションからの最終的な損失データは部分ファイルに記録されます。

このような制限を回避するには、 streaming_wals_directory にある部分WALファイルを宛先ノードの streaming_wals_directory にコピーし、`.partial`サフィックスなしで名前を変更できます。

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

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 セクションで作業している特定のクラウドプロバイダーを参照してください。