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 オプション（グローバル/サーバーごと）を介して、1秒あたりの最大キロバイト数を指定することにより、I / O帯域幅の使用を制限できます。デフォルトでは0、つまり無制限に設定されています。

重要

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

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

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 構成オプション（グローバル/サーバーごと）を使用して有効にできます。

重要

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

圧縮アルゴリズム¶

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

backup_compression = gzip|lz4|zstd

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

注釈

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

注釈

zstd バージョンは1.4.4以降である必要があります。 Debian 10（バスター）、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` 圧縮でのみ使用できます。 !!! zstd バージョンは1.5.0以上である必要があることに注意してください。または、マルチスレッドオプションでコンパイルされた1.4.4以降。

圧縮レベル¶

圧縮レベルは、 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がそのWALファイルを受信してアーカイブするまで、完全バックアップは一貫していると見なすことができないことに注意してください。 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は引き続き有効ですが、 Barman構成を更新して、バックアップの作成とWALの受信に新しいスタンバイを使用するようにできます。

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 に設定する必要があります。この機能は本質的に同等のrsync と同じです。これは代わりにSSHに依存し、リモートで動作します。 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 ：圧縮フィルター

注： 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)

カタログ管理機能¶

最小限の冗長性の安全性¶

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

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

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

重要

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

保持ポリシー¶

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

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

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

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

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

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

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

：リカバリウィンドウはBarmanバックアップ保持ポリシーの一種です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」フックスクリプト（存在する場合）

retry ’pre’フックスクリプト（存在する場合）

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

retry ’post’フックスクリプト（存在する場合）

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

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

注釈

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

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

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

pre_backup_script ：ベースバックアップの前に一度だけ実行されるフックスクリプト、終了コードのチェックなし
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 ：バックアップの削除後に起動されたフックスクリプト、終了コードをチェックせずに1回のみ

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

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

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

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

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

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

スクリプトはシェルを介して実行され、任意の終了コードを返すことができます。再試行スクリプトの場合にのみ、 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 に設定されます。

Tip

ユーザーは、実行時変数データ専用のもの（たとえば、 /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は pg_basebackup に依存しますこれは現在1つのワーカーのみに制限されています。

パラレルジョブとsshd MaxStartups¶

Barmanは、SSHサーバーで許可されている同時非認証接続の最大数を超えないようにするために、並列Rsyncジョブが開始されるレートを制限します。この最大値はsshdパラメーターMaxStartups によって定義されます - MaxStartups を超える接続が作成されたがまだ認証されていない場合、SSHサーバーは接続の一部またはすべてをドロップし、バックアップまたはリカバリが失敗する可能性があります。

ほとんどのプラットフォームでのsshd MaxStartups のデフォルト値は10です。したがって、 Barmanは10のバッチで並列ジョブを開始し、1秒間に複数のジョブのバッチを開始しません。これにより、毎秒10ジョブの実効レート制限が得られます。

この制限は、次の2つの構成オプションを使用して変更できます。

・ parallel_jobs_start_batch_size ： 1バッチで起動する並列ジョブの最大数。

parallel_jobs_start_batch_period ：ジョブの単一のバッチが開始される秒単位の時間。

たとえば、2秒以内に5つ以下の新しいRsyncジョブが作成されないようにするには：

parallel_jobs_start_batch_size = 5
parallel_jobs_start_batch_period = 2

構成オプションは、 barman backup およびbarman recover コマンドの両方で次の引数を使用してオーバーライドできます。

--jobs-start-batch-size
--jobs-start-batch-period

地理的冗長性¶

Barmanを使用して カスケードバックアップアーキテクチャ をセットアップすることが可能です。バックアップサーバーのソースは、PostgreSQLサーバーではなく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は、スナップショットがアプリケーションの一貫性を保証するために必要な状態に達するまで待ってから、次のディスクに進みます。

4.各ディスクのデバイス名など、追加のプロバイダー固有のデータは、バックアップメタデータに保存されます。

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

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

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

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

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

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

・ snapshot_disks で指定されたディスクをsnapshot_instance にマウントします。

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

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

ただし、 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 引数/ config変数は使用できないことに注意してください。

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

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

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

リカバリディスクとインスタンスがinfrastructure-as-code、アドホックオートメーション、または手動のいずれでプロビジョニングされているかにかかわらず、 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削除スクリプト¶

リカバリースクリプト¶

カスタマイズ¶

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

バイナリパス¶

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

パラレルジョブ¶

パラレルジョブとsshd MaxStartups¶

地理的冗長性¶

同期情報¶

構成¶

ノード同期¶

手動同期¶

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

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

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

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

`retention_policy` の構文¶

`wal_retention_policy` の構文¶