機能の詳細¶

このセクションでは、いくつかの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 9.4以降の`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` バックアップ方法では使用できません。

backup_compression = gzip

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

重要

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

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

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

重要

同時バックアップでは、PostgreSQL 9.2、9.3、9.4、および9.5のユーザーがクラスターのすべてのPostgreSQLサーバーに`pgespresso` オープンソース拡張機能をインストールする必要があります。詳細とソースコードについては、 pgespresso extension website をご覧ください。 Barmanは、PostgreSQL 9.6で導入された新しいAPIをサポートしています。これにより、このバージョンのPostgreSQLから同時バックアップを実行するための`pgespresso` 拡張機能の要件が削除されます。

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

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

ssh_command は宛先Postgresサーバーを指す必要があります
conninfo は、宛先Postgresデータベース上のデータベースを指す必要があります。 PostgreSQL 9.2、9.3、9.4、および9.5を使用する場合、 CREATE EXTENSION を介してpgespresso を正しくインストールする必要があります。 9.6以降を使用すると、同時バックアップはPostgresネイティブAPIを介して実行されます（バックアップの開始から停止までアクティブな接続が必要です）。

重要

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

スタンバイからのバックアップに関する現在の制限¶

Barmanは現在、バックアップデータ（ベースバックアップとWALファイル）が1つのサーバーのみから来ていることを必要としています。したがって、スタンバイからのバックアップの場合、スタンバイサーバーを指定する必要があります。

conninfo
streaming_conninfo 、postgres をbackup_method として使用および/またはWALストリーミングに依存している場合
ssh_command 、rsync をbackup_method として使用する場合

重要

Barman 2.8以降、スタンバイからのバックアップはPostgreSQL 9.4以降でのみサポートされています（バージョン9.4および9.5には pgespresso が必要です）。 9.2および9.3のサポートは非推奨です。

推奨される最も簡単な方法は、レプリケーションスロットを使用してWALストリーミングをスタンバイから直接セットアップすることです。これにはPostgreSQL 9.4が必要です。これは次のことを意味します。

「レプリケーションスロット」を含む「WALストリーミング」セクションの説明に従って、streaming_archiver = on を構成します
archiver = on を無効にする

または、PostgreSQL 9.5からは、archive_command とarchive_mode = always を使用し、WALストリーミングを無効にすることにより、スタンバイからアーカイブすることを決定できます。

注釈

残念ながら、 BarmanがWAL複製チェックと an undocumented behaviours in all versions of PostgreSQL を実行する方法が原因で、現在スタンバイから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圧縮¶

構成ファイルでcompression オプションが設定されている場合、 barman cron コマンドは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ストリーミング¶

重要

この機能はPostgreSQL 9.5以降でのみ使用できます。

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 configurationオプションを介して
アーカイブログ 、ポイントインタイムリカバリ用：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アーカイブ）

retry ’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 ：バックアップの削除前に起動されたフックスクリプト、終了コードをチェックせずに1回のみ
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ファイルがアーカイブされた後に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は現在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>

機能の詳細¶

バックアップ機能¶

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

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

ネットワーク圧縮¶

バックアップ圧縮¶

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

スタンバイからのバックアップに関する現在の制限¶

即時チェックポイント¶

ローカルバックアップ¶

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

同期WALストリーミング¶

カタログ管理機能¶

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

保持ポリシー¶

スコープ¶

それらの仕組み¶

構成と構文¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶

フックスクリプト¶

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

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

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

WAL削除スクリプト¶

リカバリースクリプト¶

カスタマイズ¶

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

バイナリパス¶

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

パラレルジョブ¶

地理的な冗長性¶

情報を同期¶

構成¶

ノード同期¶

手動同期¶

前のトピックへ

次のトピックへ

目次

機能の詳細¶

バックアップ機能¶

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

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

ネットワーク圧縮¶

バックアップ圧縮¶

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

スタンバイからのバックアップに関する現在の制限¶

即時チェックポイント¶

ローカルバックアップ¶

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

同期WALストリーミング¶

カタログ管理機能¶

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

保持ポリシー¶

スコープ¶

それらの仕組み¶

構成と構文¶

retention_policy の構文¶

wal_retention_policy の構文¶

フックスクリプト¶

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

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

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

WAL削除スクリプト¶

リカバリースクリプト¶

カスタマイズ¶

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

バイナリパス¶

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

パラレルジョブ¶

地理的な冗長性¶

情報を同期¶

構成¶

ノード同期¶

手動同期¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶