newpage

＃機能の詳細

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

このリストは網羅的ではありません。多くのシナリオがBarman設定で機能するように作成できるためです。それでも、一般的なパターンを議論することは有用です。

バックアップ機能¶

増分バックアップ¶

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

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

重要：現時点では、reuse_backupオプションはpostgresバックアップメソッドでは使用できません。

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

フルバックアッププロセスにかかる時間を短縮する
いくつかの定期的なバックアップで占有されるディスクスペースを削減します（データ重複排除）

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

主な概念は、後続のベースバックアップが、前のバックアップ以降に変更されていないファイルを共有し、ディスク使用量を適切に節約することです。これはVLDBcontextsのと高い割合of_read専用歴史tables_を含むこれらのデータベースの特に真です。

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

off：標準フルバックアップ（デフォルト）
link：サーバーの最後のバックアップを再利用する増分バックアップ変更されていないファイルのハードリンクを作成する（バックアップスペース）および時間短縮）
copy：サーバーの最後のバックアップを再利用する増分バックアップ変更されていないファイルのコピーを作成する（バックアップ時間のためだけに）削減）

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

reuse_backup = link

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

最後のノートとして、ユーザーがbarmanbackupコマンドの--reuse-backupランタイムによってreuse_backupoptionの設定を上書きすることができます。同様に、ランタイムオプションは、off、link、およびcopyの3つの値を受け入れます。例、次のようにワンoffincrementalバックアップを実行することができます：

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

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

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

重要： bandwidth_limitおよびthe> tablespace_bandwidth_limitオプションは、> postgresバックアップメソッドではサポートされていません

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

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

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

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

ネットワーク圧縮¶

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

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

network_compression = true|false

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

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

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

また、Barmanは9.2以上のデータベースサーバーからPostgreSQLのバックアップを同時方式で、主にbackup_options設定パラメータて実行できます。[^ ABOUT_CONCURRENT_BACKUP]

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

これにより、Barmanによる新しいアーキテクチャシナリオが導入されスタンバイサーバからのバックアップ**、rsyncを使用。

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

デフォルトでは、backup_optionsは透過的にbackup_optionsto concurrent_backupを設定する必要があり、下位互換性のPostgreSQL 9.6のreasons.Usersおよびそれ以降のバージョンの設定toexclusive_backupです。

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

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

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

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

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

現在、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のサポートは非推奨です。

推奨される最も簡単な方法は、スタンバイから直接レプリケーションスロットを使用して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_checkpointconfiguration global / サーバオプション（デフォルトでfalseに設定）を使用して変更できます。

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

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

--immediate-checkpoint。即時チェックポイントを強制します。
--no-immediate-checkpoint、チェックポイントの待機を強制します起こる。

ローカルバックアップ¶

免責事項：この機能は、同じサーバー上のバーマンとPostgreSQL存在として>、稼動の使用を推奨し、故障の同じシングルポイント>のパートであるされていません> 2ndQuadrantの顧客の一部はのためのサポートを追加するために要求してきました>バーマンへのローカルバックアップは、企業によって>配信24/7稼動サービスの下で、最も重要なのは、特定の状況下で使用>とします。現在、この機能を使用するには、ソースからのインストールが必要です。または、postgres>ユーザの環境を、権限とロギングおよびcron構成の観点からカスタマイズする必要があります。

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

このアーキテクチャは、RPOとRTOの観点betterresultsで、2ndQuadrant.ForでのPostgreSQLの強化、事業継続の経験を承認されていない、2ndQuadrantはまだレプリケーションおよびモニタリングのためにウィットネスサーバのように行動しcapableof、バーマンのリモートインストールとthesharedナッシングアーキテクチャを推奨しています。

ローカルバックアップの唯一の要件は、BarmanがPostgreSQLサーバーと同じユーザ（通常はpostgres）で実行されることです。コミュニティパッケージソフトがデフォルトでbarmanuserの下に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：解凍フィルター

注意： pybzip2およびpygzipを除くすべてのメソッドは、新しいプロセスをフォークするためにbarman> archive-walを必要とします。

同期WALストリーミング¶

重要：この機能はPostgreSQL 9.5以降でのみ利用可能です。

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

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

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

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

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

synchronous_standby_names = 'barman_receive_wal'

重要：これは設定の例であり、それを示すために> Barmanは同期的スタンバイノードとして適格です。> Barmanのみを使用することはお勧めしません。> _ [“同期レプリケーション” ] [synch] _ PostgreSQLの文書>このトピックに関する詳細情報。

設定をリロードするには、 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ファイルを満たすために必要な定期的なバックアップを保持します。

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

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

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

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

：リカバリは、リカバリ・ウィンドウ中の任意の時間にポイントインタイムリカバリのために1つのDBAは、一定の期間を指定しているバーマンバックアップ保存ポリシーの種類、およびバックアップのバーマン性を保証保持および/またはWALをアーカイブに必要なファイルです。インターバルは常に現在の時刻で終了し、ユーザが指定した日数だけ時間を遡ります。例、保持ポリシー日間のリカバリ、および現在の時刻に設定されている場合は、金曜日の午前9時30分で、バーマンは9:30 AMにポイントインタイムリカバリのバックを可能にするために必要なバックアップを保持します前金曜日。

スコープ¶

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

** PostgreSQL定期ベースバックアップ**：retention_policyを使用設定オプション
アーカイブログ、Point-In-Time-Recoveryの場合： wal_retention_policy構成オプション

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

ここには、2つの典型的な使用例があります。完全または部分的な特定時点回復です。

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

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

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

：ベースバックアップの保持ポリシーはアーカイブログのポリシーよりも広いため、例、ユーザーは過去6か月間の完全な週単位のバックアップを保持できますが、過去4週間のアーカイブログを保持できます定期的な週4回のバックアップ）。

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

仕組み¶

バーマンの保持ポリシーは次のとおりです。

自動化：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ファイルが削除される前後

バーマンが管理できるフックスクリプトには2つのタイプがあります。

標準フックスクリプト
フックスクリプトのリトライ

これら2つのタイプのフックスクリプトの唯一の違いは、Barmanは戻りコードをチェックせずに標準のフックスクリプトを1回だけ実行するのに対して、リトライフックスクリプトはリターンコードに応じて2回以上実行される場合があることです。

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

フックスクリプトは、次のオーダーで実行されます。

1.標準の「pre」フックスクリプト（存在する場合）2。リトライ’pre’フックスクリプト（存在する場合）3。リトライの「pre」フックスクリプトがで中止されなかった場合の実際のイベント（バックアップオペレーション、またはWALアーカイビング）。リトライの「投稿」フックスクリプト（存在する場合）5。標準の ’post’フックスクリプト（存在する場合）

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

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

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

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

pre_backup_script：_hook script_実行_before_ベースバックアップ、一度だけ、終了コードのチェックなし
pre_backup_retry_script：retryフックscript_実行_before a ベースバックアップ、成功またはアボートまで繰り返し
post_backup_retry_script：retryフックscript_実行_after a ベースバックアップ、成功またはアボートまで繰り返し
post_backup_script：_hook script_実行後_after_ベースバックアップ、一度だけ、終了コードのチェックなし

スクリプト定義はシェルに渡され、任意の終了コードを結果ことができます。 _retry_スクリプトの場合のみ、Barmanはリターンコードをチェックします（を参照）。

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

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：バーマンのバージョン

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

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

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

pre_delete_script：_hook script_が起動された_before_削除バックアップの1回のみ、終了コードのチェックなし
pre_delete_retry_script：retryフックscript_実行_before バックアップの削除、成功またはアボートまで繰り返し
post_delete_retry_script：retryフックscript_実行_after バックアップの削除、成功またはアボートまで繰り返し
post_delete_script：_hook script_起動_after_削除バックアップの1回のみ、終了コードのチェックなし

スクリプトは、シェルを介して実行され、_retry_スクリプト、バーテンダーチェックリターンコード（煮上側部分）の場合には任意の終了コード.Onlyを結果ことができます。

削除スクリプトは、バックアップスクリプトと同じ環境変数にプラス、次を使用します。

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

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

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

pre_archive_script：hook script_実行_before WALファイルはメンテナンス（通常はbarman cron）によってアーカイブされ、一度だけ、終了コードを確認してください
pre_archive_retry_script：retryフックscript_実行_before a WALファイルはメンテナンス（通常はbarman cron）によってアーカイブされます。成功するか中止されるまで繰り返し
post_archive_retry_script：retryフックscript_実行_after a WALファイルはメンテナンスによってアーカイブされます。成功または中止
post_archive_script：hook script_実行_after WALファイルはメンテナンスによってアーカイブされ、終了コードはチェックされずに1回だけ

スクリプトは、シェルを介して実行され、_retry_スクリプト、バーテンダーチェックリターンコード（煮上側部分）の場合には任意の終了コード.Onlyを結果ことができます。

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

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：hook script_が実行される_before WALファイルの削除
pre_wal_delete_retry_script：retryフックscript_実行_before WALファイルの削除、成功するまで繰り返しまたは中止されました
post_wal_delete_retry_script：retryフックscript_実行_after WALファイルの削除、成功するまで繰り返しまたは中止されました
post_wal_delete_script：hook script_が実行された_after WALファイルの削除

スクリプトは、シェルを介して実行され、_retry_スクリプト、バーテンダーチェックリターンコード（煮上側部分）の場合には任意の終了コード.Onlyを結果ことができます。

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

回復スクリプト¶

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

以前のスクリプトとして、リカバリスクリプトはglobalconfigurationオプション内で構成でき、サーバーごとにそれらをオーバーライドできます。

pre_recovery_script：_hook script_が起動された_before_リカバリバックアップの1回のみ、終了コードのチェックなし
pre_recovery_retry_script：retryフックscript_実行_before バックアップのリカバリ、成功またはアボートまで繰り返し
post_recovery_retry_script：retryフックscript_実行_after バックアップのリカバリ、成功またはアボートまで繰り返し
post_recovery_script：_hook script_を起動しました_after_リカバリバックアップの1回のみ、終了コードのチェックなし

スクリプトは、シェルを介して実行され、_retry_スクリプト、バーテンダーチェックリターンコード（煮上側部分）の場合には任意の終了コード.Onlyを結果ことができます。

回復スクリプトは、backupscriptと同じ環境変数にプラス、次を使用します。

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は、スタンバイサーバ（ストリーミングレプリケーションまたは従来のファイルベースのログシッピング）および[repmgr] [repmgr]などの高可用性ツールとの統合用に設計されています。

アーキテクチャのビューからは、PostgreSQLはtoarchive WALは、バーマンserver.Barmanにファイルを直接get-walフレームワークのおかげで、この目的のWAL hub.Forとしても使用することができるように構成されている必要があり、あなたは単語の一部、barman-wal-restoreスクリプトを使用することができますすべてのスタンバイサーバを含むbarman-cliパッケージ。

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

並列ジョブ¶

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

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

parallel_jobs = n

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

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

barman backup --jobs 4 server1

または、代わりに：

barman backup --j 4 server1

この並列ジョブ機能は、rsync / SSHを介して構成されたサーバーでのみ使用できることにノートてください。 streamingprotocolを介して構成されたサーバーの場合、Barmanは現在1ワーカーのみに制限されているpg_basebackupに依存します。

地理的冗長性¶

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

この機能により、ユーザーは透過的にPostgreSQLバックアップの_geographically distributed_copiesを保持できます。

バーマン用語、PostgreSQLが定義されているよりもinstallationratherバーマンに接続されているバックアップサーバパッシブノード。Aのパッシブノードがprimary_ssh_commandオプションで構成され、プライマリバーマンインストールの完全なレプリカのために（グローバルにavailablebothで）およびサーバーレベル（混在シナリオの場合、_direct_サーバーと_passive_サーバーの両方を使用）。

同期情報¶

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接続パラメーターを指定します。

ノードの同期¶

ノードがpassiveとしてマークされると、Barmanによって特別な方法で処理されます。

標準のメンテナンス操作から除外されます
barman backupを含む、 PostgreSQLへの直接操作は禁止されています

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

1.同期情報を収集するオーダーの。 barman sync-backup、プライマリnode3で利用可能なすべてのバックアップのローカルコピーを作成するオーダー。 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`の構文¶