Backup commands =============== バックアップコマンドは、Barmanのバックアップカタログに既に存在するバックアップに直接動作するコマンドです。 .. NOTE:: バックアップIDは`barman list-backups ` で取得できることを覚えてください Backup ID shortcuts ------------------- Barmanでは、特別なキーワードを使用して特定のバックアップを識別できます。 - ``last/latest`` カタログ内の最新のバックアップを識別します - ``first/oldest`` カタログ内の最も古いバックアップを識別します - ``last-failed`` カタログ内の最新の失敗したバックアップを識別します Barmanコマンドでこれらのキーワードを使用すると、サーバーのバックアップの正確なIDを知らなくてもアクションを実行できます。例、次のことを発行できます。 .. code:: bash barman delete oldest カタログで使用可能な最も古いバックアップを削除し、ディスク領域を再利用します。 さらに、バックアップが\ ``--name `` オプションで取得された場合、バックアップIDの代わりにフレンドリ名を使用して、その特定のバックアップを参照できます。 check-backup ------------ バージョン2.5以降、フルバックアップの一貫性のために必要なすべてのWALファイルが、 ``check-backup`` コマンドを使用して\ ``barman`` によって正しくアーカイブされたことを確認できます。 .. code:: bash barman check-backup .. IMPORTANT:: このコマンドは、`cron` によって、および`backup` オペレーションの最後に自動的に呼び出されます。これは、通常の状況では、実行する必要がないことを意味します。 バックアップの開始から終了までの1つ以上のWALファイルがまだアーカイブされていない場合、 ``barman`` はバックアップに\ ``WAITING_FOR_WALS`` のラベルを付けます。 ``cron`` コマンドは、不足しているWALファイルがアーカイブされていることを継続して確認し、バックアップに\ ``DONE`` としてラベル付けします。 バックアップの最後に最初に必要なWALファイルが欠落している場合、このようなバックアップは\ ``FAILED`` としてマークされます。したがって、バックアップ操作を実行する前に、WALアーカイブストリーミングまたは\ ``archive_command`` を介して適切に動作していることを確認することが重要です。特にスタンバイサーバーからバックアップする場合。 delete ------ 次の方法で特定のバックアップを削除できます。 .. code:: bash barman delete ``delete`` コマンドは、 :ref:`Backup ID shortcuts ` を受け入れてバックアップを識別します。 keep ---- サーバーのリテンションポリシーを超えて保持したいバックアップがある場合は、次の方法でアーカイブバックアップを作成できます。 .. code:: bash barman keep [--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 --release`` でkeepフラグを削除することにより元に戻すことができます。 .. WARNING :: サーバーのリテンションポリシーで`standalone` アーカイブバックアップが必要とされなくなると、 `barman cron` は、そのバックアップと次の最新のバックアップのbegin_wal値間のWALを削除します。これは、ターゲットを`full` から`standalone` に変更するのは安全ですが、最新のポイントへのリカバリに必要なWALがまだ残っているという保証がないため、ターゲットを`standalone` から`full` に変更するのは安全ではないことを意味します利用できます。 list-files ---------- 次の使用で、特定のバックアップのファイルベースバックアップと必要なWALファイルをリストできます。 .. code:: bash barman list-files [--target TARGET_TYPE] ``--target TARGET_TYPE`` オプションを使用すると、特定のバックアップのリストの内容を選択できます。 ``TARGET_TYPE`` の可能な値は次のとおりです。 - ``data`` データファイルをリストします - ``standalone`` 必要なWALファイルを含むベースバックアップファイルをリストします - ``wal`` ベースバックアップの先頭から次のバックアップの先頭またはログの最後までのすべてのWALファイルをリストします - ``full`` ``data`` + ``wal`` と同じ ``TARGET_TYPE`` のデフォルト値は\ ``standalone`` です。 .. IMPORTANT:: `list-files` コマンドは外部ツールとの相互作用を促進するため、 Barmanをアーカイブプロシージャに統合するのに非常に役立ちます。 recover ------- ``recover`` コマンドは、 ``backup`` コマンドを使用してバックアップが実行された後、サーバー全体をリカバリするために使用されます。 これは、次のようなコマンドを発行して実現されます。 .. code:: bash barman@backup$ barman recover /path/to/recover/dir .. IMPORTANT:: PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合、リカバリを発行する前に忘れずに停止してください。これは、テーブルスペースディレクトリにも適用されます。 リカバリの実行の最後に、選択したバックアップはローカルにリカバリされ、宛先パスにはPostgreSQLインスタンスを起動するために使用する準備ができたデータディレクトリが含まれています。 .. IMPORTANT:: ユーザー`barman` としてこのコマンドを実行すると、データベースのスーパーユーザーになります。 バックアップの特定のIDは、 :ref:`list-backups ` を使用して取得できます。 コマンド。 .. IMPORTANT:: Barmanは、現在PGDATA内のシンボリックリンクを追跡していませんpg_tblspc内のテーブルスペースを除きます。システム管理者は、シンボリックリンクを追跡し、元の場所に復元する必要がある場合に、ディザスターリカバリー計画/手順に追加することをお勧めします。 recoveryコマンドには、コマンドの動作を変更するいくつかのオプションがあります。 Remote recovery ^^^^^^^^^^^^^^^ ``--remote-ssh-command `` オプションをrecoveryコマンドの呼び出しに追加します。これにより、 Barmanは提供されたコマンドを使用してリモートホストに接続し、リモートサーバーでコピーを実行できます。 .. NOTE:: `postgres` ユーザーを使用して、リモートホストでリカバリーを実行することをお勧めします。 .. IMPORTANT:: PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合、リカバリを発行する前に忘れずに停止してください。これは、テーブルスペースディレクトリにも適用されます。 リモートリカバリの既知の制限は次のとおりです。 - Barmanは、 Barman構成の\ ``recovery_option`` パラメーターで :ref:`get-wal ` コマンドが指定されていない限り、システム一時ディレクトリに少なくとも4GBの空き領域を必要とします。 - Barmanとリモートホスト間のSSH接続は、公開鍵交換認証方法を使用する必要があります*\* - リモートユーザー**は、宛先ディレクトリにバックアップのディレクトリ構造を作成できる必要があります。 - リモートサーバーには、ベースバックアップと復旧に必要なWALファイルを含めるための十分な空き領域が必要です。 Tablespace remapping ^^^^^^^^^^^^^^^^^^^^ Barmanは、 –tablespaceオプションを指定してrecoverコマンドを使用して、1つ以上のテーブルスペースを自動的に再マップできます。このオプションは、\ ``NAME:DIRECTORY`` フォーマットを使用して引数として値のペアを受け入れます。 - ``NAME`` は、テーブルスペースの識別子です - ``DIRECTORY`` は、テーブルスペースの新しい宛先パスです 宛先ディレクトリが存在しない場合、 Barmanはそれを作成しようとします必要な権限を持っていることを前提としています。 Point in time recovery ^^^^^^^^^^^^^^^^^^^^^^ Barmanは、PostgreSQLのポイントインタイムリカバリーPITRをラップし、タイムスタンプ、復元ラベル、またはトランザクションIDとして、リカバリターゲットを指定できます。 .. IMPORTANT:: 特定のバックアップの最も古い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`` 一貫した状態に到達すると、リカバリは終了しますつまり、ベースバックアッププロセスの終了 .. IMPORTANT:: *time*、*XID*、およびLSNを介したリカバリターゲットは、バックアップの終了後である必要があります**。バックアップの開始と終了の間のポイントにリカバリする場合は、カタログ内の以前のバックアップからリカバリする必要があります。 ``--exclusive`` オプションを使用して、リカバリターゲットの直前に停止するか、直後に停止するかを指定できます。 Barmanでは、 ``--target-tli`` オプションを使用して、リカバリのターゲットタイムラインを指定できます。これは、数値のタイムラインIDまたは特別な値\ ``latest`` WALアーカイブの最新のタイムラインにリカバリーするためおよび\ ``current`` バックアップが取られたときに現在のタイムラインにリカバリーするのいずれかに設定できます。このオプションを省略すると、PostgreSQLバージョン12以降は\ ``latest`` タイムラインにリカバリーし、PostgreSQLバージョン12より前のバージョンは\ ``current`` タイムラインにリカバリーします。 *「始める前に」* セクションで説明しているように、PostgreSQLドキュメントでタイムラインの詳細を見つけることができます。 Barman 2.4では、 ``--target-action`` オプションのサポートを導入し、次の値を受け入れます。 - ``shutdown`` 復旧目標に到達すると、PostgreSQLがシャットダウンされます - ``pause`` 復旧目標に到達すると、PostgreSQLが一時停止状態で起動され、ユーザーはインスタンスを検査できます - ``promote`` 復旧目標に到達すると、PostgreSQLはリカバリを終了し、マスターとして昇格します .. IMPORTANT:: デフォルトでは、ターゲットアクションは定義されていません後方互換性のため。 `--target-action` オプションでは、ポイントインタイムリカバリーターゲットを指定する必要があります。 上記の設定の詳細については、 `PostgreSQL documentation on recovery target settings `_ を参照してください。 Barman 2.4は、 ``recover`` コマンドの\ ``--standby-mode`` オプションを追加します。これを指定すると、\ ``standby.signal`` ファイル12より前のPostgreSQLバージョンから、または生成されたリカバリ構成に\ ``standby_mode = on`` を追加することにより、リカバリされたインスタンスをスタンバイとして適切に構成します。 Postgresql *スタンバイモード* の詳細については、公式ドキュメントで入手できます。 - Postgres 11以前のバージョンの場合 `in the standby section of PostgreSQL documentation `_ 。 - PostgreSQL 12以降のバージョン `in the replication section of PostgreSQL documentation `_ 。 .. IMPORTANT:: リカバリー中に`--standby-mode` を使用する場合、ユーザーは復旧したインスタンスの構成を変更する必要があり、 BarmanからのWALファイルのレプリケーションが正常に完了すると、復旧したサーバーはプライマリに接続できます。リカバリされたインスタンスバージョンが11以下の場合、これは`primary_conninfo` パラメーターを`recovery.conf` ファイルに追加することにより実現されます。リカバリされたインスタンスバージョンが12以上の場合、 `primary_conninfo` パラメーターを`postgresql.conf` ファイルに追加する必要があります。 Fetching WALs from the Barman server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``barman recover`` コマンドは、オプションで、リカバリ中にBarmanからWALを取得するようにPostgreSQLを構成できます。これは、 :ref:`get-wal section <#get-wal>` で説明しているように、 ``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`` を使用して無効にします。 Recovering compressed backups ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``backup_compression`` オプションを使用してバックアップが圧縮されている場合、 ``barman recover`` は、リカバリー時にバックアップを解凍できます。これはマルチステップのプロセスです。 1. 圧縮されたバックアップファイルは、Rsyncを使用してローカルまたはリモートサーバーのステージングディレクトリにコピーされます。 2. 圧縮ファイルはターゲットディレクトリに解凍されます。 3. Barmanによる特別な処理を必要とする構成ファイルは、復旧先からコピーされ、必要に応じて分析または編集され、Rsyncを使用して復旧先にコピーされます。 4. バックアップのステージングディレクトリが削除されます。 barmanは、展開される環境について何も知らないため、 ``recovery_staging_path`` オプションに依存して、ステージングディレクトリの適切な場所を選択します。 ``backup_compression`` オプションを使用している場合、グローバル/サーバー構成で\ ``recovery_staging_path`` を設定するか、 ``barman recover`` コマンドで\ ``--recovery-staging-path`` オプションを使用する必要があります。これらのいずれも行わず、圧縮バックアップを復元しようとすると、 Barmanは適切な場所を推測するのではなく、失敗します。 show-backup ----------- 次の使用を使用して、特定のサーバーの特定のバックアップで使用可能な情報をすべて取得できます。 .. code:: bash barman show-backup ``show-backup`` コマンドは、 :ref:`Backup ID shortcuts ` を受け入れてバックアップを識別します。