Backup commands¶
バックアップコマンドは、Barmanのバックアップカタログに既に存在するバックアップで直接機能するコマンドです。
注釈
barman list-backups <server_name> でバックアップIDを取得できることに注意してください
バックアップIDのショートカット¶
Barmanでは、特別なキーワードを使用して特定のバックアップを識別できます。
last/latest：カタログ内の最新のバックアップを識別しますfirst/oldest：カタログ内の最も古いバックアップを識別しますlast-failed：カタログ内の最新の失敗したバックアップを識別します
これらのキーワードをBarmanコマンドで使用すると、サーバーのバックアップの正確なIDを知らなくてもアクションを実行できます。たとえば、次を発行できます。
barman delete <server_name> oldest
カタログで使用可能な最も古いバックアップを削除し、ディスク領域を再利用します。
さらに、 --name <friendly_name>
オプションを使用してバックアップを取得した場合、バックアップIDの代わりにフレンドリ名を使用して、その特定のバックアップを参照できます。
check-backup¶
バージョン2.5以降、完全バックアップの一貫性に必要なすべてのWALファイルがcheck-backup
コマンドを使用してbarman
によって正しくアーカイブされたことを確認できます。
barman check-backup <server_name> <backup_id>
重要
このコマンドは、 cron によって、および`backup` 操作の終了時に自動的に呼び出されます。これは、通常の状況では、実行する必要がないことを意味します。
バックアップの最初から最後までの1つ以上のWALファイルがまだアーカイブされていない場合、
barman はバックアップにWAITING_FOR_WALS のラベルを付けます。
cron
コマンドは、不足しているWALファイルがアーカイブされていることを引き続き確認し、バックアップにDONE
のラベルを付けます。
バックアップの最後に必要な最初のWALファイルがない場合、そのようなバックアップはFAILED
としてマークされます。したがって、バックアップ操作を実行する前に、特にスタンバイサーバーからバックアップする場合、WALアーカイブ（ストリーミングまたはarchive_command
を介して）が適切に機能していることを確認することが重要です。
delete¶
次のコマンドで特定のバックアップを削除できます。
barman delete <server_name> <backup_id>
delete
コマンドは、バックアップを識別するために バックアップIDのショートカット を受け入れます。
keep¶
サーバーの保持ポリシーを超えて保持したいバックアップがある場合は、次のようにアーカイブバックアップにすることができます。
barman keep <server_name> <backup_id> [--target TARGET, --status, --release]
TARGET の可能な値は次のとおりです。
・ full
：バックアップでいつでも最新の状態に復元できます。これを達成するために、
Barmanはバックアップと後続のすべてのWALの一貫性を保証するために必要なすべてのWALを保持します。
standalone：バックアップは、サーバーをバックアップが取られた時点の状態に回復するためにのみ使用できます。 Barmanは、バックアップの一貫性を保証するために必要なWALのみを保持します。
--status オプションが指定されている場合、
Barmanはバックアップのアーカイブステータスを報告します。これは、アーカイブとしてフラグが付けられていないバックアップの場合はfull
またはstandalone のリカバリターゲットになります。
--release オプションが提供されている場合、
Barmanはこのバックアップからkeepフラグを解放します。これにより、アーカイブステータスが削除され、直接または保持ポリシーによって削除できるようになります。
バックアップにアーカイブバックアップとしてフラグが付けられると、 Barmanの動作が次のように変更されます。
barman deleteを使用してIDでそのバックアップを削除しようとすると失敗します。保持ポリシーはそのバックアップを
OBSOLETEと見なさないため、barman cronはそのバックアップを削除しません。そのバックアップに必要なWALは永久に保持されます。指定されたリカバリターゲットが
fullの場合、後続のすべての WALも保持されます。
これは、 barman keep <server_name> <backup_id> --release
でkeepフラグを削除することで元に戻すことができます。
警告
サーバーの保存方針で`standalone` アーカイブバックアップが必要なくなると、 barman cron はそのバックアップと次の最新のバックアップのbegin_wal値の間のWALを削除します。これは、ターゲットを full から standalone に変更するのは安全ですが、最新のポイントインタイムへのリカバリに必要なWALがまだ利用できます。
list-files¶
次を使用して、特定のバックアップのファイル（ベースバックアップと必要なWALファイル）をリストできます。
barman list-files [--target TARGET_TYPE] <server_name> <backup_id>
--target TARGET_TYPE
オプションを使用すると、特定のバックアップのリストの内容を選択できます。
TARGET_TYPE の可能な値は次のとおりです。
data：データファイルをリストしますstandalone：必要なWALファイルを含むベースバックアップファイルをリストしますwal：ベースバックアップの先頭から次のバックアップの先頭まで（またはログの末尾まで）のすべてのWALファイルをリストしますfull：data+walと同じ
TARGET_TYPE のデフォルト値はstandalone です。
重要
list-files コマンドは外部ツールとの相互作用を促進するため、 Barmanをアーカイブ手順に統合するのに非常に役立ちます。
recover¶
recover コマンドは、 backup
コマンドを使用してバックアップを実行した後、サーバー全体を回復するために使用されます。
これは、次のようなコマンドを発行して実現されます。
barman@backup$ barman recover <server_name> <backup_id> /path/to/recover/dir
重要
PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合は、リカバリーを発行する前に停止することを忘れないでください。これは、テーブルスペースディレクトリにも適用されます。
リカバリの実行の最後に、選択したバックアップがローカルにリカバリされ、宛先パスにはPostgreSQLインスタンスの起動に使用できるデータディレクトリが含まれます。
重要
ユーザー`barman` としてこのコマンドを実行すると、データベースのスーパーユーザーになります。
バックアップの特定のIDは、 :ref:``list-backups`<list-backups>`
コマンド。
重要
Barmanは現在、PGDATA内のシンボリックリンクを追跡しません（pg_tblspc内のテーブルスペースを除く）。システム管理者は、シンボリックリンクを追跡し、元の場所に復元する必要がある場合に備えて、ディザスターリカバリー計画/手順に追加することをお勧めします。
recoveryコマンドには、コマンドの動作を変更するオプションがいくつかあります。
リモートリカバリー¶
リカバリーコマンドの呼び出しに--remote-ssh-command <COMMAND>
オプションを追加します。これにより、
Barmanは提供されたコマンドを使用してリモートホストに接続し、リモートサーバーでコピーを実行できます。
注釈
リモートホストでリカバリを実行するには、 postgres ユーザーを使用することをお勧めします。
重要
PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合は、リカバリーを発行する前に停止することを忘れないでください。これは、テーブルスペースディレクトリにも適用されます。
リモートリカバリの既知の制限は次のとおりです。
Barmanは、 Barman構成の
recovery_optionパラメーターで :ref:``get-wal`<get-wal>` コマンドが指定されていない限り、システム一時ディレクトリに少なくとも4GBの空き領域を必要とします。Barmanとリモートホスト間のSSH接続は、公開キー交換認証方法を使用する必要があります
リモートユーザーは、宛先ディレクトリにバックアップのディレクトリ構造を作成できる必要があります。
*リモートサーバーには、ベースバックアップとリカバリに必要なWALファイルを含めるための十分な空き領域が必要です。
表領域のリマッピング¶
Barmanは、recoverコマンドに–tablespaceオプションを使用して、1つ以上のテーブルスペースを自動的にリマップできます。このオプションは、NAME:DIRECTORY
形式を使用して、値のペアを引数として受け入れます。
NAMEは表領域の識別子DIRECTORYは、テーブルスペースの新しい宛先パスです
宛先ディレクトリが存在しない場合、 Barmanは作成しようとします（必要な権限があると仮定）。
ポイントインタイムリカバリ¶
BarmanはPostgreSQLのポイントインタイムリカバリ（PITR）をラップしているため、タイムスタンプ、復元ラベル、またはトランザクションIDとしてリカバリターゲットを指定できます。
重要
特定のバックアップの最も古いPITRは、ベースバックアップ自分自身の最後です。バックアップの開始から終了までの任意の時点を回復する場合は、以前のバックアップを使用する必要があります。 Barman 2.3から、 --target-immediate オプションを使用して、一貫性に達したときにリカバリを終了できます。
リカバリターゲットは、次の相互に排他的なオプションのいずれかを使用して指定できます。
--target-time TARGET_TIME: タイムスタンプを指定する--target-xid TARGET_XID: トランザクションIDを指定する--target-lsn TARGET_LSN: ログシーケンス番号（LSN）を指定するには - PostgreSQL 10以降が必要--target-name TARGET_NAME: pg_create_restore_point(name)関数で以前に作成した名前付け復元ポイントを指定します--target-immediate: 一貫した状態に到達すると、リカバリが終了します（つまり、ベースバックアッププロセスが終了します）
重要
時間、XID、およびLSNを介したリカバリターゲットは、バックアップの終了後にある必要があります。バックアップの開始から終了までの時点に回復する場合は、カタログ内の以前のバックアップから回復する必要があります。
--exclusive
オプションで、リカバリー対象の直前で停止するか直後で停止するかを指定できます。
Barmanでは、 --target-tli
オプションを使用して、回復のターゲットタイムラインを指定できます。これは、数値のタイムラインIDまたは特別な値latest
（WALアーカイブ内の最新のタイムラインに回復する場合）およびcurrent
（バックアップが作成されたときのタイムラインに回復する場合）のいずれかに設定できます。このオプションを省略すると、PostgreSQLバージョン12以降はlatest
タイムラインに回復し、12未満のPostgreSQLバージョンはcurrent
タイムラインに回復します。
「始める前に」セクションで説明されているように、タイムラインの詳細については、PostgreSQLのドキュメントをご覧ください。
Barman 2.4では、 --target-action
オプションのサポートが導入され、次の値を受け入れます。
shutdown: 回復目標に到達したら、PostgreSQLをシャットダウンするpause：復旧目標に到達すると、PostgreSQLを一時停止状態で起動し、ユーザーがインスタンスを検査できるようにしますpromote: リカバリターゲットに到達すると、PostgreSQLはリカバリを終了し、マスターに昇格します
重要
デフォルトでは、ターゲットアクションは定義されていません（後方互換性のため）。 --target-action オプションでは、ポイントインタイムリカバリターゲットを指定する必要があります。
上記の設定の詳細については、 PostgreSQL documentation on recovery target settings を参照してください。
Barman 2.4は、 recover コマンドの--standby-mode
オプションも追加します。指定された場合、 standby.signal
ファイル（PostgreSQL 12から）を作成するか、生成されたリカバリー構成に
standby_mode = on
を追加することにより、リカバリーされたインスタンスをスタンバイとして適切に構成します。スタンバイモードの詳細については、PostgreSQLのドキュメントをご覧ください。
BarmanサーバーからWALを取得する¶
barman recover
コマンドは、リカバリ中にBarmanからWALをフェッチするようにPostgreSQLを構成できます。これは、
get-wal section で説明されているように、
recovery_options
グローバル/サーバー構成オプションを 'get-wal'
に設定することで有効になります。 recovery_options
が設定されていないか空の場合、 Barmanは代わりにbarman recover
コマンドの実行中にリカバリーに必要なWALをコピーします。
--get-wal および--no-get-wal オプションを使用して、
recovery_options で定義された動作をオーバーライドできます。
--get-wal とbarman recover を使用して、
BarmanサーバーからのWALのフェッチを有効にするか、 --no-get-wal
を使用して無効にします。
圧縮されたバックアップの回復¶
backup_compression
オプションを使用してバックアップが圧縮されている場合、
barman recover
はリカバリ時にバックアップを解凍できます。これはマルチステップのプロセスです。
1.圧縮されたバックアップファイルは、Rsyncを使用してローカルまたはリモートサーバー上のステージングディレクトリにコピーされます。
圧縮ファイルがターゲットディレクトリに解凍されます。
Barmanによる特別な処理が必要な構成ファイルは、復元先からコピーされ、必要に応じて分析または編集され、Rsyncを使用して復元先にコピーされます。
バックアップのステージングディレクトリが削除されます。
barmanは展開される環境について何も知らないため、ステージングディレクトリに適切な場所を選択するためにrecovery_staging_path
オプションに依存しています。
backup_compression
オプションを使用している場合はする必要があります
したがって、グローバル/サーバー構成でrecovery_staging_path
を設定するか* barman recover
コマンドで--recovery-staging-path
オプションを使用します。これらのいずれも行わずに圧縮されたバックアップを復元しようとすると、
Barmanは適切な場所を推測しようとせずに失敗します。
show-backup¶
次を使用して、特定のサーバーの特定のバックアップについて使用可能なすべての情報を取得できます。
barman show-backup <server_name> <backup_id>
show-backup
コマンドは、バックアップを識別するために バックアップIDのショートカット を受け入れます。
