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

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

最後に、ユーザーはノートコマンドの --reuse-backup ランタイムオプションを使用して、 reuse_backup オプションの設定をオーバーライドできます。同様に、ランタイムオプションは、 off 、 link 、および copy の3つの値を受け入れます。例、次のように一時的な増分バックアップを実行できます。

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

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

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

重要

bandwidth_limit オプションは、 Postgres 9.4以降の postgres バックアップメソッドでサポートされていますが、 tablespace_bandwidth_limit オプションは rsync を使用する場合にのみ使用できます

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

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

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

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

ネットワーク圧縮¶

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

重要

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

network_compression = true|false

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

並行バックアップとスタンバイからのバックアップ¶

通常、バックアップ操作中に、 Barmanは_exclusive backup_にPostgreSQLネイティブ関数 pg_start_backup および pg_stop_backup を使用します。これらの操作は、読み取り専用のスタンバイサーバでは許可されていません。

また、主にBarman設定パラメータを使用して、9.2以降のデータベースサーバーからPostgreSQLのバックアップを 同時方式 で実行できます。 1

これにより、 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 は exclusive_backup に透過的に設定されています。 PostgreSQL 9.6以降のバージョンのユーザーは、 backup_options を concurrent_backup に設定する必要があります。

重要

PostgreSQL 9.5がコミュニティによってEOLとして宣言されると、 Barmanはデフォルトで backup_options を concurrent_backup に設定します。 pgespresso のサポートは終了します。

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

重要

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

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

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

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

重要

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

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

「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 、チェックポイントの待機を強制します起こる。

ローカルバックアップ¶

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

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

このアーキテクチャは、 EnterpriseDBによって承認されていません。 PostgreSQLのビジネス継続性を強化し、RPOとRTOの点でより良い結果を得るために、 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は、バックアップの 保持ポリシー をサポートしています。

バックアップ保存ポリシーは、リカバリ手順のためにバックアップおよび関連するアーカイブログ（Write Ahead Logセグメント）を保持する必要がある期間を決定するユーザー定義のポリシーです。

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

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

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

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

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

：リカバリウィンドウは、 Barmanバックアップ保存ポリシーの一種ですDBAは期間を指定し、 Barmanは、リカバリウィンドウ中の任意の時点へのポイントインタイムリカバリに必要なバックアップやアーカイブWALファイルの保持を保証します。インターバルは常に現在の時刻で終了し、ユーザが指定した日数だけ過去に戻ります。例、保持ポリシーが7日間のリカバリウィンドウに設定されており、現在の時刻が金曜日の午前9:30である場合、 Barmanは、特定のポイントインタイムリカバリを午前9:30に戻すために必要なバックアップを保持します前金曜日。

スコープ¶

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

重要

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

ここには、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.実際のイベント（つまり、バックアップオペレーション、またはWALアーカイビング）。 ABORT_STOP で中断4.リトライの ’post’フックスクリプト（存在する場合）5.標準の ’post’フックスクリプト（存在する場合）

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

注釈

現在、 ABORT_STOP は 'post'フックスクリプトのリトライによって無視されます。これらの場合、追加のワーニングをロギングする以外は、 ABORT_STOP は ABORT_CONTINUE のように動作します。

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

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

pre_backup_script ：ベースバックアップの前に実行されるフックスクリプト、一度だけ、終了コードのチェックなし
pre_backup_retry_script ：フックスクリプトのリトライベースバックアップ、成功またはアボートまで繰り返し
post_backup_retry_script ：後に実行されるリトライフックスクリプトベースバックアップ、成功またはアボートまで繰り返し
post_backup_script ：ベースバックアップ後に実行されるフックスクリプト、一度だけ、終了コードのチェックなし

スクリプト定義はシェルに渡され、任意の終了コードを結果ことができます。リトライスクリプトの場合のみ、 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 ：削除後に起動されるフックスクリプトバックアップの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 ：リカバリ後に起動されるフックスクリプトバックアップの1回のみ、終了コードのチェックなし

スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。リトライスクリプトの場合のみ、 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 など）などのvolatileパーティション内のディレクトリを使用することをお勧めします。

バイナリ経路¶

バージョン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 に依存します。

地理的冗長性¶

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 によって自動的に管理され、透過的に呼び出されます。

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

手動同期¶

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

barman sync-backup <server_name> <backup_id>

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

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

barman sync-wals <server_name>

1: 同時バックアップは、バージョン9.2以降、streaming レプリケーション protocol（例、 pg_basebackup などのツールを使用）を介してPostgreSQLで使用可能な技術です。

Features in detail¶

バックアップ機能¶

増分バックアップ¶

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

ネットワーク圧縮¶

並行バックアップとスタンバイからのバックアップ¶

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

即時チェックポイント¶

ローカルバックアップ¶

アーカイブ機能¶

WAL圧縮¶

同期WALストリーミング¶

カタログ管理機能¶

最小の冗長性の安全性¶

保持ポリシー¶

スコープ¶

仕組み¶

設定と構文¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶

フックスクリプト¶

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

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

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

WAL削除スクリプト¶

回復スクリプト¶

カスタマイズ¶

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

バイナリ経路¶

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

並列ジョブ¶

地理的冗長性¶

同期情報¶

設定¶

ノードの同期¶

手動同期¶

前のトピックへ

次のトピックへ

目次

Features in detail¶

バックアップ機能¶

増分バックアップ¶

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

ネットワーク圧縮¶

並行バックアップとスタンバイからのバックアップ¶

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

即時チェックポイント¶

ローカルバックアップ¶

アーカイブ機能¶

WAL圧縮¶

同期WALストリーミング¶

カタログ管理機能¶

最小の冗長性の安全性¶

保持ポリシー¶

スコープ¶

仕組み¶

設定と構文¶

retention_policy の構文¶

wal_retention_policy の構文¶

フックスクリプト¶

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

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

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

WAL削除スクリプト¶

回復スクリプト¶

カスタマイズ¶

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

バイナリ経路¶

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

並列ジョブ¶

地理的冗長性¶

同期情報¶

設定¶

ノードの同期¶

手動同期¶

`retention_policy` の構文¶

`wal_retention_policy` の構文¶