Features in detail¶

このセクションでは、いくつかのBarman機能を紹介し、その適用性と使用に必要な構成について説明します。

Barman構成で作業して多くのシナリオを作成できるため、このリストは完全ではありません。それでも、一般的なパターンについて説明することは役立ちます。

バックアップ機能¶

インクリメンタルバックアップ¶

Barmanは ファイルレベルのインクリメンタルバックアップ を実装しています。増分バックアップは、特定のPostgreSQLサーバーのカタログで利用可能な最新の完全バックアップからのデータ変更のみを保存する完全な定期バックアップです。 WAL継続的アーカイブによって実装される差分バックアップと混同しないでください。

注釈

ブロックレベルの増分バックアップは将来のバージョンで利用できるようになります。

重要

現時点では、 reuse_backup オプションは`postgres` バックアップ方法では使用できません。

Barmanの増分バックアップの主な目標は次のとおりです。

フルバックアッププロセスにかかる時間を短縮します
複数の定期的なバックアップが占めるディスク領域を削減する（ データ重複排除 ）

この機能は rsync と hard links に大きく依存しているため、基になるオペレーティングシステムとバックアップデータが存在するファイルシステムの両方でサポートされている必要があります。

主な概念は、後続のベースバックアップで前回のバックアップ以降に変更されていないファイルを共有し、関連するディスク使用量を節約することです。これは、VLDBコンテキストと、読み取り専用の履歴テーブルを高い割合で含むデータベースに特に当てはまります。

Barmanは、 barman backup コマンドを透過的に管理するreuse_backup と呼ばれるグローバル/サーバーオプションを介して増分バックアップを実装します。これは3つの値を受け入れます。

off ：標準の完全バックアップ（デフォルト）
link ：サーバーの最後のバックアップを再利用し、変更のないファイルのハードリンクを作成することによる増分バックアップ（バックアップスペースと時間の削減）
copy ：サーバーの最後のバックアップを再利用し、変更のないファイルのコピーを作成することによる増分バックアップ（バックアップ時間の短縮のみ）

最も一般的なシナリオは、次のようにreuse_backup をlink に設定することです。

reuse_backup = link

これをグローバルレベルで設定すると、すべてのサーバーの増分バックアップが自動的に有効になります。

最後に、ユーザーは barman backup コマンドの--reuse-backup ランタイムオプションを介してreuse_backup オプションの設定をオーバーライドできます。同様に、実行時オプションは3つの値を受け入れます：off 、link 、およびcopy 。たとえば、次のように1回限りの増分バックアップを実行できます。

barman backup --reuse-backup=link <server_name>

帯域幅の使用を制限する¶

bandwidth_limit オプション（global/per server）を使用して、1秒あたりの最大キロバイト数を指定することにより、I / O帯域幅の使用を制限できます。デフォルトでは0、つまり無制限に設定されています。

重要

bandwidth_limit オプションは`postgres` バックアップ方法でサポートされていますが、tablespace_bandwidth_limit オプションは`rsync` を使用する場合にのみ使用できます。

複数のテーブルスペースがあり、1つ以上のテーブルスペースでバックアップ手順のI/Oワークロードを制限したい場合は、 tablespace_bandwidth_limit オプション（global/per server）を使用できます。

tablespace_bandwidth_limit = tbname:bwlimit[, tbname:bwlimit, ...]

このオプションは、テーブルスペース名と帯域幅制限（キロバイト/秒）で構成されるペアのコンマ区切りリストを受け入れます。

サーバーをバックアップするとき、 Barmanは上記のオプションで既存のテーブルスペースを見つけようとします。見つかった場合、指定された帯域幅制限が適用されます。そうでない場合、そのサーバーのデフォルトの帯域幅制限が適用されます。

ネットワーク圧縮¶

圧縮を使用して、転送されるデータのサイズを減らすことができます。 network_compression オプション（global/per server）を使用して有効にできます。

重要

network_compression オプションは、 postgres バックアップ方法では使用できません。

network_compression = true|false

このオプションを true に設定すると、ネットワーク転送中のデータ圧縮が有効になります（バックアップとリカバリの両方）。デフォルトではfalse に設定されています。

バックアップ圧縮¶

Barmanは、バックアッププロセス中にバックアップデータを圧縮するためにpg_basebackupの圧縮機能を使用できます。これは、 backup_compression 構成オプション（global/per server）を使用して有効にできます。

重要

backup_compression およびこのセクションで説明するその他のオプションは、 rsync または`local-rsync` バックアップ方法では使用できません。 postgres バックアップ方法のみ。

圧縮アルゴリズム¶

このオプションを設定すると、pg_basebackupは指定された圧縮アルゴリズムを使用してバックアップを圧縮します。現在、 Barmanでサポートされているアルゴリズムは次のとおりです。gzip lz4 およびzstd 。

backup_compression = gzip|lz4|zstd

Barmanでは、選択した圧縮アルゴリズムのCLIユーティリティがBarmanサーバーとの両方で使用できる必要があります。 CLIユーティリティを使用して、圧縮されたバックアップからバックアップラベルを抽出し、リカバリ中にPostgreSQLサーバーでバックアップを解凍します。これらは、Debian、Ubuntu、RedHat、CentOS、およびSLESシステムにgzip 、lz4 、およびzstd という名前のシステムパッケージをインストールできます。

注釈

Ubuntu 18.04（bionic）では、 liblz4-tool パッケージで`lz4` ユーティリティを使用できます。

注釈

zstd バージョンは1.4.4以上である必要があります。 Debian 10（buster）、Ubuntu 18.04（bionic）およびSLES 12の`zstd` のシステムパッケージは以前のバージョンをインストールします - backup_compression = zstd はこれらのパッケージでは動作しません。

注釈

lz4 および`zstd` は、PostgreSQLバージョン15以降でのみ使用できます。

重要

backup_compression を使用している場合は、recovery_staging_path も設定して、barman recover が圧縮されたバックアップを回復できるようにする必要があります。圧縮されたバックアップの回復を参照

詳細については、セクションをご覧ください。

コンプレッションワーカー¶

このオプションのパラメーターを使用すると、マルチプルのスレッドを使用して圧縮を行うと、圧縮速度が向上します（デフォルトは0）。

backup_compression_workers = 2

注釈

このオプションは、 zstd 圧縮でのみ使用できます。

圧縮レベル¶

圧縮レベルは backup_compression_level オプションを使用して指定できます。これは、 backup_compression で指定された圧縮アルゴリズムでサポートされている整数値に設定する必要があります。

圧縮場所¶

PostgreSQLバージョン15以降でBarmanを使用する場合、サーバー（PostgreSQLはバックアップを圧縮）またはクライアント（pg_basebackupはバックアップを圧縮）で圧縮を指定できます。これは、 backup_compression_location オプションを使用して実現できます。

重要

backup_compression_location オプションは、PostgreSQL 15以降で実行している場合にのみ使用できます。

backup_compression_location = server|client

backup_compression_location = server を使用すると、圧縮作業をPostgreSQLサーバーに移動することを犠牲にして、バックアップに必要なネットワーク帯域幅を削減できます。

backup_compression_location がserver に設定されている場合、追加のオプションbackup_compression_format をplain に設定して、ディスクに書き込む前にpg_basebackupにデータを解凍させることができます。

圧縮形式¶

backup_compression_format = plain|tar

backup_compression_format が設定されていないか、値がtar の場合、バックアップは圧縮されたtarballとしてディスクに書き込まれます。 plain とtar の両方のフォーマットの説明は、[pg_basebackup documentation][pg_basebackup-documentation]にあります。 !!!重要

Barmanは外部ツールを使用して圧縮バックアップを管理します。 backup_compression およびbackup_compression_format に応じて PostgresサーバーとBarmanサーバーに1つ以上のツールをインストールする必要がある場合があります。次の表は、構成に応じて選択するのに役立ちます。

backup_compression	backup_compression_format	Postgres server	Barman server
gzip	plain	tar	None
gzip	tar	tar	tar
lz4	plain	tar, lz4	None
lz4	tar	tar, lz4	tar, lz4
zstd	plain	tar, zstd	None
zstd	tar	tar, zstd	tar, zstd

同時バックアップ¶

通常、バックアップ操作中、 Barmanは_concurrent backup_にPostgreSQLネイティブ関数pg_start_backup およびpg_stop_backup を使用します。 [ABOUT_CONCURRENT_BACKUP] これは、PostgreSQL 9.6以降で推奨されるバックアップ方法です（ただし、PostgreSQL 15ベータでは関数の名前が pg_backup_start および pg_backup_stop に変更されました）。

[ABOUT_CONCURRENT_BACKUP] 同時バックアップは、_ストリーミングレプリケーションプロトコル_を使用するテクノロジーです（たとえば、 pg_basebackup などのツールを使用します）。

推奨されるバックアップアプローチであるだけでなく、同時バックアップでは、 Barmanを使用した次のアーキテクチャシナリオも使用できます。rsync を使用した**スタンバイサーバーからのバックアップ。

デフォルトでは、 backup_options はconcurrent_backup に設定されます。バージョン15より古いPostgreSQLサーバーで排他的バックアップが必要な場合、ユーザーはbackup_options をexclusive_backup に設定する必要があります。

backup_options がconcurrent_backup に設定されている場合、 Barmanはサーバーの同時バックアップモードをアクティブにし、次の2つの単純なルールに従います。

ssh_command は宛先Postgresサーバーを指す必要があります
conninfo は、宛先Postgresデータベース上のデータベースを指す必要があります。

重要

同時バックアップの場合、現在Barmanは完全バックアップの終了WALファイルが実際に出荷されたかどうかを判断できません-PostgreSQL自分自身がWALファイルが正しくアーカイブされていることを確認する排他的バックアップの反対。完全バックアップは、そのBarmanファイルを受信してアーカイブするまで一貫性があるとは見なされないことに注意してください。 Barman 2.5では、 WAITING_FOR_WALS と呼ばれる新しい状態が導入されています。これは、 check-backup コマンド（ cron コマンドで実行される通常のメンテナンスジョブの一部）によって管理されます。 Barman 2.10から、 barman backup コマンドで`--wait` オプションを使用できます。

スタンバイの同時バックアップ¶

スタンバイをバックアップする場合、次の configuration options はスタンバイサーバーを指す必要があります。

conninfo
streaming_conninfo （backup_method = postgres またはstreaming_archiver = on を使用する場合）
ssh_command （backup_method = rsync 使用時）

次の構成オプションは、プライマリサーバーを指す必要があります。

primary_conninfo

Barmanはprimary_conninfo を使用してプライマリで新しいWALに切り替え、WAL切り替えが自然に発生するのを待たずにスタンバイに対する同時バックアップを完了できるようにします。

!!!注

プライマリで書き込みトラフィックがほとんどまたはまったくないときにスタンバイをバックアップする場合は、 primary_conninfo を設定することが特に重要です。 primary_conninfo が設定されていない場合でも、バックアップは実行されますが、プライマリ上の現在のWALエージェントがバックアップに必要な最新のWALよりも新しくなるまで、バックアップの停止段階で待機します。

Barmanは現在、WALファイルとバックアップデータが同じPostgreSQLサーバーからのものであることを必要としています。スタンバイがプライマリに昇格した場合、バックアップとWALは引き続き有効ですが、バックアップの作成とWALの受信に新しいスタンバイを使用するようにBarman構成を更新できます。

WALは、WALストリーミングまたはWALアーカイブを使用してスタンバイから取得できます。 WALストリーミングを使用するには、

WALストリーミングセクションの指示に従ってください。

スタンバイからWALアーカイブを使用するには、: WAL archiving via archive_command セクションの指示に従って さらに

スタンバイサーバーのPostgreSQL構成でarchive_mode = always を設定します。

注釈

PostgreSQL 10以前では、 BarmanはスタンバイでWALストリーミングと有効になっているWALアーカイブを処理できません。したがって、WALストリーミングを使用する場合はWALアーカイブを無効にする必要があります。これは、PostgreSQL 10以前で生成されたWALは論理的には同等であるがバイナリレベルで異なる可能性があるため、 Barmanは2つのWALが同一であることを検出できないためです。

即時チェックポイント¶

バックアップを開始する前に、 Barmanはチェックポイントを要求します。これにより、追加のワークロードが生成されます。通常、そのチェックポイントはPostgreSQLサーバーのワークロード制御の設定に従って調整されるため、バックアップが遅延する可能性があります。

このデフォルトの動作は、 immediate_checkpoint 構成のグローバル/サーバーオプション（デフォルトでfalse に設定）を介して変更できます。

immediate_checkpoint がtrue に設定されている場合、PostgreSQLはワークロードを制限しようとせず、チェックポイントは最大速度で発生し、できるだけ早くバックアップを開始します。

次の2つのオプションのいずれかを使用してbarman backup を発行することにより、いつでも構成オプションの動作をオーバーライドできます。

--immediate-checkpoint 、即時チェックポイントを強制します。
--no-immediate-checkpoint 、チェックポイントが発生するのを強制的に待機します。

ローカルバックアップ¶

注釈

BarmanとPostgreSQLは同じサーバー上にあり、同じ単一障害点の一部であるため、この機能は実稼働での使用はお勧めしません。 EnterpriseDBの一部のお客様は、特定の状況で、最も重要なことに、会社が提供する24時間年中無休の運用サービスの下で使用するローカルバックアップのサポートを追加することをBarmanしています。現在、この機能を使用するには、ソースからインストールするか、権限、ロギングおよびcron構成の観点から`postgres` ユーザーの環境をカスタマイズする必要があります。

特別な状況では、 BarmanをPostgreSQLインスタンスが存在するのと同じサーバーにインストールし、バックアップデータをPGDATA、および必要に応じてテーブルスペースとは別のボリュームに保存できます。通常、これらのボリュームはNFSなどのファイルシステムを備えたネットワークストレージアプライアンスにあります。

このアーキテクチャはEnterpriseDBによって承認されていません。 RPOとRTOの点でより良い結果をもたらすPostgreSQLのビジネス継続性エクスペリエンスを強化するために、EnterpriseDBは、レプリケーションと監視の目的で監視ウィットネスサーバのように機能できるBarmanのリモートインストールを使用したシェアードナッシングアーキテクチャを引き続きお勧めします。

ローカルバックアップの唯一の要件は、 BarmanがPostgreSQLサーバーと同じユーザー（通常はpostgres ）で実行されることです。コミュニティパッケージはデフォルトでbarman ユーザーにBarmanをインストールするため、このユースケースでは次を含む手動インストール手順が必要です。

cron構成
logrotateを含むログ構成

Barmanで特定のサーバーのローカルバックアップを使用するには、 backup_method を local-rsync に設定する必要があります。この機能は、代わりにSSHに依存してリモートで動作するrsync 同等の機能と本質的に同じです。 local-rsync では、ローカルでrsync コマンドを発行してファイルシステムのコピーが実行されます（このため、 BarmanはPostgreSQLと同じユーザーで実行する必要があります）。

local-pg13 という名前のサーバーのローカルバックアップの構成の抜粋は次のとおりです。

[local-pg13]
description = "Local PostgreSQL 13"
backup_method = local-rsync
...

アーカイブ機能 ### WAL圧縮¶

barman cron コマンドは、構成ファイルでcompression オプションが設定されている場合、WALファイルを圧縮します。このオプションでは 5 つの値を使用できます。

bzip2 ：Bzip2圧縮の場合（bzip2 ユーティリティが必要）
gzip ：Gzip圧縮用（gzip ユーティリティが必要）
pybzip2 ： Bzip2圧縮の場合（Pythonの内部圧縮モジュールを使用）
pygzip ：Gzip圧縮の場合（Pythonの内部圧縮モジュールを使用）
pigz ：Pigz圧縮用（pigz ユーティリティが必要）
custom ：カスタム圧縮の場合、次のオプションも設定する必要があります。 - custom_compression_filter ：圧縮フィルタ - custom_decompression_filter ：解凍フィルタ - custom_compression_magic ：カスタム圧縮walファイルを識別するための16進文字列
注:* pybzip2 およびpygzip を除くすべてのメソッドでは、新しいプロセスをフォークするためにbarman archive-wal が必要です。

同期WALストリーミング¶

Barmanは、同期スタンバイサーバーのようにトランザクションWALファイルを収集することにより、目標復旧ポイントをゼロに減らすこともできます。

このようなシナリオを構成するには、 PostgreSQLストリーミング接続を介してWALをアーカイブするようにBarmanサーバーを構成する必要があり、 receive-wal プロセスはPostgreSQLサーバーの同期スタンバイとして認識される必要があります。

まず、 show-servers コマンドでBarman receive-wal プロセスのアプリケーション名を取得する必要があります。

barman@backup$ barman show-servers pg|grep streaming_archiver_name
    streaming_archiver_name: barman_receive_wal

次に、アプリケーション名を同期スタンバイとしてpostgresql.conf ファイルに追加する必要があります。

synchronous_standby_names = barman_receive_wal

重要

これは構成の一例に過ぎませんBarmanが同期スタンバイノードとして使用できることを示します。 Barmanのみを使用することは推奨していません。このトピックの詳細については、PostgreSQLのドキュメントから Synchronous Replication をお読みください。

構成をリロードするには、PostgreSQLサーバーを再起動する必要があります。

サーバーが正しく構成されている場合、 replication-status コマンドはreceive_wal プロセスを同期ストリーミングクライアントとして表示します。

[root@backup ~]# barman replication-status pg
Status of streaming clients for server pg:
  Current xlog location on master: 0/9000098
  Number of streaming clients: 1

  1. #1 Sync WAL streamer
     Application name: barman_receive_wal
     Sync stage      : 3/3 Remote write
     Communication   : TCP/IP
     IP Address      : 139.59.135.32 / Port: 58262 / Host: -
     User name       : streaming_barman
     Current state   : streaming (sync)
     Replication slot: barman
     WAL sender PID  : 2501
     Started at      : 2016-09-16 10:33:01.725883+00:00
     Sent location   : 0/9000098 (diff: 0 B)
     Write location  : 0/9000098 (diff: 0 B)
     Flush location  : 0/9000098 (diff: 0 B)

カタログ管理機能 ### 最小限の冗長性の安全性¶

デフォルトでは0に設定されているminimum_redundancy と呼ばれるグローバル/サーバーごとの構成オプションを使用して、PostgreSQLサーバーの定期バックアップの最小数を定義できます。

この値を0より大きい任意の数に設定することにより、 Barmanは、サーバーカタログに常に少なくともその数のバックアップがあることを確認します。

これにより、偶発的なbarman delete 操作から保護されます。

重要

アイテム保持ポリシー設定が最小冗長要件と競合しないことを確認してください。このトピックに関するメッセージについては、Barmanのログを定期的に確認してください。

保持ポリシー¶

Barmanは、バックアップの 保持ポリシー をサポートしています。

バックアップ保持ポリシーは、復旧手順のためにバックアップと関連するアーカイブログ（ログ先行書き込みセグメント）を保持する必要がある期間を決定するユーザー定義のポリシーです。

ユーザーの要求に基づいて、 Barmanは、現在の保持ポリシーを満たすために必要な定期的なバックアップと、それらのバックアップの完全なリカバリに必要なアーカイブされたWALファイルを保持します。

Barmanユーザーは、 バックアップの冗長性 （定期的なバックアップの数）または リカバリーウィンドウ （どれくらいの期間）に関して保持ポリシーを定義できます。

冗長性に基づく保持ポリシー

：冗長性ベースの保持ポリシーでは、ユーザーは保持する定期的なバックアップの数を決定します。冗長性ベースの保持ポリシーは、リカバリ期間を使用する保持ポリシーとは対照的です。

リカバリーウィンドウに基づく保持ポリシー

：リカバリウィンドウはBarmanバックアップ保持ポリシーの1つであり、 DBAが期間を指定すると、 Barmanはリカバリウィンドウ中の任意の時点へのポイントインタイムリカバリに必要なバックアップおよび/またはアーカイブされたWALファイルの保持を保証します。間隔は常に現在の時刻で終わり、ユーザーが指定した日数だけさかのぼります。たとえば、保持ポリシーが7日間の復旧ウィンドウに設定されており、現在時刻が金曜日の午前9時30分である場合、 Barmanは、前の金曜日。

スコープ¶

保持ポリシーは以下に対して定義できます。

PostgreSQLの定期的なベースバックアップ ：retention_policy 構成オプションを介して
アーカイブログ 、ポイントインタイムリカバリ用：wal_retention_policy 構成オプションを介して

重要

時間次元では、定期的なバックアップの時間枠にアーカイブログを含める必要があります。

ここには、完全または部分的なポイントインタイムリカバリの2つの一般的なユースケースがあります。

フルポイントインタイムリカバリのシナリオ：

：ベースバックアップとアーカイブログは同じ保持ポリシーを共有するため、使用可能な最初のバックアップからいつでも復旧できます。

部分的なポイントインタイムリカバリのシナリオ：

：ベースバックアップの保持ポリシーは、アーカイブログの保持ポリシーよりも広くなっています。たとえば、ユーザーは過去6か月の完全な週次バックアップを保持できますが、過去4週間のログをアーカイブできます（最後の4回の定期的な週次バックアップ）。

重要

現在、 Barmanは`wal_retention_policy` オプションを`main` に制限することにより、**フルポイントインタイムリカバリ**シナリオのみを実装しています。

それらの仕組み¶

Barmanのリテンションポリシーは次のとおりです。

自動化 ：barman cron によって強制
手動： Barmanは古いバックアップを報告し、削除できます

重要

現在、 Barmanは手動による強制を実装していません。この機能は、将来のバージョンで利用できるようになります。

構成と構文¶

保持ポリシーは、次の構成オプションを使用して定義できます。

retention_policy ：ベースバックアップ保持用
wal_retention_policy ：アーカイブログ保存用
retention_policy_mode ：auto にのみ設定できます（保持ポリシーはbarman cron コマンドによって自動的に適用されます）

これらの構成オプションはグローバルレベルとサーバーレベルの両方で定義できるため、ユーザーはマルチサーバー環境で最大限の柔軟性を発揮します。

`retention_policy` の構文¶

retention_policy を介したベースバックアップ保持ポリシーの一般的な構文は次のとおりです。

retention_policy = {REDUNDANCY value | RECOVERY WINDOW OF value {DAYS | WEEKS | MONTHS}}

そこで：

構文は大文字と小文字を区別しません
value は整数で> 0
冗長性保持ポリシー の場合： - value はサーバーの最小冗長性レベル以上である必要があります（その値が割り当てられていない場合、警告が生成されます）逆順の時系列で
リカバリウィンドウポリシー の場合： - リカバリ可能性のポイントは次のとおりです。逆順の時系列におけるその値は、サーバーの最小冗長性レベル以上である必要があります（その値に割り当てられておらず、警告が生成された場合）

デフォルトでは、 retention_policy は空です（保持は強制されません）。

`wal_retention_policy` の構文¶

現在、 wal_retention_policy に許可されている値は特別な値main です。これは、アーカイブログの保持ポリシーをベースバックアップの保持ポリシーにマップします。

フックスクリプト¶

Barmanを使用すると、データベース管理者は次の2つのイベントでフックスクリプトを実行できます。

バックアップの前後
バックアップの削除の前後
WALファイルがアーカイブされる前と後
WALファイルを削除する前と後

Barmanが管理できるフックスクリプトは2種類あります。

標準フックスクリプト
フックスクリプトを再試行

これら2種類のフックスクリプトの唯一の違いは、 Barmanはリターンコードをチェックせずに標準のフックスクリプトを1回のみ実行しますが、リトライフックスクリプトはリターンコードに応じて複数回実行される場合があります。

具体的には、リトライフックスクリプトを実行すると、 Barmanはリターンコードをチェックし、スクリプトがSUCCESS （標準のリターンコード0 ）、またはABORT_CONTINUE （リターンコード62 ）、またはABORT_STOP （リターンコード63 ）を返すまで無期限に再試行します。 Barmanは、他の戻りコードを再試行する一時的な障害として扱います。ユーザーにはより多くの権限が与えられます。フックスクリプトは、障害が一時的かどうかを指定することにより、ワークフローを制御できます。また、 ’pre’フックスクリプトの場合、 ABORT_STOP を返すことで、ユーザーはBarmanにメインオペレーションをエラーで中断するように要求できます。

フックスクリプトは次の順序で実行されます。

1.標準の「pre」フックスクリプト（存在する場合）

2.リトライ「pre」フックスクリプト（存在する場合）

3.リトライ「プレ」フックスクリプトがABORT_STOP で中止されなかった場合の実際のイベント（つまり、バックアップオペレーション、またはWALアーカイブ）

4.リトライ「post」フックスクリプト（存在する場合）

5.標準の「post」フックスクリプト（存在する場合）

フックスクリプトによって生成された出力は、 Barmanのログファイルに書き込まれます。

注釈

現在、 ABORT_STOP はリトライ「post」フックスクリプトで無視されます。これらの場合、追加の警告をログに記録することを除いて、 ABORT_STOP は`ABORT_CONTINUE` のように動作します。

バックアップスクリプト¶

これらのスクリプトは、次のグローバル構成オプションを使用して構成できます（サーバーごとにオーバーライドできます）。

pre_backup_script ：ベースバックアップの前に1回だけ実行され、終了コードをチェックしないフックスクリプト
pre_backup_retry_script ：ベースバックアップの前に実行されるフックスクリプトを、成功するか中止するまで繰り返し
post_backup_retry_script ：ベースバックアップ後に実行されるフックスクリプトを、成功するか中止するまで繰り返し
post_backup_script ：ベースバックアップ後に1回だけ実行され、終了コードをチェックしないフックスクリプト

スクリプト定義はシェルに渡され、終了コードを返すことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードを確認します（ hook script section を参照）。

シェル環境には次の変数が含まれます。

・ BARMAN_BACKUP_DIR ：バックアップ先ディレクトリ

・ BARMAN_BACKUP_ID ：バックアップのID

BARMAN_CONFIGURATION ： Barmanが使用する構成ファイル
BARMAN_ERROR ：エラーメッセージ（ post フェーズのみ）
BARMAN_PHASE ：スクリプトのフェーズ、 pre またはpost
BARMAN_PREVIOUS_ID ：以前のバックアップのID（存在する場合）
BARMAN_RETRY ：リトライスクリプトなら1 、そうでなければ0
BARMAN_SERVER ：サーバーの名前
BARMAN_STATUS ：バックアップのステータス
BARMAN_VERSION ：Barmanのバージョン

バックアップ削除スクリプト¶

バージョン 2.4 では、バックアップの前後の削除スクリプトが導入されています。

以前のスクリプトと同様に、バックアップ削除スクリプトはグローバル構成オプション内で構成でき、サーバーごとにオーバーライドできます。

pre_delete_script ：バックアップを削除する前に一度だけ、終了コードをチェックせずにフックスクリプトが起動されました
pre_delete_retry_script ：バックアップの削除前に実行されるフックスクリプトを、成功するか中止するまで繰り返し
post_delete_retry_script ：バックアップの削除後に実行されるフックスクリプトを、成功または中止するまで繰り返し
post_delete_script ：バックアップの削除後に一度だけ、終了コードをチェックせずに起動されたフックスクリプト

スクリプトはシェルを介して実行され、終了コードを返すことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードを確認します（上のセクションを参照）。

削除スクリプトは、バックアップスクリプトと同じ環境変数に加えて：

BARMAN_NEXT_ID ：次のバックアップのID（存在する場合）

WALアーカイブスクリプト¶

バックアップスクリプトと同様に、アーカイブスクリプトはグローバル構成オプションで構成できます（サーバーごとにオーバーライドできます）。

pre_archive_script ：メンテナンス（通常はbarman cron ）によってWALファイルがアーカイブされる前に1回だけ実行され、終了コードをチェックしないフックスクリプト
pre_archive_retry_script ：メンテナンス（通常barman cron ）によってWALファイルがアーカイブされる前に、成功するか中止されるまで繰り返し実行されるフックスクリプト
post_archive_retry_script ：メンテナンスによってWALファイルがアーカイブされた後、成功するか中止されるまで繰り返し実行されるフックスクリプト
post_archive_script ：メンテナンスでWALファイルがアーカイブされた後に一度だけ実行されるフックスクリプト、終了コードのチェックなし

スクリプトはシェルを介して実行され、終了コードを返すことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードを確認します（上のセクションを参照）。

アーカイブスクリプトは、いくつかの環境変数をバックアップスクリプトと共有します。

BARMAN_CONFIGURATION ： Barmanが使用する構成ファイル
BARMAN_ERROR ：エラーメッセージ（ post フェーズのみ）
BARMAN_PHASE ：スクリプトのフェーズ、 pre またはpost
BARMAN_SERVER ：サーバーの名前

次の変数は、アーカイブスクリプトに固有です。

BARMAN_SEGMENT ：WALファイルの名前
BARMAN_FILE ：WALファイルのフルパス
BARMAN_SIZE ：WALファイルのサイズ
BARMAN_TIMESTAMP ：WALファイルのタイムスタンプ
BARMAN_COMPRESSION ：WALファイルに使用される圧縮の種類

WAL削除スクリプト¶

バージョン 2.4 では、WALの前後の削除スクリプトが導入されています。

他のフックスクリプトと同様に、 wal deleteスクリプトはグローバル構成オプションで構成でき、サーバーごとにオーバーライドできます。

pre_wal_delete_script ：WALファイル削除前に実行されるフックスクリプト
pre_wal_delete_retry_script ：WALファイルの削除の前に実行されるフックスクリプトを、成功するか中止されるまで繰り返し
post_wal_delete_retry_script ：WALファイルの削除後に実行されるフックスクリプト、成功するか中止されるまで繰り返し
post_wal_delete_script ：WALファイル削除後に実行されるフックスクリプト

スクリプトはシェルを介して実行され、終了コードを返すことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードを確認します（上のセクションを参照）。

WAL削除スクリプトは、WALアーカイブスクリプトと同じ環境変数を使用します。

リカバリースクリプト¶

バージョン 2.4 では、回復前および回復後のスクリプトが導入されています。

以前のスクリプトと同様に、回復スクリプトはグローバル構成オプション内で構成でき、サーバーごとにオーバーライドできます。

pre_recovery_script ：バックアップの回復前に起動されたフックスクリプト、終了コードをチェックせずに1回のみ
pre_recovery_retry_script ：バックアップの復元の前に実行されるフックスクリプトを、成功するか中止するまで繰り返し
post_recovery_retry_script ：バックアップの回復後に実行されるフックスクリプトを、成功するか中止するまで繰り返し
post_recovery_script ：バックアップの回復後に一度だけ、終了コードをチェックせずに起動されたフックスクリプト

スクリプトはシェルを介して実行され、終了コードを返すことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードを確認します（上のセクションを参照）。

リカバリースクリプトは、バックアップスクリプトと同じ環境変数に加えて：

BARMAN_DESTINATION_DIRECTORY ：新しいインスタンスが回復されたディレクトリ
BARMAN_TABLESPACES ：テーブルスペースリロケーションマップ（JSON、存在する場合）
BARMAN_REMOTE_COMMAND ：リカバリで使用されるセキュアシェルコマンド（存在する場合）
BARMAN_RECOVER_OPTIONS ：リカバリ追加オプション（JSON、存在する場合）

カスタマイズ¶

ロックファイルディレクトリ¶

Barmanでは、 barman_lock_directory グローバルオプションを使用してロックファイルのディレクトリを指定できます。

ロックファイルは、グローバルおよびサーバーレベルでの同時作業を調整するために使用されます（たとえば、cron操作、バックアップ操作、WALアーカイブへのアクセスなど）。

デフォルトでは（下位互換性のため）、 barman_lock_directory はbarman_home に設定されます。

注釈

ユーザーは、実行時変数データ（たとえば、 /var/run/barman ）専用の揮発性パーティション内のディレクトリを使用することをお勧めします。

バイナリパス¶

バージョン1.6.0以降、 Barmanでは、グローバル/サーバーオプションpath_prefix を使用して、 Barmanが実行可能ファイルを探す1つ以上のディレクトリを指定できます。

path_prefix が提供される場合、コロンで区切られた1つ以上のディレクトリのリストが含まれている必要があります。 Barmanは最初にこれらのディレクトリ内を検索し、次にPATH 環境変数で指定されたディレクトリを検索します。

デフォルトでは、 path_prefix オプションは空です。

クラスター管理システムとの統合¶

Barmanは、スタンバイサーバー（ストリーミングレプリケーションまたは従来のファイルベースのログシッピングを使用）および（ https://www.repmgr.org/ ）[repmgr]のような高可用性ツールと統合するように設計されています。

アーキテクチャの観点から、WALファイルをBarmanサーバーに直接アーカイブするようにPostgreSQLを構成する必要があります。 Barmanは、 get-wal フレームワークのおかげで、WALハブとしても使用できます。このために、すべてのスタンバイサーバーでbarman-cli パッケージの一部であるbarman-wal-restore スクリプトを使用できます。

replication-status コマンドを使用すると、管理対象サーバー、特にホットスタンバイサーバーとWALストリーマーに接続されているストリーミングクライアントに関する情報を取得できます。

パラレルジョブ¶

デフォルトでは、 Barmanはバックアップと回復の両方の操作中にファイルのコピーに1つのワーカーのみを使用します。バージョン2.2以降、ファイルコピーを実行するワーカーの数をカスタマイズできます。この場合、コピーされるファイルはすべての並列ワーカーに均等に分散されます。

グローバルおよびサーバースコープで構成でき、対応する構成ファイルにこれらを追加します。

parallel_jobs = n

ここで、 n は、ファイルコピー操作で使用される並列ワーカーの数です。デフォルト値は1です。

いずれの場合も、ユーザーは backup または recover コマンドを実行するときにこの値をオーバーライドできます。たとえば、次のように4つの並列ワーカーを使用できます。

barman backup --jobs 4 server1

または、代わりに：

barman backup --j 4 server1

この並列ジョブ機能は、 rsync /SSH を介して構成されたサーバーでのみ使用可能であることに注意してください。ストリーミングプロトコルを介して構成されたサーバーの場合、 Barmanは現在1つのワーカーのみに制限されている pg_basebackup に依存します。

地理的な冗長性¶

バックアップサーバーのソースがPostgreSQLサーバーではなくBarmanインストールであるBarmanを使用して、 カスケードバックアップアーキテクチャ をセットアップすることができます。

この機能により、ユーザーはPostgreSQLバックアップの地理的に分散したコピーを透過的に保持できます。

Barmanの専門用語では、PostgreSQLサーバーではなくBarmanインストールに接続されているバックアップサーバーは パッシブノード と定義されています。パッシブノードは primary_ssh_command オプションを介して構成され、グローバル（プライマリBarmanインストールのフルレプリカの場合）とサーバーレベル（ダイレクトサーバーとパッシブサーバーの両方を持つ混合シナリオの場合）の両方で使用できます。

情報を同期¶

barman sync-info コマンドは、同期の目的で役立つBarmanサーバーの現在のステータスに関する情報を収集するために使用されます。使用可能な構文は次のとおりです。

barman sync-info [--primary] <server_name> [<last_wal> [<last_position>]]

このコマンドは、以下を含むJSONオブジェクトを返します。

そのサーバーのステータスがDONE であるすべてのバックアップのマップ
アーカイブされたすべてのWALファイルのリスト
サーバーの構成
最後に読み取った位置（xlogデータベースファイル内）
最後に読み取ったWALファイルの名前

JSON応答には、 master とpassive ノード間の同期に必要な情報がすべて含まれています。

--primary が指定されている場合、コマンドはローカルではなく、定義されたプライマリノードで実行されます。

構成¶

サーバーをpassive node として構成するのは簡単な操作です。サーバー構成に次のオプションを追加するだけです。

primary_ssh_command = ssh barman@primary_barman

このオプションは、プライマリサーバーへのSSH接続パラメーターを指定し、パッシブサーバーのバックアップデータのソースを識別します。

-c/--config オプションでbarmanを呼び出しており、パッシブノードがプライマリノードでbarmanを呼び出す場合は、次のオプションを追加します。

forward_config_path = true

ノードの同期¶

ノードが passive としてマークされている場合、 Barmanによって特別な方法で扱われます。

標準保守作業から除外されます
barman backup を含む、PostgreSQLへの直接操作は禁止されています

パッシブサーバーとそのプライマリ間の同期は、透過的に以下を呼び出すbarman cron によって自動的に管理されます。

barman sync-info --primary 、同期情報を収集するため
barman sync-backup 、プライマリノードで使用可能なすべてのバックアップのローカルコピーを作成するため
barman sync-wals 、プライマリノードで使用可能なすべてのWALファイルをローカルにコピーするため

手動同期¶

barman cron はパッシブ/プライマリノードの同期を自動的に管理しますが、次の方法でバックアップの同期を手動でトリガーできます。

barman sync-backup <server_name> <backup_id>

sync-backup barmanを起動すると、primary_ssh_commandを使用してマスターサーバーに接続し、リモートマシンにバックアップが存在する場合は、rsyncを使用してすべてのファイルのコピーを開始します。バックアップごとに1つの同期プロセスのみが許可されます。

WALファイルは、次の方法でも同期できます。

barman sync-wals <server_name>

クラウドスナップショットのバックアップ¶

スナップショットバックアップは、クラウドストレージボリュームの1つ以上のスナップショットで構成されるバックアップです。

次のいずれかのコマンドを使用して、: suitable PostgreSQL server のスナップショットバックアップを作成できます。

BarmanサーバーがWALとバックアップメタデータの保存に使用されている場合、 required configuration operations for snapshots を使用したbarman backup 。
Barmanサーバーがなく、代わりにWALとバックアップメタデータにクラウドオブジェクトストアが使用されている場合、必要な command line arguments を使用したbarman-cloud-backup 。

スナップショットバックアップの詳細¶

スナップショットバックアップを作成するための高レベルのプロセスは次のとおりです。

Barmanは、一連のプリフライトチェックを実行して、スナップショットオプション、インスタンス、ディスクを検証します。
Barmanは、 PostgreSQL backup API を使用してバックアップを開始します。

3.クラウドプロバイダーAPIを使用して、指定された各ディスクのスナップショットをトリガーします。 Barmanは、スナップショットがアプリケーションの一貫性を保証するために必要な状態に達するまで待ってから、次のディスクに進みます。

各ディスクのデバイス名など、追加のプロバイダー固有のデータがバックアップメタデータに保存されます。
各ディスクのマウントポイントとマウントオプションは、バックアップメタデータに保存されます。
Barmanは、PostgreSQLバックアップAPIを使用してバックアップを停止します。

クラウドプロバイダーAPI呼び出しは、バックアップコマンドが実行されるノードで行われます。これは、 Barmanサーバー（ barman backup を使用する場合）またはPostgreSQLサーバー（ barman-cloud-backup を使用する場合）のいずれかです。

次のプリフライトチェックは、各バックアップの前に実行されます。また、スナップショットバックアップ用に構成されたサーバーに対して barman check が実行されます。

・ snapshot_zone で指定されたアベイラビリティーゾーンにsnapshot_instance で指定されたコンピュートインスタンスが存在すること。

・ snapshot_zone で指定されたアベイラビリティーゾーンにsnapshot_disks で指定されたディスクが存在すること。

snapshot_disks で指定されたディスクがsnapshot_instance に接続されています。

・ snapshot_disks で指定されたディスクがsnapshot_instance にマウントされている。

スナップショットバックアップからのリカバリ¶

Barmanは現在、スナップショットバックアップからの完全に自動化されたリカバリを実行しません。これは、スナップショットからの復旧には、新しいインフラストラクチャのプロビジョニングと管理が必要であり、これは、Terraformなどの専用のInfrastructure-as-Codeソリューションでより適切に処理されるためです。

ただし、 barman recover コマンドを使用して、スナップショット復旧インスタンスを検証したり、安全でないオプションのPostgreSQL構成の確認などの復旧後のタスクを実行したり、必要なPITRオプションを設定したりできます。また、backup_labelファイルを所定の場所にコピーし（バックアップラベルはボリュームスナップショットに保存されないため）、必要なWAL間でコピーします（ --get-wal 回復オプションが使用されている場合、フェッチするようにPostgreSQL restore_command を構成しますWAL）。

barman-cloud-backup で作成されたバックアップを復元する場合、 barman recover の代わりに、より制限されたスナップショットのbarman-cloud-restore コマンドを使用する必要があります。

スナップショットバックアップからのリカバリは、次の手順で構成されます。

バックアップ中に作成されたスナップショットごとに新しいディスクをプロビジョニングします。
バックアップメタデータに従って、手順1でプロビジョニングした各ディスクがアタッチおよびマウントされたコンピューティングインスタンスをプロビジョニングします。
barman recover またはスナップショットのbarman-cloud-restore コマンドを使用して、リカバリを検証して終了します。

手順1と2は、既存のコードとしてのインフラストラクチャシステムで処理するのが最適ですが、これらの手順を手動またはカスタムスクリプトを使用して実行することもできます。このようなスクリプトの例は provided with Barman ですが、このスクリプトは実行される環境についてさまざまな仮定を行うため、実稼働での使用には適していません。

リカバリインスタンスがプロビジョニングされ、バックアップスナップショットからクローンされたディスクが接続されてマウントされたら、次の追加の引数を使用して barman recover を実行します。

--remote-ssh-command ：リカバリインスタンスへのログインに必要なsshコマンド。
--snapshot-recovery-instance ：クラウドプロバイダーが必要とするリカバリインスタンスの名前。
--snapshot-recovery-zone ：リカバリインスタンスが配置されているアベイラビリティーゾーンの名前。

例：

barman recover SERVER_NAME BACKUP_ID REMOTE_RECOVERY_DIRECTORY \
    --remote-ssh-command ssh USER@HOST \
    --snapshot-recovery-instance INSTANCE_NAME \
    --snapshot-recovery-zone ZONE_NAME

スナップショットバックアップのリカバリ時には、次のbarman recover 引数/構成変数を使用できないことに注意してください。

Command argument	Config variable .
--bwlimit	bandwidth_limit
--jobs	parallel_jobs
--recovery-staging-path	recovery_staging_path
--tablespace	N/A

Barmanは、バックアップがスナップショットバックアップであることを自動的に検出し、接続されているディスクがそのバックアップのスナップショットから複製されたことを確認します。 Barmanは、バックアップラベルとWALを所定の場所にコピーし、PostgreSQL構成で必要なリカバリオプションを設定することにより、PostgreSQLをリカバリ用に準備します。

スナップショットバックアップのバックアップメタデータ¶

リカバリディスクとインスタンスがコードとしてのインフラストラクチャ、アドホックな自動化、または手動のいずれでプロビジョニングされたかにかかわらず、 Barmanにクエリを実行して、特定のバックアップに必要なスナップショットを見つける必要があります。これは、バックアップ内の各スナップショットの詳細を提供する barman show-backup を使用して実現できます。例：

$ barman show-backup primary 20230123T131430
Backup 20230123T131430:
  Server Name            : primary
  System Id              : 7190784995399903779
  Status                 : DONE
  PostgreSQL Version     : 140006
  PGDATA directory       : /opt/postgres/data

  Snapshot information:
    provider             : gcp
    project              : project_id

    device_name          : pgdata
    snapshot_name        : barman-av-ubuntu20-primary-pgdata-20230123t131430
    snapshot_project     : project_id
    Mount point          : /opt/postgres
    Mount options        : rw,noatime

    device_name          : tbs1
    snapshot_name        : barman-av-ubuntu20-primary-tbs1-20230123t131430
    snapshot_project     : project_id
    Mount point          : /opt/postgres/tablespaces/tbs1
    Mount options        : rw,noatime

--format=json オプションは、外部ツールと統合するときに使用できます。

$ barman --format=json show-backup primary 20230123T131430
...
"snapshots_info": {
  "provider": "gcp",
  "provider_info": {
    "project": "project_id"
  },
  "snapshots": [
    {
      "mount": {
        "mount_options": "rw,noatime",
        "mount_point": "/opt/postgres"
      },
      "provider": {
        "device_name": "pgdata",
        "snapshot_name": "barman-av-ubuntu20-primary-pgdata-20230123t131430",
        "snapshot_project": "project_id"
      }
    },
    {
      "mount": {
        "mount_options": "rw,noatime",
        "mount_point": "/opt/postgres/tablespaces/tbs1"
      },
      "provider": {
        "device_name": "tbs1",
        "snapshot_name": "barman-av-ubuntu20-primary-tbs1-20230123t131430",
        "snapshot_project": "project_id",
      }
    }
  ]
}
...

barman-cloud-backup で取得したバックアップには、 barman-cloud-backup-list と共に使用してクラウドオブジェクトストア内のバックアップメタデータを照会できる類似の barman-cloud-backup-show コマンドがあります。

Features in detail¶

バックアップ機能¶

インクリメンタルバックアップ¶

帯域幅の使用を制限する¶

ネットワーク圧縮¶

バックアップ圧縮¶

圧縮アルゴリズム¶

コンプレッションワーカー¶

圧縮レベル¶

圧縮場所¶

圧縮形式¶

同時バックアップ¶

スタンバイの同時バックアップ¶

即時チェックポイント¶

ローカルバックアップ¶

アーカイブ機能 ### WAL圧縮¶

同期WALストリーミング¶

カタログ管理機能 ### 最小限の冗長性の安全性¶

保持ポリシー¶

スコープ¶

それらの仕組み¶

構成と構文¶

retention_policy の構文¶

wal_retention_policy の構文¶

フックスクリプト¶

バックアップスクリプト¶

バックアップ削除スクリプト¶

WALアーカイブスクリプト¶

WAL削除スクリプト¶

リカバリースクリプト¶

カスタマイズ¶

ロックファイルディレクトリ¶

バイナリパス¶

クラスター管理システムとの統合¶

パラレルジョブ¶

地理的な冗長性¶

情報を同期¶

構成¶

ノードの同期¶

手動同期¶

クラウドスナップショットのバックアップ¶

スナップショットバックアップの詳細¶

スナップショットバックアップからのリカバリ¶

スナップショットバックアップのバックアップメタデータ¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶