バックアップコマンド#
バックアップコマンドは、Barmanのバックアップカタログに既に存在するバックアップに直接動作するコマンドです。
注釈
バックアップIDは`barman list-backups <server_name>` で取得できることを覚えてください
バックアップ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
を介して適切に動作していることを確認することが重要です。特にスタンバイサーバーからバックアップする場合。
削除#
次の方法で特定のバックアップを削除できます。
barman delete <server_name> <backup_id>
delete コマンドは、
バックアップIDのショートカット を受け入れてバックアップを識別します。
重要
指定されたバックアップに依存するブロックレベルのインクリメンタルバックアップがある場合、チェーン内に親が見つからない場合のリカバリーに事実上使用できなくなるため、これらのバックアップとそのすべての依存関係もこの操作中に削除されます。
keep#
サーバーのリテンションポリシーを超えて保持したいバックアップがある場合は、次の方法でアーカイブバックアップを作成できます。
barman keep <server_name> <backup_id> [--target TARGET, --status, --release]
注釈
バックアップシステムの完全性を保証するため、ブロックレベルのインクリメンタルバックアップはBarmanのkeepアノテーションを使用できません。この制限は、ブロックレベルのインクリメンタルバックアップが互いに依存する方法によるものです。このようなバックアップでkeepアノテーションを使用すると、孤立したバックアップが発生する可能性があります。これは、特定のバックアップが必要な親バックアップなしで存在する可能性があることを意味します。 > 簡単に言えば、ブロックレベルのインクリメンタルバックアップにkeepアノテーションを適用できる場合、バックアップチェーンの一部が必要な先行者なしで保持されるリスクがあります。この状況では、適切に復元するために必要な重要な親バックアップが欠落しているため、役に立たない、または完全でないバックアップが作成される可能性があります。
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ファイルをリストしますfulldata+walと同じ
TARGET_TYPE のデフォルト値はstandalone です。
重要
list-files コマンドは外部ツールとの相互作用を促進するため、 Barmanをアーカイブプロシージャに統合するのに非常に役立ちます。
recovery#
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-ssh-command <COMMAND>
オプションをrecoveryコマンドの呼び出しに追加します。これにより、
Barmanは提供されたコマンドを使用してリモートホストに接続し、リモートサーバーでコピーを実行できます。
注釈
postgres ユーザーを使用して、リモートホストでリカバリーを実行することをお勧めします。
重要
PostgreSQLインスタンスが実行されているターゲットデータディレクトリを使用して`recover` コマンドを発行しないでください。その場合、リカバリを発行する前に忘れずに停止してください。これは、テーブルスペースディレクトリにも適用されます。
リモートリカバリの既知の制限は次のとおりです。
Barmanは、 Barman構成の
recovery_optionパラメーターで get-wal コマンドが指定されていない限り、システム一時ディレクトリに少なくとも4GBの空き領域を必要とします。Barmanとリモートホスト間のSSH接続は、公開鍵交換認証方法を使用する必要があります**
リモートユーザー**は、宛先ディレクトリにバックアップのディレクトリ構造を作成できる必要があります。
リモートサーバーには、ベースバックアップと復旧に必要なWALファイルを含めるための十分な空き領域が必要です。
テーブルスペースのリマッピング#
Barmanは、
–tablespaceオプションを指定してrecoverコマンドを使用して、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_NAMEpg_create_restore_point(name)ファンクションで以前に作成した名前付けリストアポイントを指定します--target-immediate一貫した状態に到達すると、リカバリは終了しますつまり、ベースバックアッププロセスの終了
重要
time、XID、およびLSNを介したリカバリターゲットは、バックアップの終了後である必要があります**。バックアップの開始と終了の間のポイントにリカバリする場合は、カタログ内の以前のバックアップからリカバリする必要があります。
重要
--target-time の使用時にタイムゾーンが指定されない場合、 Barmanホストのタイムゾーンが使用されます。
--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][target]を参照してください。
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 。
重要
リカバリー中に`--standby-mode` を使用する場合、ユーザーは復旧したインスタンスの構成を変更する必要があり、 BarmanからのWALファイルのレプリケーションが正常に完了すると、復旧したサーバーはプライマリに接続できます。リカバリされたインスタンスバージョンが11以下の場合、これは`primary_conninfo` パラメーターを`recovery.conf` ファイルに追加することにより実現されます。リカバリされたインスタンスバージョンが12以上の場合、 primary_conninfo パラメーターを`postgresql.conf` ファイルに追加する必要があります。
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
を使用して無効にします。
重要
これらのターゲット[--target-xid 、--target-name 、--target-time ]のいずれかと組み合わせて`--no-get-wal` を使用してリカバリーする場合、 BarmanはWALアーカイブ全体をBarmanホストからリカバリホストにコピーします。これにより、構成されたターゲットに到達するために必要なすべてのWALが既にBarmanにアーカイブされていると仮定すると、少なくともこれらのWALがPostgresで利用できることを保証します。これは、現在Barmanで、これらの種類の復旧ターゲットを達成するためにPostgresが必要なWALを決定する信頼性の高いおよび/またはパフォーマンスの方法がないために発生します。
圧縮バックアップのリカバリー#
backup_compression
オプションを使用してバックアップが圧縮されている場合、
barman recover
は、リカバリー時にバックアップを解凍できます。これはマルチステップのプロセスです。
圧縮されたバックアップファイルは、Rsyncを使用してローカルまたはリモートサーバーのステージングディレクトリにコピーされます。
圧縮ファイルはターゲットディレクトリに解凍されます。
Barmanによる特別な処理を必要とする構成ファイルは、復旧先からコピーされ、必要に応じて分析または編集され、Rsyncを使用して復旧先にコピーされます。
バックアップのステージングディレクトリが削除されます。
barmanは、展開される環境について何も知らないため、
recovery_staging_path
オプションに依存して、ステージングディレクトリの適切な場所を選択します。
backup_compression
オプションを使用している場合、グローバル/サーバー構成でrecovery_staging_path
を設定するか、 barman recover
コマンドで--recovery-staging-path
オプションを使用する必要があります。これらのいずれも行わず、圧縮バックアップを復元しようとすると、
Barmanは適切な場所を推測するのではなく、失敗します。
ブロックレベルのインクリメンタル バックアップのリカバリー#
バックアップがブロックレベルのインクリメンタルの場合、
barman recover は、 pg_combinebackup
を介したリカバリーにバックアップのチェーンを結合できます。バックアップのチェーンは、完全なバックアップからリカバリのために要求されたものに進むツリーブランチです。これはマルチステップのプロセスです。
バックアップのチェーンは、新しい合成バックアップに結合されます。リカバリするインクリメンタルバックアップのIDを使用した名前付けのフォルダーが、
pg_combinebackupを使用してローカルサーバーの特定のステージングディレクトリ内に作成されます。あらゆる種類のリカバリーローカルまたはリモートの場合、合成バックアップはbarmanサーバーにローカルに作成されます。リモートリカバリーの場合、コンテンツはRsyncを使用して最終的な宛先にコピーされます。それ以外の場合、ローカルリカバリの場合、コンテンツは最終的な場所に移動されるだけです。
提供されたステージングディレクトリ内に作成され、復旧するインクリメンタルバックアップのIDで名前付けられたフォルダーは、復旧プロセスの最後に削除されます。
ブロックレベルのインクリメンタルバックアップからリカバリーする場合、したがって、グローバル/サーバー構成でlocal_staging_path
を設定するか、 barman recover コマンドで--local-staging-path
オプションを使用する必要があります。これらのことのいずれも行わず、このようなバックアップを回復しようとすると、
Barmanは適切な場所を推測するのではなく、失敗します。
重要
チェーン内のバックアップのいずれかがチェックサムを無効にして取得されたが、最終的なバックアップがチェックサムを有効にして取得された場合、結果のディレクトリには無効なチェックサムを含むページが含まれる場合があります。 Follow up the `limitations section in pg_basebackup documentation <https://www.postgresql.org/docs/17/app-pgcombinebackup.html>`_ 。
show-backup#
次の使用を使用して、特定のサーバーの特定のバックアップで使用可能な情報をすべて取得できます。
barman show-backup <server_name> <backup_id>
show-backup コマンドは、
バックアップIDのショートカット を受け入れてバックアップを識別します。