Backup commands#

バックアップコマンドは、Barmanのバックアップカタログに既に存在するバックアップに直接動作するコマンドです。

注釈

バックアップIDは`barman list-backups <server_name>` で取得できることを覚えてください

Backup ID shortcuts#

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 コマンドは、 Backup ID shortcuts を受け入れてバックアップを識別します。

keep#

サーバーのリテンションポリシーを超えて保持したいバックアップがある場合は、次の方法でアーカイブバックアップを作成できます。

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` に変更するのは安全ですが、最新のポイントへのリカバリに必要なWALがまだ残っているという保証がないため、ターゲットを`standalone` から`full` に変更するのは安全ではないことを意味します利用できます。

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は、 list-backups を使用して取得できます。

コマンド。

重要

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

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

Remote recovery#

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

注釈

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

重要

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

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

  • Barman構成のrecovery_option パラメーターで get-wal コマンドが指定されていない限り、 Barmanはシステム一時ディレクトリに少なくとも4GBの空き領域を必要とします。

Barmanとリモートホスト間のSSH接続は、公開キー交換認証方法を使用する必要があります

*リモートユーザー** は、宛先ディレクトリにバックアップのディレクトリ構造を作成できる必要があります。

  • リモートサーバーには、ベースバックアップと復旧に必要なWALファイルを含めるための十分な空き領域が必要です。

Tablespace remapping#

Barmanは、 –tablespaceオプションを指定してrecoverコマンドを使用して、1つ以上のテーブルスペースを自動的に再マップできます。このオプションは、NAME:DIRECTORY フォーマットを使用して引数として値のペアを受け入れます。

※ NAME はテーブルスペースの識別子です

  • DIRECTORY は、テーブルスペースの新しい宛先パスです

宛先ディレクトリが存在しない場合、 Barmanはそれを作成しようとします必要な権限を持っていることを前提としています。

Point in time recovery#

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 一貫した状態に到達すると、リカバリは終了しますつまり、ベースバックアッププロセスの終了

重要

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はリカバリを終了し、マスターとして昇格します

重要

デフォルトでは、ターゲットアクションは定義されていません後方互換性のため。 --target-action オプションでは、ポイントインタイムリカバリーターゲットを指定する必要があります。

上記の設定の詳細については、 PostgreSQL documentation on recovery target settings を参照してください。

Barman 2.4は、 recover コマンドの--standby-mode オプションを追加します。これを指定すると、standby.signal ファイル12より前のPostgreSQLバージョンから、または生成されたリカバリ構成にstandby_mode = on を追加することにより、リカバリされたインスタンスをスタンバイとして適切に構成します。

Postgresql スタンバイモード の詳細については、公式ドキュメントで入手できます。

重要

リカバリー中に`--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を構成できます。これは、 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 を使用して無効にします。

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#

次の使用を使用して、特定のサーバーの特定のバックアップで使用可能な情報をすべて取得できます。

barman show-backup <server_name> <backup_id>

show-backup コマンドは、 Backup ID shortcuts を受け入れてバックアップを識別します。