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

重要

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 、およびnone です。 none 圧縮アルゴリズムは、非圧縮のアーカイブを作成します。

backup_compression = gzip|lz4|zstd|none

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

注釈

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

注釈

zstd バージョンは1.4.4以降である必要があります。 Debian 10 Buster、Ubuntu 18.04 bionic、およびSLES 12の`zstd` システムパッケージは、以前のバージョンをインストールします。 backup_compression = zstd はこれらのパッケージでは動作しません。

注釈

lz4 および`zstd` は、PostgreSQLバージョン15以降でのみ使用できます。

重要

backup_compression を使用している場合、 barman recover が圧縮バックアップをリカバリできるように`recovery_staging_path` も設定する必要があります。 Recovering compressed backups を参照してください

詳細については、セクションをご覧ください。

圧縮ワーカー#

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

backup_compression_workers = 2

注釈

このオプションは、 zstd 圧縮でのみ使用できます。

注釈

zstd バージョンは1.5.0以降である必要があります。またはマルチスレッドオプションでコンパイルされた1.4.4以上。

圧縮レベル#

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

none 圧縮はbackup_compression_level=0 のみをサポートしています。

注釈

backup_compression_level 使用可能な値とデフォルト値は、使用される圧縮アルゴリズムによって異なります。詳細については、圧縮アルゴリズムのドキュメントを確認してください。

注釈

15より前のPostgreSQLバージョンでは、 gzip は`backup_compression_level=0` をサポートしました。デフォルトの圧縮レベルを使用した結果

圧縮場所#

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 である場合、バックアップは圧縮されたtarボールとしてディスクに書き込まれます。 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
none	tar	tar	tar

同時バックアップ#

通常、バックアップ操作中に、 Barmanは_concurrentbackup_にPostgreSQLネイティブファンクションpg_start_backup およびpg_stop_backup を使用します。 [^ABOUT_CONCURRENT_BACKUP] これは、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データベース上のデータベースを指している必要があります。

重要

コンカレントバックアップの場合、現在Barmanは、フルバックアップの終了WALファイルが実際に出荷されたかどうかを判断できません。PostgreSQL自分自身がWALファイルが正しくアーカイブされていることを確認する排他的バックアップとは反対です。そのWALファイルがBarmanによって受信およびアーカイブされるまで、フルバックアップは一貫しているとは見なされないことに注意してください。 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 を設定することが特に重要です。

Barman 3.8.0現在、 primary_conninfo が設定されている場合、サーバーにprimary_checkpoint_timeout オプションを追加できます。これは、新しいWALファイルが生成されるのを強制的に実行する前にBarmanが待機する最大時間秒です。プライマリのチェックポイント。 primary_checkpoint_timeout オプションは、プライマリサーバーで設定されたarchive_timeout オプションの値より大きい秒数に設定する必要があります。

primary_conninfo が設定されていない場合、バックアップは引き続き実行されますが、プライマリの現在のWALセグメントがバックアップに必要な最新のWALよりも新しくなるまで、停止バックアップステージで待機します。

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

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時間365日の運用サービスの下で使用するために、 Barmanにローカルバックアップのサポートを追加することを要求しました。現在、この機能を使用するには、ソースからインストールするか、権限、ロギング、cron構成の点で`postgres` ユーザーの環境をカスタマイズする必要があります。

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

このアーキテクチャはEnterpriseDBによって承認されていません。 RPOとRTOの点でより良い結果を伴う、PostgreSQLのビジネス継続性エクスペリエンスを強化するために、EnterpriseDBは引き続き、レプリケーションと監視を目的とした監視ウィットネスサーバのように機能できるBarmanのリモートインストールを使用したシェアードナッシングアーキテクチャをお勧めします。

ローカルバックアップの唯一の要件は、 BarmanがPostgreSQLサーバーと同じユーザーで実行されることです。通常はpostgres です。 Communityパッケージはデフォルトで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圧縮#

構成ファイルで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ストリーミング#

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

このようなシナリオを構成するには、 Barmanサーバーは PostgreSQLストリーミング接続を介してWALをアーカイブするように構成し、 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バックアップ保持ポリシーの1つであり、 DBAが期間を指定し、 Barmanがポイントインタイムリカバリーに必要なバックアップおよび/またはアーカイブされたWALファイルのリカバリウィンドウ中の任意の時点での保持を保証します。間隔は常に現在の時刻で終了し、ユーザーが指定した日数だけ過去に戻ります。たとえば、リテンションポリシーが7日間のリカバリウィンドウに設定されており、現在時刻が金曜日の午前9時30分である場合、 Barmanは1日の午前9時30分にポイントインタイムリカバリーを可能にするために必要なバックアップを保持します。前の金曜日。

スコープ#

リテンションポリシーは以下に対して定義できます。

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 はサーバーの最小冗長レベル以上である必要がありますその値が割り当てられていない場合、警告が生成されます
- 最初の有効なバックアップは値番目のバックアップです逆順の時系列で
リカバリウィンドウポリシー
- の場合、復旧可能ポイントは次のとおりです。現在時間 - window
- 最初の有効なバックアップは、復旧可能ポイントの前の最初に使用可能なバックアップです。逆順の時系列の値はサーバーの最小冗長レベル以上である必要がありますその値に割り当てられず、警告が生成された場合

デフォルトでは、 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に失敗してメインオペレーションを中断するように要求できます。

フックスクリプトは次の順序で実行されます。

標準の’pre’フックスクリプト存在する場合
retry ’pre’フックスクリプト存在する場合
実際のイベントつまりバックアップオペレーションまたはWALアーカイブ、再試行’pre’フックスクリプトがABORT_STOP で中止されなかった場合
再試行 ’post’フックスクリプト存在する場合
標準の’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 バックアップを削除する前に実行されるretryフックスクリプト、成功または中止されるまで繰り返します
post_delete_retry_script バックアップの削除後に実行されるretryフックスクリプト、成功または中止されるまで繰り返します
post_delete_script バックアップの削除後に1回のみ起動されるフックスクリプト、終了コードはチェックされません

スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。再試行スクリプトの場合にのみ、 Barmanはリターンコードをチェックします上部のセクションを参照してください。

削除スクリプトは、バックアップスクリプトと同じ環境変数に加えて、以下を使用します。

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

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

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

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

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

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ファイルを削除する前に実行されるretryフックスクリプト、成功または中止されるまで繰り返します
post_wal_delete_retry_script WALファイルの削除後に実行されるretryフックスクリプト、成功または中止されるまで繰り返します
post_wal_delete_script WALファイルの削除後に実行されるフックスクリプト

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

リカバリスクリプト#

バージョン 2.4 では、リカバリー前後のスクリプトを導入しています。

以前のスクリプトと同様に、リカバリスクリプトはグローバル構成オプション内で構成でき、サーバーごとにオーバーライドすることが可能です。

pre_recovery_script バックアップのリカバリー前に1回のみ、終了コードのチェックなしで起動されるフックスクリプト
pre_recovery_retry_script バックアップのリカバリーの前に実行されるretryフックスクリプト、成功または中止まで繰り返します
post_recovery_retry_script バックアップのリカバリ後に実行されるretryフックスクリプト、成功または中止されるまで繰り返し
post_recovery_script バックアップのリカバリー後に1回だけ、終了コードのチェックなしで起動されるフックスクリプト

リカバリスクリプトは、バックアップスクリプトと同じ環境変数に加えて、以下を使用します。

BARMAN_DESTINATION_DIRECTORY 新しいインスタンスがリカバリされるディレクトリ
BARMAN_TABLESPACES テーブルスペース再配置マップJSON存在する場合
BARMAN_REMOTE_COMMAND リカバリーで使用されるsecure Shellコマンド存在する場合
BARMAN_RECOVER_OPTIONS リカバリー追加オプションJSON存在する場合

カスタマイズ#

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

Barmanでは、 barman_lock_directory グローバルオプションを介してロックファイルのディレクトリを指定できます。

ロックファイルは、グローバルおよびサーバーレベルで同時作業を調整するために使用されますたとえば、 cron操作、バックアップ操作、WALアーカイブへのアクセスなど。

デフォルトでは、下位互換性の理由から、barman_lock_directory はbarman_home に設定されます。

Tip

ユーザーは、実行時変数データ専用のディレクトリ、たとえば /var/run/barman などの揮発性パーティションのディレクトリを使用することをお勧めします。

バイナリパス#

バージョン1.6.0の時点で、 Barmanでは、global/serverオプション 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サーバーに適用できます。これらはクラスター環境を処理する場合に役立つため、たとえば、フェールオーバーイベントに応答してBarmanサーバーの構成を変更できます。

例として、次のノードを含むPostgreSQLクラスターがあるとします。

pg-node-1 プライマリ
pg-node-2 スタンバイ
pg-node-3 スタンバイ

プライマリノードからバックアップしており、次のオプションを含む構成があるとします。

[my-barman-server]
cluster = my-cluster
conninfo = host=pg-node-1 user=barman database=postgres
streaming_conninfo = host=pg-node-1 user=streaming_barman
; other options...

たとえば、次のようなそのクラスターの構成モデルを作成できます。

[my-barman-server:backup-from-pg-node-2]
cluster = my-cluster
model = true
conninfo = host=pg-node-2 user=barman database=postgres
streaming_conninfo = host=pg-node-2 user=streaming_barman

これは、次のコマンドでpg-node-1 からpg-node-2 へのフェイルオーバーに適用できるため、新しいプライマリノードからバックアップを開始します。

barman config-switch my-barman-server my-barman-server:backup-from-pg-node-2

これにより、クラスター構成オプションが選択したモデルで定義された値でオーバーライドされます。

注モデルからすべてのオプションを設定できるわけではありません。: section 5 of the 'man' page を参照して、モデルに適用されるスコープの設定を確認してください。

注 pg-backup-api をチェックすることに興味があるかもしれません。これは、REST APIをスタートし、 barman config-switch を含むbarman コマンドを実行するリモート要求をリッスンすることができます。

パラレルジョブ#

デフォルトでは、 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 に依存します。

パラレルジョブとsshd MaxStartups#

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

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

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

parallel_jobs_start_batch_size 単一のバッチで開始する並列ジョブの最大数。
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_コマンドを使用してマスターサーバーに接続し、リモートマシンにバックアップが存在する場合、rsyncを使用してすべてのファイルのコピーを開始します。バックアップごとに1つの同期プロセスのみが許可されます。

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

barman sync-wals <server_name>

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

スナップショットバックアップは、クラウドストレージボリュームの1つ以上のスナップショットで構成されるバックアップです。

次のいずれかのコマンドを使用して、 suitable PostgreSQL server のスナップショットバックアップを取得できます。

BarmanサーバーがWALの保存とメタデータのバックアップに使用されている場合、 barman backup と required configuration operations for snapshots 。
Barmanサーバーがなく、代わりにクラウドオブジェクトストアがWALとバックアップメタデータに使用されている場合、必須の command line arguments を備えたbarman-cloud-backup 。

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

スナップショットバックアップを取得する高レベルのプロセスは次のとおりです。

Barmanは一連のプリフライトチェックを実行して、スナップショットオプション、インスタンス、ディスクを検証します。
Barmanは、 PostgreSQL backup API を使用してバックアップを開始します。
クラウドプロバイダーAPIを使用して、指定された各ディスクのスナップショットをトリガーします。 Barmanは、次のディスクに移動する前に、アプリケーションの一貫性を保証するためにスナップショットが必要な状態に到達するまで待機します。
各ディスクのデバイス名などの追加のプロバイダー固有データは、バックアップメタデータに保存されます。
各ディスクのマウントポイントとマウントオプションは、バックアップメタデータに保存されます。
Barmanは、PostgreSQLバックアップAPIを使用してバックアップを停止します。

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

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

snapshot_instance およびプロバイダ固有の引数で指定されたコンピューティングインスタンスが存在します。

・ 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 for スナップショットコマンドを使用する必要があります。

スナップショットバックアップからのリカバリーは、次の手順で構成されます。

バックアップ中に作成されたスナップショットごとに、新しいディスクをプロビジョニングします。
手順1でプロビジョニングされた各ディスクがバックアップメタデータに従って接続およびマウントされるコンピューティングインスタンスをプロビジョニングします。
barman recover または barman-cloud-restore for スナップショットコマンドを使用して、リカバリーを検証およびファイナライズします。

ステップ1および2は、既存のインフラストラクチャアズコードシステムで最適に処理されますが、これらの手順を手動でまたはカスタムスクリプトを使用して実行することもできます。

これらの手順を実行する際には、次のリソースが役立つ場合があります。

例 recovery script for GCP 。
例 runbook for Azure 。

上記のリソースは、バックアップ/リカバリー環境に関する仮定を立てているため、さらにカスタマイズせずに本番使用に適していると考えられるべきではありません。

リカバリインスタンスがプロビジョニングされ、バックアップスナップショットからクローンされたディスクが接続およびマウントされたら、次の追加引数を使用してbarman recover を実行します。

--remote-ssh-command リカバリインスタンスにログインするために必要なsshコマンド。
--snapshot-recovery-instance クラウドプロバイダーの必要なリカバリインスタンスの名前。
スナップショットプロバイダーに固有の追加引数。

例

barman recover SERVER_NAME BACKUP_ID REMOTE_RECOVERY_DIRECTORY \
    --remote-ssh-command ssh USER@HOST \
    --snapshot-recovery-instance INSTANCE_NAME

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

gcp プロバイダーでは、次の追加のbarman recover 引数を使用できます。

--gcp-zone リカバリインスタンスが存在するアベイラビリティーゾーンの名前。提供されない場合、 Barmanはサーバー構成で設定されたgcp_zone の値を使用します。

azure プロバイダーでは、次の追加のbarman recover 引数を使用できます。

--azure-resource-group リカバリインスタンスが属するリソースグループ。提供されない場合、 Barmanはサーバー構成で設定されたazure_resource_group の値を使用します。

aws プロバイダーでは、次の追加のbarman recover 引数を使用できます。

--aws-region リカバリインスタンスが存在するAWSリージョン。提供されない場合、 Barmanはサーバー構成で設定されたaws_region の値を使用します。

スナップショットバックアップを復旧する場合、次のbarman recover 引数/config変数は使用できないことに注意してください。

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

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

リカバリディスクとインスタンスがインフラストラクチャアズコード、アドホック自動化、または手動でプロビジョニングされるかどうかにかかわらず、 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 コマンドがあります。

snapshots_info/provider_info およびsnapshots_info/snapshots/*/provider で使用可能なメタデータは、以降のセクションで説明するように、クラウドプロバイダーによって異なります。

GCPプロバイダー固有のメタデータ#

snapshots_info/provider_info では、次のフィールドが使用できます。

project バックアップとリカバリーに関係するリソースを所有するプロジェクトのGCPプロジェクトID。

snapshots_info/snapshots/*/provider では、次のフィールドが使用できます。

device_name スナップショットのソースディスクがバックアップ時にバックアップVMに接続された短いデバイス名。
snapshot_name スナップショットの名前。
snapshot_project スナップショットを所有するGCPプロジェクトID。

Azureプロバイダー固有のメタデータ#

snapshots_info/provider_info では、次のフィールドが使用できます。

subscription_id バックアップとリカバリーに関係するリソースを所有するAzureサブスクリプションID。
resource_group バックアップに関係するリソースが属するAzureリソースグループ。

snapshots_info/snapshots/*/provider では、次のフィールドが使用できます。

location スナップショットが取得されたディスクのAzureの場所。
lun バックアップ時にスナップショットが取得されたディスクを識別するLUN。
snapshot_name スナップショットの名前。

AWSプロバイダー固有のメタデータ#

snapshots_info/provider_info では、次のフィールドが使用できます。

account_id バックアップの作成に使用されたリソースを所有するAWSアカウントのID。
region バックアップに関係するリソースが存在するAWSリージョン。

snapshots_info/snapshots/*/provider では、次のフィールドが使用できます。

device_name バックアップ時にバックアップVMでソースディスクがマッピングされたデバイス。
snapshot_id AWSによって割り当てられたスナップショットのID。
snapshot_name スナップショットの名前。

Features in detail

目次

Features in detail#

バックアップ機能#

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

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

ネットワーク圧縮#

バックアップ圧縮#

圧縮アルゴリズム#

圧縮ワーカー#

圧縮レベル#

圧縮場所#

圧縮形式#

同時バックアップ#

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

即時チェックポイント#

ローカルバックアップ#

アーカイブ機能#

WAL圧縮#

同期WALストリーミング#

カタログ管理機能#

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

リテンションポリシー#

スコープ#

仕組み#

構成と構文#

retention_policy の構文#

wal_retention_policy の構文#

フックスクリプト#

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

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

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

WAL削除スクリプト#

リカバリスクリプト#

カスタマイズ#

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

バイナリパス#

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

構成モデル#

パラレルジョブ#

パラレルジョブとsshd MaxStartups#

地理的な冗長性#

情報の同期#

構成#

ノードの同期#

手動同期#

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

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

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

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

GCPプロバイダー固有のメタデータ#

Azureプロバイダー固有のメタデータ#

AWSプロバイダー固有のメタデータ#

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

`retention_policy` の構文#

`wal_retention_policy` の構文#