バックアップ

バックアップ#

概要#

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は、ストリーミング接続を介したブロックレベルのインクリメンタル バックアップもサポートします。

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

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

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

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

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

重要

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

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

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 を使用します。

重要

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

クラウドへのストリーミングバックアップ#

クラウドストレージURLに対して backup_method = postgres 、 basebackups_directory 、 wals_directory で構成されている場合、 Barmanはクラウドストレージへの直接のストリーミングバックアップをサポートします。このモードでは、バックアップはPostgresサーバーから pg_basebackup を介してBarmanサーバーにストリーミングされ、完全なバックアップをローカルに保存することなく、チャンクでクラウドに動的にプッシュされます。 WALファイルはPostgresサーバーからBarmanサーバーにストリーミングされ、アーカイブがトリガーされるたびにクラウドにアップロードされます。これは定期的に、または barman archive-wal コマンドを手動で実行したときに発生します。

これは、現在、クラウド環境でブロックレベルのインクリメンタルバックアップを有効にする唯一の方法です。

この機能を構成するには、 backup_method = postgres 、 basebackups_directory 、および wals_directory をクラウドストレージURLに設定します。例、S3互換ストレージを使用する場合

backup_method = postgres
basebackups_directory = s3://mybucket/barman/
wals_directory = s3://mybucket/barman/

構成が完了すると、データをクラウドに安全に保存しながら、インクリメンタルバックアップ、保持ポリシーなどを含むBarmanサーバーのすべての機能を活用できます。

注釈

basebackups_directory と wals_directory に異なるURLを設定することは可能ですが、両方のオプションに同じURL、場合によっては同じパスを使用することを強くお勧めします。これにより、 Barmanが各サーバーのデータを専用のサブディレクトリに整理するため、クラウドでの一貫したストレージ構造が保証されます。

警告

アクティブなサーバーで basebackups_directory および/または wals_directory の値を変更することは非推奨です。サーバーを非アクティブ化し、既存のデータを新しい場所に移動し、再アクティブ化することにより、注意して行ったとしても、データの損失または構成ミスの潜在的なリスクがあります。

代わりに、安全なオプションは、 basebackups_directory または wals_directory の新しい値で新しいサーバー構成を作成し、新しいサーバーに新しい完全なバックアップを実行し、新しいサーバーが完全に動作したら、古いサーバーを廃止することです。

この機能を使用する場合、 Barmanはクラウドにアップロードする前にチャンクを処理するローカルステージングスペースを必要とします。使用できるステージング領域の量とその場所は、オプション cloud_staging_max_size および cloud_staging_directory で構成でき、または実行時に --cloud-staging-max-size および --cloud-staging-directory CLIオプションを使用してオーバーライドできます。

これは実験的な機能です。このため、いくつかの制限が適用されます。

  1. 現在、S3互換ストレージのみが宛先としてサポートされています。

  2. バックアップとWALの暗号化はサポートされていません。

  3. バックアップの圧縮はサポートされていません。 WAL圧縮は、圧縮方法として pigz または custom を使用する場合を除きサポートされます。

  4. verify-backup 、 generate-manifest 、 rebuild-xlogdb 、 get-wal などのバックアップまたはWALファイルへのアクセスを必要とするBarmanサブコマンドはサポートされておらず、実行すると失敗します。

  5. Barman 地理的な冗長性 機能とその関連コマンドはサポートされていません。

  6. 今のところ、この機能はLinuxベースのディストリビューションでのみ動作し、BSD派生システムFreeBSDやOpenBSDなどではサポートされていません。

Rsyncバックアップ#

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

rsyncを使用してバックアップを構成するには、特定のPostgresサーバーの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を使用したファイルレベルのインクリメンタル バックアップ#

ファイルレベルのインクリメンタル バックアップは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は local-rsync と呼ばれるローカルバックアップ方法をサポートしています。この方法は、リモート rsync 方法と同じrsyncベースのバックアップアプローチを使用しますが、トランスポートレイヤーのSSHに依存しません。代わりに、Postgresが実行されているのと同じサーバーでローカルにファイルコピー操作を実行します。このため、 BarmanはPostgresと同じユーザーで実行する必要があります。

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

  • cron構成

  • ログ構成logrotateを含む

  • Barmanのホーム構成。

ローカルバックアップ用にBarmanをセットアップすることをお勧めします。 Barmanのインストール後に次の手順に従うことです。

  1. グローバル構成ファイルで barman_user = postgres または別のサーバーを使用している場合は、サーバーを実行しているオペレーティングシステムユーザーを設定して、 Barmanがデータファイルを読み取るためのアクセスを保証します。

  2. バックアップディレクトリとその他の関連ディレクトリを同じユーザーがアクセスできるように構成します。これは、構成ファイルたとえば backup_directory 、 barman_home 、 log_filename などコミュニティパッケージが提供するデフォルトのパスは、 barman ユーザーが所有しており、これらのディレクトリの権限と所有権はパッケージの更新中に元の状態に復元され、問題が発生する可能性があるため、使用しないでください。

詳細については、 Configuration options を参照してください。

Barmanで特定のサーバーのローカルバックアップを使用するには、 backup_method を local-rsync に設定する必要があります。

ローカルからクラウドへのバックアップ#

Barmanは、 local-to-cloud バックアップ方法を使用してクラウドオブジェクトストレージに直接バックアップを実行できます。この方法は、ローカルファイルシステム上のPostgres PGDATAディレクトリからデータを直接読み取り、バックアップデータ用の中間ローカルストレージを必要とせずに、クラウドストレージに直接アップロードします。

注釈

現在、 Amazon S3 およびS3互換ストレージのみがサポートされています。 Azure Blob StorageとGoogle Cloud Storageのサポートは、 Barmanの将来のバージョンで追加されます。

他のバックアップ方法と同様に、このアプローチはデータベースサーバーとの調整にPostgresの低レベルバックアップAPIを使用しますが、バックアップデータはディスクから読み取られるときにクラウドに直接アップロードします。

重要

local-to-cloud バックアップ方法には以下が必要です。

  • Postgres 9.6以降同時バックアップサポートの場合。

  • Barmanは、PGDATAディレクトリへの直接ファイルシステムアクセスを持っている必要があります。

  • Barmanを実行するユーザーは、データベースクラスターの所有者である必要があります。

  • 適切に構成されたAWS資格情報またはS3互換ストレージの資格情報。

  • 適切に構成されたS3またはS3互換オブジェクトストレージバケットへのネットワークアクセス。

ローカルからクラウドへのバックアップを構成するには、 backup_method を local-to-cloud に設定し、クラウドストレージパスURLを構成します。

backup_method = local-to-cloud
basebackups_directory = s3://bucket-name
wals_directory = s3://bucket-name
conninfo = host=localhost dbname=postgres user=postgres

basebackups_directory は、S3ストレージURLたとえば s3://bucket/path である必要があります。同様に、 wals_directory は、WALアーカイブのS3保存場所を指す必要があります。

注釈

Barmanは各サーバーのデータを専用のサブディレクトリに整理するため、クラウドで一貫したストレージ構造を維持するために、 basebackups_directory と wals_directory の両方に同じバケットとパスを使用することをお勧めします。

警告

アクティブなサーバーで basebackups_directory および/または wals_directory の値を変更することは非推奨です。サーバーを非アクティブ化し、既存のデータを新しい場所に移動し、再アクティブ化することにより、注意して行ったとしても、データの損失または構成ミスの潜在的なリスクがあります。

代わりに、安全なオプションは、 basebackups_directory または wals_directory の新しい値で新しいサーバー構成を作成し、新しいサーバーに新しい完全なバックアップを実行し、新しいサーバーが完全に動作したら、古いサーバーを廃止することです。

AWS S3構成オプション#

local-to-cloud バックアップ方法は、さまざまなAWS S3構成オプションをサポートしています。

Bandwidth Control:

  • bandwidth_limit クラウドアップロードの1秒あたりのキロバイト単位の最大転送速度デフォルト 0 制限なしを意味します。

AWS S3 Options:

  • aws_region S3バケットのAWSリージョン。

  • aws_profile 認証用のAWSプロファイル名。

  • aws_encryption S3暗号化方法 AES256 または aws:kms 。

  • aws_sse_kms_key_id サーバーサイドの暗号化のためのKMSキーID。

  • aws_read_timeout 秒単位のS3読み取りタイムアウト。

Cloud Options:

  • cloud_upload_max_archive_size クラウドアーカイブごとの最大サイズデフォルト 100G 。

  • cloud_upload_min_chunk_size マルチパートアップロードの最小チャンクサイズ。

  • cloud_delete_batch_size 1回のバッチ操作で削除するファイルの数。

Compression:

  • compression WAL圧縮アルゴリズム gzip 、 bzip2 、 xz 、 snappy 、 zstd 、 lz4 、または none 。

  • compression_level 圧縮レベル-選択したアルゴリズムに応じて、 low 、 medium 、 high 、または数値に設定できます。

圧縮設定の詳細については、以下の バックアップ圧縮 セクションを参照してください。

Local-to-Cloudを使用する場合#

local-to-cloud バックアップ方法は、次の場合に適切です。

  • PostgresとBarmanは同じマシンで実行されるか、 BarmanはPGDATAディレクトリに直接ローカルファイルシステムにアクセスします。

  • バックアップデータ自分自身用の中間ローカルストレージを使用せずに、AWS S3またはS3互換ストレージに直接バックアップしたい。

  • メインの barman CLIを介したシンプルで統合されたクラウドバックアップ構成が必要です。

制限事項#

local-to-cloud バックアップ方法には次の制限があります。

  • does not は、インクリメンタル バックアップをサポートしますブロックレベルのインクリメンタル バックアップをサポートするPostgres 17以降の postgres 方法とは異なります。

  • does not は、ハードリンクを介したファイルレベルの重複排除をサポートします reuse_backup を使用した rsync とは異なります。

  • Only AWS S3 and S3-compatible storage are currently supported - Azure Blob StorageおよびGoogle Cloud Storageのサポートは、将来のバージョンで追加されます。

  • PGDATAへのローカルファイルシステムのアクセスが必要ですリモートサーバーの rsync または postgres メソッドとは異なります。

構成例#

次に、AWS S3を使用したローカルからクラウドへのバックアップの完全な構成例を示します。

[myserver]
backup_method = local-to-cloud
barman_user = postgres
basebackups_directory = s3://my-backup-bucket
wals_directory = s3://my-backup-bucket
conninfo = host=localhost dbname=postgres user=postgres
bandwidth_limit = 5120  ; 5 MB/s
compression = gzip
aws_region = us-west-2
aws_profile = barman
archiver = on

この構成では、 BarmanはローカルのPGDATAディレクトリからデータを直接読み取り、WALファイルの帯域幅調整とgzip圧縮を使用して指定されたS3バケットにアップロードすることによりバックアップを実行します。

ローカルからクラウドへのWALアーカイブ#

local-to-cloud バックアップ方法を使用する場合、barmancloud-wal-archive`コマンドを使用してWALファイルをクラウドにアーカイブできます。これは、 ``archive_command` を介して構成で指定されたクラウドストレージにWALファイルをアップロードします。

archive_command = 'barman cloud-wal-archive myserver %p'

WAL生成が多い期間にWALアーカイブバックログを削減するために、 --parallel フラグまたは cloud_wal_archive_parallel 構成オプションを使用して追加のWALファイルを同時にアップロードできます。

archive_command = 'barman cloud-wal-archive --parallel 2 myserver %p'

--parallel N が設定されている場合N > 1、プライマリWALが正常にアーカイブされた後、 pg_wal/archive_status で準備ができている最大 N - 1 追加のWALファイルがバックグラウンドプロセスでアップロードされます。

一般的なバックアップ設定#

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

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

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

  • 完全なバックアッププロセスの時間を短縮します。

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

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

  • ファイルレベルのインクリメンタル バックアップ rsync を使用

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

注釈

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

スタンバイサーバーからのバックアップ#

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

  • 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での誤検出問題が発生する可能性があるため、他方を使用している場合は一方を無効にする必要があります。

帯域幅使用量の管理#

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

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

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

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

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

重要

bandwidth_limit オプションは、 rsync 、 postgres および local-to-cloud バックアップ方法で使用できますが、 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は、不変ストレージにバックアップを保存するように構成して、悪意のあるアクターまたは誤った削除から保護できます。このようなストレージは、`WORM`Write Once Read Manyストレージと呼ばれることもあります。

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

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

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

  • 次の2つのディレクトリのみが不変のストレージパスに保存されるように構成する必要があります。

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

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

ヒント

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

即時チェックポイント#

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

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

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

  • --immediate-checkpoint 即時チェックポイントを強制します。

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

目次