Features in detail¶

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

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

バックアップ機能¶

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

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

注釈

Block level incremental backup will be available in future versions.

重要

The reuse_backup option can't be used with the postgres backup method at this time.

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、つまり無制限に設定されています。

重要

the bandwidth_limit option is supported with the postgres backup method, but the tablespace_bandwidth_limit option is available only if you use rsync .

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

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

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

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

ネットワーク圧縮¶

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

重要

the network_compression option is not available with the postgres backup method.

network_compression = true|false

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

バックアップ圧縮¶

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

重要

the backup_compression and other options discussed in this section are not available with the rsync or local-rsync backup methods. Only with postgres backup method.

圧縮アルゴリズム¶

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

backup_compression = gzip|lz4|zstd

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

注釈

On Ubuntu 18.04 (bionic) the lz4 utility is available in the liblz4-tool pacakge.

注釈

zstd version must be 1.4.4 or higher. The system packages for zstd on Debian 10 (buster), Ubuntu 18.04 (bionic) and SLES 12 install an earlier version - backup_compression = zstd will not work with these packages.

注釈

lz4 and zstd are only available with PostgreSQL version 15 or higher.

重要

If you are using backup_compression you must also set recovery_staging_path so that barman recover is able to recover the compressed backups. See the Recovering compressed backups section for more information.

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

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

backup_compression_workers = 2

注釈

This option is only available with zstd compression. !!! Note zstd version must be 1.5.0 or higher. Or 1.4.4 or higher compiled with multithreading option.

圧縮レベル¶

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

圧縮場所¶

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

重要

the backup_compression_location option is only available when running against PostgreSQL 15 or later.

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 uses external tools to manage compressed backups. Depending on the backup_compression and backup_compression_format You may need to install one or more tools on the Postgres server and the Barman server. The following table will help you choose according to your configuration.

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 を使用します。 [1] これは、PostgreSQL 9.6以降のバックアップを取得する推奨される方法です（ただし、PostgreSQL 15ベータでは関数の名前が pg_backup_start および pg_backup_stop に変更されました）。

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

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

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

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

重要

In case of a concurrent backup, currently Barman cannot determine whether the closing WAL file of a full backup has actually been shipped - opposite of an exclusive backup where PostgreSQL itself makes sure that the WAL file is correctly archived. Be aware that the full backup cannot be considered consistent until that WAL file has been received and archived by Barman. Barman 2.5 introduces a new state, called WAITING_FOR_WALS , which is managed by the check-backup command (part of the ordinary maintenance job performed by the cron command). From Barman 2.10, you can use the --wait option with barman backup command.

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

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

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

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

primary_conninfo

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

注釈

It is especially important that primary_conninfo is set if the standby is to be backed up when there is little or no write traffic on the primary. If primary_conninfo is not set then the backup will still run however it will wait at the stop backup stage until the current WAL semgent on the primary is newer than the latest WAL required by the backup.

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

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

WAL streaming セクションの指示に従ってください。

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

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

注釈

With PostgreSQL 10 and earlier Barman cannot handle WAL streaming and WAL archiving being enabled at the same time on a standby. You must therefore disable WAL archiving if using WAL streaming and vice versa. This is because it is possible for WALs produced by PostgreSQL 10 and earlier to be logically equivalent but differ at the binary level, causing Barman to fail to detect that two WALs are identical.

即時チェックポイント¶

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

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

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

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

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

ローカルバックアップ¶

特別な状況では、 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 streaming connection を介して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

重要

this is only an example of configuration, to show you that Barman is eligible to be a synchronous standby node. We are not suggesting to use ONLY Barman. You can read Synchronous Replication from the PostgreSQL documentation for further information on this topic.

構成をリロードするには、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 操作から保護されます。

重要

Make sure that your retention policy settings do not collide with minimum redundancy requirements. Regularly check Barman's log for messages on this topic.

保持ポリシー¶

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

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

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

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

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

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

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

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

スコープ¶

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

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

重要

In a temporal dimension, archive logs must be included in the time window of periodic backups.

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

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

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

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

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

重要

Currently, Barman implements only the full point in time recovery scenario, by constraining the wal_retention_policy option to main .

それらの仕組み¶

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

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

重要

Currently Barman does not implement manual enforcement. This feature will be available in future versions.

構成と構文¶

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

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のログファイルに書き込まれます。

注釈

Currently, ABORT_STOP is ignored by retry 'post' hook scripts. In these cases, apart from logging an additional warning, ABORT_STOP will behave like 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 に設定されます。

Tip

Users are encouraged to use a directory in a volatile partition, such as the one dedicated to run-time variable data (e.g. /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>

Features in detail¶

バックアップ機能¶

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

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

ネットワーク圧縮¶

バックアップ圧縮¶

圧縮アルゴリズム¶

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

圧縮レベル¶

圧縮場所¶

圧縮形式¶

同時バックアップ¶

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

即時チェックポイント¶

ローカルバックアップ¶

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

同期WALストリーミング¶

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

保持ポリシー¶

スコープ¶

それらの仕組み¶

構成と構文¶

retention_policy の構文¶

wal_retention_policy の構文¶

フックスクリプト¶

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

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

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

WAL削除スクリプト¶

リカバリースクリプト¶

カスタマイズ¶

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

バイナリパス¶

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

パラレルジョブ¶

地理的な冗長性¶

情報を同期¶

構成¶

ノードの同期¶

手動同期¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶