バックアップ#

概要#

backupコマンドは、構成ファイルパラメーターに従って、Postgresサーバー全体をバックアップするために使用されます。それを使用するには、次を実行します。

barman backup [OPTIONS] SERVER_NAME

注釈

backupコマンドの詳細については、 backup コマンドリファレンスを参照してください。

重要

Barmanとの相互作用が予定されている場合、サーバーが正しく構成されていることを確認する必要があります。バックアップを作成する前にカバーする必要がある手順については、 Quickstart および Quickstart セクションを参照してください。

警告

WALファイルが archiver または streaming_archiver オプションを介してBarmanに正しくアーカイブされていない場合、バックアップの開始は失敗します。

Barmanは、Postgresサーバーの複数のバックアップ方法を提供しており、それぞれに独自のアプローチと要件があります。

バージョン2.0より前のバージョンでは、 Barmanは標準バックアップとファイルレベルのインクリメンタルバックアップの両方をrsyncにのみ依存していました。ストリーミングバックアップはこのバージョンで導入されました。バージョン3.11以降、 Barmanは、ストリーミング接続を介したブロックレベルのインクリメンタルバックアップもサポートします。

重要

Postgres 15以降では、 exclusive バックアップはサポートされなくなりました。バックアップを取る唯一の方法は、 concurrent バックアップを使用することです。 backup_options が設定されていない場合、 Barmanは自動的に concurrent_backup に設定します。

バックアップの要件#

Barmanサーバーの最も重要な要件は、利用可能なディスク領域の量です。バックアップするクラスターのサイズ、1日あたり生成されるWALファイルの数、バックアップの頻度、および保持ポリシーに基づいて、必要なディスク領域を計画することをお勧めします。

Barman開発者は、XFSおよびext4ファイルシステムを使用してBarmanを定期的にテストします。 PostgreSQLと同様に、 Barmanは、バックアップとWALの保存に使用されるNFSマウントポイントに対して特別なことは何もしません。 NFSでBarmanを安全に使用するには、次の点が必要です。

barman_lock_directory はローカルファイルシステム上にある必要があります。

少なくともNFSプロトコルバージョン4を使用してください。

ファイルシステムは、ハードおよび同期オプション hard 、 sync を使用してマウントする必要があります。

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

インクリメンタルバックアップには、既存のバックアップを参照として使用し、Postgresサーバーでの最後のバックアップ以降に発生したデータ変更のみをコピーすることが含まれます。

Barmanでのインクリメンタルバックアップの主な目的は次のとおりです。

完全なバックアッププロセスの時間を短縮します。
定期的なバックアップデータの重複排除にわたって冗長データを削除することにより、ディスク領域の使用量を削減します。

Barmanは、2種類のインクリメンタルバックアップをサポートしています。

ファイルレベルのインクリメンタルバックアップ rsync を使用
ブロックレベルのインクリメンタルバックアップPostgres 17で pg_basebackup を使用

注釈

異なる種類のインクリメンタルバックアップには、相互互換性がありません。たとえば、 rsyncバックアップに加えてブロックレベルのインクリメンタルバックアップを取得することはできません。また、 pg_basebackup で作成されたストリーミングバックアップに基づいてファイルレベルのインクリメンタルバックアップを取得することはできません。

帯域幅使用量の管理#

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

特定の表領域のI/Oワークロードを管理する必要がある場合は、 tablespace_bandwidth_limit オプショングローバルまたはサーバーごとを使用して、個々の表領域の制限を設定します。

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

このオプションは、テーブルスペース名と帯域幅制限のペア1秒あたりのキロバイト単位のコンマ区切りリストを取得します。

サーバーをバックアップするときに、 Barmanはこのオプションにリストされているテーブルスペースをチェックします。一致するテーブルスペースが見つかった場合、指定された帯域幅制限が適用されます。一致するものが見つからない場合、サーバーのデフォルトの帯域幅制限が使用されます。

重要

bandwidth_limit オプションは、 rsync および postgres バックアップ方法で使用できますが、 tablespace_bandwidth_limit オプションは rsync を使用する場合にのみ適用されます。

ネットワーク圧縮#

ネットワーク圧縮を使用することにより、ネットワーク上で転送されるデータのサイズを削減できます。これは、 network_compression オプショングローバルまたはサーバーごとを使用して有効にできます。

network_compression = true | false

重要

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

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

バックアップ圧縮#

Barmanは、 pg_basebackup ツールを使用したバックアップ圧縮をサポートしています。この機能は、 backup_compression オプショングローバルまたはサーバーごとを使用して有効にできます。

重要

backup_compression オプションは、ここで説明する他のオプションと同様に、 postgres バックアップ方法でのみ使用できます。

圧縮アルゴリズム#

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

backup_compression = gzip | lz4 | zstd | none

Barman、選択した圧縮アルゴリズムに対応するCLIユーティリティをBarmanサーバーとPostgresサーバーの両方にインストールする必要があります。これらのユーティリティは、Debian、Ubuntu、RedHat、CentOS、およびSLESシステムに gzip 、 lz4 、および zstd という名前のシステムパッケージを介してインストールできます。

Ubuntu 18.04 bionicでは、 lz4 ユーティリティは liblz4-tool パッケージで利用できます。
lz4 および zstd は、Postgres 15以降でサポートされています。

重要

backup_compression を使用する場合、 staging_path および staging_location を設定して圧縮バックアップのリカバリーを有効にする必要があります。詳細については、 backup_compression セクションを参照してください。

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

backup_compression_workers オプションデフォルトは 0 を設定することにより、マルチプルのスレッドを使用して圧縮を高速化できます。

backup_compression_workers = 2

注釈

このオプションは、 zstd 圧縮でのみ使用できます。 zstd バージョンは1.5.0以上、またはマルチスレッドが有効になっている場合は1.4.4以上である必要があります。

圧縮レベル#

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

none 圧縮の場合、 backup_compression_level を 0 に設定する必要があります。
使用可能なレベルとデフォルト値は、選択した圧縮アルゴリズムによって異なります。詳細については、 backup configuration options セクションを確認してください。
15より前のPostgresバージョンの場合、 gzip は、デフォルトの圧縮レベルを使用する backup_compression_level = 0 のみをサポートしています。

圧縮場所#

Postgres 15以降では、圧縮を発生する場所 server または client で選択できます。 backup_compression_location オプションを設定します。

backup_compression_location = server | client

server 圧縮はPostgresサーバーで発生し、ネットワーク帯域幅は削減されますが、サーバーのワークロードが増加します。
client 圧縮はクライアントサイドで pg_basebackup によって処理されます。

backup_compression_format を使用してバックアップ形式を指定することもできます。

backup_compression_format = plain | tar

plain pg_basebackup は、ディスクに書き込む前にデータを解凍します。
tar バックアップは圧縮されたtarボールとして書き込まれますデフォルト。

注釈

backup_compression_location = server および backup_compression_format = plain を設定すると、ファイルがサーバー側で圧縮され、クライアント側で解凍されることを考慮して、ネットワーク使用量を削減できます。これは、ネットワーク帯域幅は制限されているがCPUは制限されておらず、バックアップを非圧縮で保存する必要がある場合に役立ちます。

選択した backup_compression および backup_compression_format によっては、PostgresサーバーとBarmanサーバーの両方に追加ツールをインストールする必要がある場合があります。

以下の表を参照して、構成に適切なツールを選択します。

backup_compression	backup_compression_format	Postgres	Barman
gzip	プレーン	タール	なし
gzip	タール	タール	タール
lz4	プレーン	tar、lz4	なし
lz4	タール	tar、lz4	tar、lz4
zstd	プレーン	tar、zstd	なし
zstd	タール	tar、zstd	tar、zstd
なし	タール	タール	タール

バックアップの暗号化#

Barmanは、バックアップとWALファイルの両方の暗号化をサポートしています。この機能は、 encryption オプショングローバルまたはサーバーごとを使用して有効にできます。

要件#

バックアップの現在の暗号化実装は、 tar形式でバックアップを取得する pg_basebackup 機能に依存しています。これを行うには、次のように構成を設定する必要があります。

backup_method = postgres
backup_compression = <compression_method> 圧縮なしの場合は none
backup_compression_format = tar

バックアップされたtarファイルは、 pg_basebackup がBarmanサーバーディスクへの書き込みを終了するとすぐに暗号化されます。

暗号化方法#

encryption オプションの設定は、ベースバックアップとWALに使用される暗号化方法を指定します。現在、 gpg および none 暗号化なしのみが受け入れられる値です。

注釈

WAL暗号化の詳細については、 WAL暗号化を参照してください。

注釈

復号の詳細については、暗号化されたバックアップの復元を参照してください。

GPG#

この方法は、構成ファイルで encryption = gpg を設定することにより有効にされます。

暗号化に`GPG`を使用するには、サーバーに gpg バージョン2.1以降をインストールする必要があります。また、事前にGPGキーペアを生成し、生成された公開キーのIDまたは受信者のメールアドレスで encryption_key_id オプションを構成する必要があります。対応するプライベートキーはGPGのキーリングに存在し、強力なパスフレーズで保護されている必要があります。

即時チェックポイント#

バックアップを開始する前に、 Barmanはチェックポイントを要求します。これは、追加のワークロードを生成する可能性があります。デフォルトでは、このチェックポイントはPostgresのワークロード制御設定に従って管理され、バックアップが遅延する場合があります。

immediate_checkpoint 構成オプションデフォルトは false を使用して、このデフォルトの動作を変更できます。

immediate_checkpoint が true に設定されている場合、Postgresはスロットルなしで最大速度でチェックポイントを実行し、できるだけ早くバックアップを開始できます。 barman backup コマンドで次のオプションのいずれかを使用することにより、いつでもこの構成をオーバーライドできます。

--immediate-checkpoint 即時チェックポイントを強制します。
--no-immediate-checkpoint バックアップを開始する前にチェックポイントが完了するのを待機します。

ストリーミングバックアップ#

Barmanは、 pg_basebackup とのストリーミング接続を使用してPostgresサーバーのバックアップを実行できます。

重要

pg_basebackup はBarmanサーバーにインストールする必要があります。下位互換性があるため、 pg_basebackup の最新バージョンを使用することをお勧めします。構成ファイルの path_prefix オプションを使用して、複数のバージョンをインストールし、指定できます。

ストリーミングバックアップを構成するには、 backup_method を postgres に設定します。

backup_method = postgres

ブロックレベルのインクリメンタルバックアップ#

このタイプのバックアップは、Postgres 17で導入されたネイティブのインクリメンタルバックアップ機能を使用します。

ブロックレベルのインクリメンタルバックアップは、Postgresのページレベルでデータを重複排除します。これは、最後のバックアップ以降に変更されたページのみを保存する必要があることを意味し、特に頻繁に書き込みを行う大規模なデータベースの場合、より効率的です。

Barmanでブロックレベルのインクリメンタルバックアップを実行するには、backupコマンドで --incremental オプションを使用します。重複排除のために backup_method=postgres で作成された以前のバックアップ完全またはインクリメンタルを参照するバックアップIDまたはショートカットを提供する必要があります。または、 last-full または latest-full を使用して、カタログ内の最新の適格なフルバックアップを参照できます。

コマンドの例

barman backup --incremental BACKUP_ID SERVER_NAME

Barmanでブロックレベルのインクリメンタルバックアップを使用するには、次のことを行う必要があります。

Postgres 17以降を使用してください。
この機能はWAL要約に依存しているため、最初の完全バックアップを取得する前にデータベースサーバーで summarize_wal を有効にする必要があります。
backup_method=postgres を使用します。

注釈

圧縮バックアップは、現在Barmanのブロックレベルのインクリメンタルバックアップではサポートされていません。

重要

ブロックレベルのインクリメンタルバックアップの間で data_checksums を有効にする場合、新しい完全バックアップを取ることをお勧めします。発散チェックサム構成は、リカバリ中に問題を発生させる可能性があります。

SSHを介したRsyncを使用したバックアップ#

Barmanは、トランスポートメカニズムとしてSSHを使用するRsyncを使用してPostgresサーバーのバックアップを実行できます。

rsyncを使用してバックアップを構成するには、 Barmanサーバー構成ファイルに次のパラメーターを含めます。

backup_method = rsync
ssh_command = ssh postgres@pg

ここで、 backup_method はrsyncバックアップ方法をアクティブにし、 ssh_command はBarmanサーバーからPostgresサーバーへのSSH接続の詳細を指定します。

注釈

Barman 3.11以降、rsyncベースのバックアップにキープアライブメカニズムが使用されます。このメカニズムは、libpq接続を介して単純な SELECT 1 クエリーを送信して、アイドル接続によるファイアウォールまたはルーターの切断を防ぎます。 keepalive_interval 構成オプションを使用して、このメカニズムを制御または無効にできます。

ファイルレベルのインクリメンタルバックアップ#

ファイルレベルのインクリメンタルバックアップはrsyncまたはハードリンクに依存するため、オペレーティングシステムとバックアップデータが保存されるファイルシステムの両方がこれらの機能をサポートする必要があります。

基本的なアイデアは、後続のベースバックアップ中に、最後のバックアップから変更されていないファイルが共有され、ディスク領域を節約するということです。これは、 :term:`VLDB`および読み取り専用の履歴テーブルの割合が高い場合に特に役立ちます。

Barmanコマンドを管理する reuse_backup と呼ばれるグローバル/サーバーオプションを介してrsyncインクリメンタルバックアップを有効にできます。 3つの値を受け入れます。

off 標準のフルバックアップデフォルト。
link 最後のバックアップを再利用し、変更されていないファイルのハードリンクを作成するファイルレベルのインクリメンタルバックアップ、バックアップ領域と時間の両方を削減します。
copy 最後のバックアップを再利用し、変更されていないファイルのコピーを作成するファイルレベルのインクリメンタルバックアップ。バックアップ時間は削減されますが、領域は削減されません。

通常、次のように reuse_backup を link に設定します。

reuse_backup = link

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

Barmanコマンドの実行時に、 --reuse-backup ランタイムオプションでこの設定をオーバーライドできます。たとえば、1回限りのインクリメンタルバックアップを実行するには、次を使用します。

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

注釈

ブロックレベルのインクリメンタルバックアップとは異なり、rsyncファイルレベルのインクリメンタルバックアップは自己完結型です。親バックアップが削除されても、他のバックアップの整合性は影響を受けません。 rsyncバックアップの重複排除はハードリンクを使用します。つまり、再利用されたバックアップが削除されるときに、新しい完全バックアップを作成する必要はありません。共有ファイルは、これらのファイルを使用した最後のバックアップも削除されるまでディスクに残ります。さらに、初期バックアップに reuse_backup = link または reuse_backup = copy を使用しても、リンクまたはコピーする既存のファイルが存在しないため完全バックアップとして扱われるため、効果はありません。

ローカルでRsyncを使用したバックアップ#

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

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

ローカルバックアップの唯一の要件は、 BarmanがPostgresサーバーと同じユーザー、通常は postgres で実行されることです。コミュニティパッケージはデフォルトでBarmanを barman ユーザーの下にインストールすることを考えると、このユースケースでは以下を含む手動インストール手順が必要です。

cron構成
ログ構成logrotateを含む

ヒント

barman.conf ファイルの barman_user オプションを使用して、 Barmanに別のユーザーを設定します。権限の問題を回避するには、新しいユーザーがアクセスできるパスに応じて、ホーム、ログ、およびロックディレクトリを変更することを忘れないでください。詳細については、 barman_user を参照してください。

Barmanで特定のサーバーのローカルバックアップを使用するには、 backup_method を local-rsync に設定する必要があります。この機能は本質的に同等の rsync と同じであり、代わりにSSHに依存し、リモートで動作します。 local-rsync では、ファイルコピーはローカルでrsyncコマンドを発行して実行されますこのため、 BarmanはPostgresと同じユーザーで実行する必要があります。

スタンバイのコンカレントバックアップ#

スタンバイサーバーからバックアップを実行する場合、次の構成オプションがスタンバイをポイントするように設定されていることを確認します。

conninfo
streaming_conninfo backup_method = postgres または streaming_archiver = on を使用する場合
ssh_command backup_method = rsync を使用する場合
wal_conninfo conninfo がスタンバイを指している場合、プライマリに接続します

primary_conninfo オプションは、プライマリサーバーを指す必要があります。 Barmanは primary_conninfo を使用して、プライマリで新しいWALスイッチをトリガーし、自然なWALスイッチを待たずにスタンバイからのコンカレントバックアップを完了できます。

注釈

プライマリでの書き込みアクティビティが最小限または全くない期間にスタンバイをバックアップする場合、 primary_conninfo を構成することが重要です。

Barman 3.8.0以降では、 primary_conninfo が構成されている場合、 primary_checkpoint_timeout オプションを設定することもできます。これは、 Barmanがプライマリにチェックポイントを強制するまでの、新しいWALファイルの最大待機時間秒単位を指定します。このタイムアウトは、プライマリに設定された archive_timeout 値を超える必要があります。

primary_conninfo が設定されていない場合、バックアップは続行されますが、最後にアーカイブされたWALセグメントがバックアップに必要な最新のWALより新しくなるまで、stopbackupステージで一時停止します。

Barmanでは、WALファイルとバックアップデータが同じPostgresクラスターから発生する必要があります。スタンバイがプライマリに昇格しても、既存のバックアップとWALは有効なままです。ただし、 Barman構成を更新して、今後のバックアップとWALの取得に新しいスタンバイを使用する必要があります。

注釈

Postgresクラスターでフェールオーバーが発生した場合、 Configuration Models でBarman構成を更新できます。

WALは、WALストリーミングまたはWALアーカイブを介してスタンバイから取得できます。詳細については、 concepts セクションを参照してください。 WALストリーミングまたはWALアーカイブでの作業を開始する場合は、 concepts または concepts のクイックスタートセクションを参照してください。

注釈

Postgres 10以前の場合、 Barmanはスタンバイで同時のWALストリーミングとアーカイブを処理できません。 Postgres 10以前のWALはバイナリレベルで異なる場合があり、 Barmanでの誤検出問題が発生する可能性があるため、他方を使用している場合は一方を無効にする必要があります。

外部構成ファイルの管理#

Barmanは、使用されるバックアップ方法に応じて、外部構成ファイル<外部構成ファイル>`を異なる方法で処理します。 ``rsync` メソッドでは、外部ファイルはPGDATAディレクトリにコピーされます。ただし、 postgres メソッドでは、外部ファイルはコピーされず、警告が発行されてこれらのファイルについてユーザーに通知します。

リカバリーの章の Managing external configuration files セクションを参照して、バックアップを復元するときに外部ファイルがどのように処理されるかを理解します。

ヒント

backup_method = postgres の場合、 BarmanはPostgreSQLホストへのSSH接続を確立しないため、バックアップ後フックを構成し、 barman show-server コマンドの出力を使用して、バックアップが完了した直後に外部構成ファイルを自分でバックアップすることができます。

バックアップに不変ストレージを使用する#

Barmanは、不変ストレージにバックアップを保存するように構成して、悪意のあるアクターまたは誤った削除から保護できます。このようなストレージは、`WORM`Write Once Read Manyストレージと呼ばれることもあります。

このタイプのストレージの主な使用例は、ランサムウェア攻撃からバックアップを保護することです。不変のストレージを使用することにより、特定の期間バックアップを削除または変更できません。

Barmanが不変のバックアップを提供するには、バックアップとWALファイルのみを不変ストレージに配置し、復元不可能なデータを通常のストレージに残す必要があります。この方法により、 Barmanは、バックアップとWALファイルのメタデータに関する一時的な情報を維持できます。その情報は定期的な更新が必要です。

上記を踏まえて、不変のストレージにバックアップを保存するようにBarmanを構成するには、次の提案に従う必要があります。

次の2つのディレクトリのみが不変のストレージパスに保存されるように構成する必要があります。
- basebackups_directory バックアップが保存されるディレクトリ。
- wal_directory WALファイルが保存されるディレクトリ。
他のすべてのディレクトリは、Barmanの内部プロセスによって使用され、クラスターの復元に重要なデータを保持しないため、通常のストレージパスに保存する必要があります。これは、グローバル構成で通常のストレージをポイントするように barman_home オプションを構成するか、サーバーセクションで barman_home オプションを構成することにより実現できます。これには、以前の箇条書きのオプションをそれに応じて設定する必要があります。
WALファイルカタログは、通常のストレージパスに保存する必要があります。これは、通常のストレージをポイントするように xlogdb_directory オプションを構成することにより実現できます。
staging_path および staging_location オプション詳細については staging_path を参照してください。インクリメンタルまたは圧縮または暗号化されたバックアップの復元に使用されるパスも、通常のストレージに存在する必要があります。
保持ポリシーは、少なくともバックアップファイルが不変である完全な期間をカバーする必要があります。これは、serverセクションの retention_policy オプションを不変ストレージの不変期間よりも大きい値に設定することにより実現できます。これは、不変期間が終了する前にバックアップが削除されないようにするためです。

バックアップの不変性を構成するには、有効にする必要がある worm_mode オプションがあります。これにより、 Barmanは、バックアップとWALファイルが`WORM`環境に保存されている場合に問題のあるプロセスをスキップできます。

注釈

xlogdb ファイルを再配置するオプションはBarman 3.12に含まれていました。詳細については、 xlogdb を参照してください。

電流制限#

Barmanの不変バックアップサポートの現在の実装には、次の制限があります。

WORM環境には猶予期間が必要です。猶予期間は、WORM制限が有効になる前にデータを変更または削除できる事前定義されたウィンドウを提供します。この要件は、 Barmanが名前の変更を利用してWALを外部パーティションに安全にコピーするため、ファイルが既にWORM状態に入っている場合、これは失敗するために存在します。

一般に、Barmanが必要な操作を完了するための十分な時間を提供するため、少なくとも15分の猶予期間をお勧めします。

注釈

バックアップの暗号化も有効になっている場合、猶予期間は暗号化の実行に必要な時間をカバーするのに十分な長さである必要があります特にバックアップにテーブルスペースが含まれ、複数のtarボールが生成される場合。

これは、暗号化がバックアッププロセスの最後にのみ発生するため、 pg_basebackup が完了した後です。暗号化はインプレースで実行できないため、各tarファイルは個別に暗号化され、完了すると非暗号化バージョンが削除されます。

これらの制約を考慮すると、ユーザーは不変のバックアップサポートを有効にする前に、現在の実装が要件を満たしているかどうかを評価する必要があります。

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

Barmanは、ストレージボリュームのスナップショットを利用して、特定のクラウド環境に展開されたPostgresサーバーのバックアップを実行できます。この設定では、 Postgresファイルのバックアップはクラウドに保存されているボリュームスナップショットとして表され、 Barmanは書き込み先行ログWALとバックアップカタログのストレージサーバーとして機能します。バックアップデータはクラウドに保存されているにもかかわらず、 Barmanは、 rsync または postgres バックアップ方法で作成された従来のバックアップと同様にこれらのバックアップを管理します。

注釈

さらに、 Postgresサーバーで barman-cloud-backup コマンドを直接使用することにより、 Barmanサーバーを使用せずにスナップショットバックアップを作成できます。このオプションを適切に使用する方法の詳細については、 barman-cloud-backup セクションを参照してください。

重要

backup_method=snapshot を使用する場合、次の構成オプションと同等のコマンド引数該当する場合は使用できません。

backup_compression
bandwidth_limit --bwlimit
parallel_jobs --jobs
network_compression
reuse_backup --reuse-backup

スナップショットを使用してバックアップを構成するには、 Barmanサーバー構成ファイルに次のパラメーターを含めます。

backup_method = snapshot
snapshot_provider = CLOUD_PROVIDER
snapshot_instance = INSTANCE_NAME
snapshot_disks = DISK_NAME1,DISK_NAME2

重要

snapshot_disks に、Postgresデータを保存するすべてのディスクが含まれていることを確認します。リストされていないディスクに保存されているデータはバックアップされず、リカバリ中に使用できません。

要件と構成#

Barmanでスナップショットバックアップ方法を使用するには、展開が次の要件を満たしている必要があります。

Postgresは、サポートされているクラウドプロバイダーが提供するコンピューティングインスタンスで実行されている必要があります。
PGDATAやテーブルスペースデータを含むすべての重要なデータは、スナップショットをサポートするストレージボリュームに保存する必要があります。
findmnt コマンドは、Postgresホストで使用できる必要があります。

重要

PGDATA の外部に保存された構成ファイルは、スナップショットに含まれません。構成管理システムまたはその他のメカニズムを使用して、これらのファイルを個別に管理する必要があります。

Google Cloud Platform#

Barmanで`GCP`のスナップショットバックアップを使用するには、以下を確認してください。

Python Libraries

Barmanが使用するPythonディストリビューションの google-cloud-compute および grpcio ライブラリをインストールします。これらのライブラリはオプショナルであり、デフォルトでは含まれません。

pipを使用してインストールします。

pip3 install grpcio google-cloud-compute

注釈

google-cloud-compute ライブラリには、Python 3.7以降が必要です。 GCPスナップショットは、以前のPythonバージョンと互換性がありません。

Disk Requirements

snapshot バックアップで使用されるディスクは、ゾーン永続ディスクである必要があります。現時点では、リージョン永続ディスクはサポートされていません。

Access Control

Barmanには、特定の権限を持つサービスアカウントが必要です。このアカウントをBarmanを実行しているコンピューティングインスタンスに接続するか、 GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して資格情報ファイルを指定できます。

重要

サービスアカウントに以下にリストされている権限があることを確認します。

compute.disks.createSnapshot
compute.disks.get
compute.globalOperations.get
compute.instances.get
compute.snapshots.create
compute.snapshots.delete
compute.snapshots.list

For provider specific credentials configurations, refer to the Google authentication methods and service account impersonation.

Specific Configuration

フィールド gcp_project および gcp_zone は、GCPに固有の構成オプションです。

gcp_project = GCP_PROJECT_ID
gcp_zone = ZONE

Microsoft Azure#

Barmanを使用してAzureでスナップショットバックアップを使用するには、以下を確認します。

Python Libraries

azure-mgmt-compute および azure-identity ライブラリは、 Barmanが使用するPythonディストリビューションで利用できる必要があります。これらのライブラリはオプショナルであり、デフォルトでは含まれません。

pipを使用してインストールします。

pip3 install azure-mgmt-compute azure-identity

注釈

azure-mgmt-compute ライブラリには、Python 3.7以降が必要です。 Azureスナップショットは、以前のPythonバージョンと互換性がありません。

Disk Requirements

スナップショットバックアップに関係するすべてのディスクは、データディスクとしてVMインスタンスに接続されている管理ディスクである必要があります。

Access Control

Barmanは、マネージドIDまたはCLIログインを介して取得した資格情報を使用してAzureにアクセスする必要があります。

次の環境変数がサポートされています。 AZURE_STORAGE_CONNECTION_STRING 、 AZURE_STORAGE_KEY および AZURE_STORAGE_SAS_TOKEN 。 Azure Active Directoryを介して認証するために、 --credential オプションを使用して、 default 、 azure-cli または managed-identity 資格情報を指定することもできます。

重要

資格情報に以下にリストされている権限があることを確認します。

Microsoft.Compute/disks/read
Microsoft.Compute/virtualMachines/read
Microsoft.Compute/snapshots/read
Microsoft.Compute/snapshots/write
Microsoft.Compute/snapshots/delete

For provider specific credential configurations, refer to the Azure environment variables configurations, Identity Package and DefaultAzureCredential documentation.

Specific Configuration

フィールド azure_subscription_id および azure_resource_group は、Azureに固有の構成オプションです。

azure_subscription_id = AZURE_SUBSCRIPTION_ID
azure_resource_group = AZURE_RESOURCE_GROUP

アマゾンウェブサービス#

Barmanで`AWS`のスナップショットバックアップを使用するには、以下を確認してください。

Python Libraries

boto3 ライブラリは、 Barmanが使用するPythonディストリビューションで利用できる必要があります。このライブラリはオプショナルであり、デフォルトでは含まれません。

pipを使用してインストールします。

pip3 install boto3

Disk Requirements

スナップショットバックアップに関係するすべてのディスクは、同じVMインスタンスに接続されている非ルートEBSボリュームである必要があります。

Access Control

BarmanはAWSにアクセスする必要があるため、postgresユーザーとして awscli ツールを使用してAWS資格情報を構成する必要があります、AWSコンソールのIAMセクションで事前に作成する必要があるアクセスキーとシークレットキーを入力します。

重要

以下にリストされている権限があることを確認します。

ec2:CreateSnapshot
ec2:CreateTags
ec2:DeleteSnapshot
ec2:DescribeSnapshots
ec2:DescribeInstances
ec2:DescribeVolumes

プロバイダー固有の資格情報構成については、 AWS boto3 configurations を参照してください。

Specific Configuration

フィールド aws_region 、 aws_profile 、および aws_await_snapshots_timeout は、AWSに固有の構成オプションです。

aws_profile は、資格情報ファイルのAWSプロファイルの名前です。使用しない場合、デフォルトのプロファイルが適用されます。資格情報ファイルが存在しない場合、資格情報は環境から取得されます。

aws_region は、AWSプロファイルで定義されたリージョンをオーバーライドします。

aws_await_snapshots_timeout は、スナップショットが作成されるのを待機するタイムアウトです。デフォルトは 3600 秒です。

snapshot_instance または snapshot_disks を指定すると、 Barmanはインスタンス/ボリュームIDまたはリソースの名前を受け入れます。名前を使用する場合、 BarmanはAWSに照会して、一致する Name タグを持つリソースを照会します。 0または複数の一致が見つかった場合、 Barmanはエラーを結果ます。

aws_region = AWS_REGION
aws_profile = AWS_PROFILE_NAME
aws_await_snapshots_timeout = TIMEOUT_IN_SECONDS

Ransomware Protection

ランサムウェア保護は、データを保護し、動作の安定性を維持するために不可欠です。 Amazon EBS Snapshot Lockを使用すると、スナップショットが削除から保護され、ランサムウェア攻撃から保護する不変のバックアップを提供します。スナップショットをロックすることにより、不要な削除が防止され、侵害された場合に信頼できる復旧オプションが保証されます。 Barmanは、バックアップの作成時にスナップショットをロックすることにより、バックアップの不要な削除を防ぐことができます。

注釈

ロックされたバックアップを削除するには、最初にAWSコンソールでロックを手動で削除する必要があります。

バックアップの作成中にスナップショットをロックするには、次のオプションを構成する必要があります。

スナップショットロックモード compliance または governance のいずれかを選択します。
ロック期間または有効期限のいずれかを設定します両方ではありません。ロックの期間は1〜36,500の範囲で日単位で指定されます。有効期限を選択する場合、 YYYY-MM-DDTHH:MM:SS.sssZ 形式を使用して、スナップショット作成日時の少なくとも1日後である必要があります。
オプションで、クールオフ期間時間単位を1〜72の範囲で設定します。このオプションは、ロックモードが compliance に設定されている場合にのみ適用されます。

aws_snapshot_lock_mode = compliance | governance
aws_snapshot_lock_duration = 1
aws_snapshot_lock_cool_off_period = 1
aws_snapshot_lock_expiration_date = "2024-10-07T21:53:00.606Z"

重要

以下にリストされている権限があることを確認します。

ec2:LockSnapshot

AWSスナップショットロックの概念については、 Amazon EBS snapshot lock concepts を参照してください。

バックアッププロセス#

次に、スナップショットバックアッププロセスの概要を示します。

Barmanは、チェックを実行して、スナップショットオプション、インスタンス、ディスクを検証します。
各バックアップの前と barman check コマンドの実行中に、次のチェックが実行されます。
- snapshot_instance およびプロバイダ固有の引数で指定されたコンピューティングインスタンスが存在します。
- snapshot_disks にリストされているディスクは存在します。
- snapshot_disks にリストされているディスクは、 snapshot_instance に接続されています。
- snapshot_disks にリストされているディスクは、 snapshot_instance にマウントされています。
Barmanは、PostgresバックアップAPIを使用してバックアップを開始します。
クラウドプロバイダーAPIは、指定された各ディスクのスナップショットを作成するために使用されます。 Barmanは、各スナップショットがアプリケーションの一貫性を保証する状態に到達するまで待機してから、次のディスクに進みます。
各ディスクのデバイス名、各ディスクのマウントポイントとオプションなどの追加プロバイダー固有の詳細は、バックアップメタデータに記録されます。

メタデータ#

コードとしてのインフラストラクチャ、アドホック自動化、または手動でリカバリディスクとインスタンスをプロビジョニングするかどうかに関係なく、 Barmanを使用して特定のバックアップに必要なスナップショットを特定する必要があります。これは、 barman show-backup コマンドで行うことができます。このコマンドは、バックアップに含まれる各スナップショットの詳細を提供します。

例

Backup 20240813T200506:
  Server Name            : snapshot
  System Id              : 7402620047885836080
  Status                 : DONE
  PostgreSQL Version     : 160004
  PGDATA directory       : /opt/postgres/data
  Estimated Cluster Size : 22.7 MiB

  Server information:
    Checksums            : on

  Snapshot information:
    provider             : aws
    account_id           : 714574844897
    region               : sa-east-1

    device_name          : /dev/sdf
    snapshot_id          : snap-0d2288b4f30e3f9e3
    snapshot_name        : Barman_AWS:1:/dev/sdf-20240813t200506
    Mount point          : /opt/postgres
    Mount options        : rw,noatime,seclabel

  Base backup information:
    Backup Method        : snapshot-concurrent
    Backup Size          : 1.0 KiB (16.0 MiB with WALs)
    WAL Size             : 16.0 MiB
    Timeline             : 1
    Begin WAL            : 00000001000000000000001A
    End WAL              : 00000001000000000000001A
    Number of WALs       : 1
    Begin time           : 2024-08-14 16:21:50.820618+00:00
    End time             : 2024-08-14 16:22:38.264726+00:00
    Copy time            : 47 seconds
    Estimated throughput : 22 B/s
    Begin Offset         : 40
    End Offset           : 312
    Begin LSN            : 0/1A000028
    End LSN              : 0/1A000138

  WAL information:
    Number of files      : 1
    Disk usage           : 16.0 MiB
    WAL rate             : 5048.32/hour
    Last available       : 00000001000000000000001B

  Catalog information:
    Retention Policy     : not enforced
    Previous Backup      : - (this is the oldest base backup)
    Next Backup          : - (this is the latest base backup)

--format=json オプションは、外部ツールと統合する場合に使用できます。

{
  "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",
        }
      }
    ]
  }
}

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 スナップショットの名前。

バックアップ#

概要#

バックアップの要件#

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

帯域幅使用量の管理#

ネットワーク圧縮#

バックアップ圧縮#

圧縮アルゴリズム#

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

圧縮レベル#

圧縮場所#

バックアップの暗号化#

要件#

暗号化方法#

GPG#

即時チェックポイント#

ストリーミングバックアップ#

ブロックレベルのインクリメンタル バックアップ#

SSHを介したRsyncを使用したバックアップ#

ファイルレベルのインクリメンタル バックアップ#

ローカルでRsyncを使用したバックアップ#

スタンバイのコンカレント バックアップ#

外部構成ファイルの管理#

バックアップに不変ストレージを使用する#

電流制限#

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

要件と構成#

Google Cloud Platform#

Microsoft Azure#

アマゾン ウェブ サービス#

バックアッププロセス#

メタデータ#

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

ブロックレベルのインクリメンタルバックアップ#

ファイルレベルのインクリメンタルバックアップ#

スタンバイのコンカレントバックアップ#

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

アマゾンウェブサービス#