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の代わりにフレンドリ名を使用して、その特定のバックアップを参照できます。

バックアップの確認

バージョン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 を介して）が適切に機能していることを確認することが重要です。

削除する

次の方法で特定のバックアップを削除できます。

barman delete <server_name> <backup_id>

delete コマンドは、バックアップを識別するために バックアップIDのショートカット を受け入れます。

維持する

サーバーの保持ポリシーを超えて保持したいバックアップがある場合は、次のコマンドを使用してアーカイブバックアップにすることができます。

barman keep <server_name> <backup_id> [--target TARGET, --status, --release]

TARGET の可能な値は次のとおりです。

  • full ：バックアップは、常に最新の時点に回復するために使用できます。これを達成するために、 Barmanは、バックアップと後続のすべてのWALの一貫性を保証するために必要なすべてのWALを保持します。

  • standalone ：バックアップは、サーバーをバックアップが取られた時点の状態に回復するためにのみ使用できます。 Barmanは、バックアップの一貫性を確保するために必要なWALのみを保持します。

--status オプションが提供されている場合、 Barmanはバックアップのアーカイブステータスを報告します。これは、アーカイブバックアップの場合はfull またはstandalone 、アーカイブとしてフラグが付けられていないバックアップの場合はnokeep のリカバリターゲットになります。

--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 に変更するのは安全ですが、ターゲットを standalone から`full` に変更することは安全ではないことを意味します。利用できます。

リストファイル

次のコマンドを使用して、特定のバックアップのファイル（ベースバックアップと必要な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 コマンドは、 backup コマンドを使用してバックアップを実行した後、サーバー全体を回復するために使用されます。

これは、次のようなコマンドを発行して実現されます。

barman@backup$ barman recover <server_name> <backup_id> /path/to/recover/dir

重要

PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合は、リカバリーを発行する前に停止することを忘れないでください。これは、テーブルスペースディレクトリにも適用されます。

リカバリの実行の最後に、選択したバックアップはローカルにリカバリされ、宛先パスにはPostgreSQLインスタンスの起動に使用する準備ができたデータディレクトリが含まれています。

重要

ユーザー`barman` としてこのコマンドを実行すると、データベースのスーパーユーザーになります。

リストバックアップ を使用して、バックアップの特定のIDを取得できます

コマンド。

重要

Barmanは現在、PGDATA内のシンボリックリンクを追跡していません（pg_tblspc内のテーブルスペースを除く）。システム管理者は、シンボリックリンクを追跡し、元の場所に復元する必要がある場合に備えて、ディザスターリカバリー計画/手順に追加することをお勧めします。

recoveryコマンドには、コマンドの動作を変更するいくつかのオプションがあります。

リモートリカバリ

リカバリコマンドの呼び出しに--remote-ssh-command <COMMAND> オプションを追加します。これにより、 Barmanは、提供されたコマンドを使用してリモートホストに接続し、リモートサーバーでコピーを実行できます。

注釈

postgres ユーザーを使用して、リモートホストでリカバリを実行することをお勧めします。

重要

PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合は、リカバリーを発行する前に停止することを忘れないでください。これは、テーブルスペースディレクトリにも適用されます。

リモートリカバリの既知の制限は次のとおりです。

  • Barmanは、 Barman構成のrecovery_option パラメーターで 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 コマンドは、オプションでPostgreSQLを構成して、リカバリ中にBarmanからWALをフェッチできます。これは、

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を使用してローカルまたはリモートサーバー上のステージングディレクトリにコピーされます。

2.圧縮ファイルがターゲットディレクトリに解凍されます。

  1. Barmanによる特別な処理が必要な構成ファイルは、回復先からコピーされ、必要に応じて分析または編集され、Rsyncを使用して回復先にコピーされます。

  2. バックアップのステージングディレクトリが削除されます。

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のショートカット を受け入れます。