前提条件#

このセクションでは、ユースケースに応じてBarman環境をセットアップするために必要ないくつかの要件と構成について詳しく説明します。

このセクションでは、次のホストを想定しています。

  • pghost Postgresが実行されているホスト。

  • barmanhost Barmanがセットアップされるホスト。

Postgresユーザー#

Barmanでサーバーに関する情報を収集するには、Postgresインスタンスへの接続が必要です。この接続をセットアップするための推奨される方法は、 Postgresで barman という名前の専用ユーザーを作成することです。このユーザーには、必要な特権が必要です。

注釈

以下で実行する createuser コマンドは、パスワードの入力を求めます。パスワードは、 barmanhost のBarmanホームディレクトリの下の .pgpass という名前の createuser に追加することをお勧めします。さらに、Postgresが提供するものの中から希望のクライアント認証方法を選択できます。詳細については、 createuser を確認してください。

Postgresで barman という名前のスーパーユーザーを作成するには、 pghost で次のコマンドを実行します。

createuser -s -P barman

または、必要な特権のみを持つユーザーを選択する場合、次の手順を実行します。

  1. pghost で、次のコマンドを実行して、Postgresに barman という名前のユーザーを作成します。

createuser -P barman
  1. pghost で、 psqlインターフェイスで、次のステートメントを実行します。

GRANT EXECUTE ON FUNCTION pg_backup_start(text, boolean) to barman;
GRANT EXECUTE ON FUNCTION pg_backup_stop(boolean) to barman;
GRANT EXECUTE ON FUNCTION pg_switch_wal() to barman;
GRANT EXECUTE ON FUNCTION pg_create_restore_point(text) to barman;
GRANT pg_read_all_settings TO barman;
GRANT pg_read_all_stats TO barman;

Postgresバージョン14以前のバージョンを使用する場合、ファンクション pg_backup_start および pg_backup_stop の名前とシグネチャが異なります。したがって、上記のブロックの最初の2行を次のように置き換える必要があります。

GRANT EXECUTE ON FUNCTION pg_start_backup(text, boolean, boolean) to barman;
GRANT EXECUTE ON FUNCTION pg_stop_backup() to barman;
GRANT EXECUTE ON FUNCTION pg_stop_backup(boolean, boolean) to barman;

注釈

Postgresバージョン13以下では、 barman switch-wal コマンドの --force オプションは、スーパーユーザーがないと機能しません。 Postgresバージョン15以降では、ステートメント GRANT pg_checkpoint TO barman; を実行することにより、 pg_checkpoint ロールを付与してスーパーユーザーなしで使用できます。

Postgres接続#

どのバックアップ方法を使用しているかに関係なく、Postgresインスタンスへの接続が必要です。この接続は、 Barmanがデータベースサーバーとのアクティビティを調整するために、およびモニタリングのために必要です。

barmanhost がスーパーユーザーとして、または必要な特権を持つユーザーとしてデータベースサーバーに接続できることを確認します。 Postgres接続のセットアップに関する詳細情報は、 barmanhost で見つけることができます。

ユーザーを作成したら、 barmanhost で次のコマンドを実行して、Postgresインスタンスに接続できることをアサートします。

psql -c 'SELECT version()' -U barman -h pghost postgres

postgres は、 BarmanがPostgresインスタンスに接続できる利用可能なデータベースです。

上記のコマンドが成功した場合、それはデータベースサーバーに正常に接続できることを意味します。上記の接続パラメーターは、サーバーの構成ファイルの conninfo パラメーターに書き込む必要があるものであるため、覚えておいてください。このコンテキストでは、このパラメーターは次のようになります。

[my-server]
; ...
conninfo = host=pghost user=barman dbname=postgres application_name=myapp

application_name はオプションのパラメーターです。

Postgresクライアントツール#

Postgresサーバーと対話するには、Postgresクライアントツールが必要です。 Barmanが最も一般的に使用するツールは pg_basebackup および pg_receivewal です。これらはPostgresクライアントパッケージによって提供されます。

DebianまたはUbuntuにPostgresクライアントパッケージをインストールするには、 barmanhost で次のコマンドを実行します。

sudo apt-get install postgresql-client

または、 barmanhost がRHEL、Rocky Linux、Alma Linuxを使用している場合、次のレシピに従います。

sudo dnf install postgresql

Postgresストリーミングレプリケーション接続#

ストリーミングバックアップまたはWALファイルのストリーミングを使用する予定がある場合は、ストリーミング接続をセットアップする必要があります。さらに、 pre-requisites セクションで共有されているように、 Postgresクライアントツールをインストールする必要があります。

Postgresで streaming_barman という名前の専用ユーザーを作成することをお勧めします。次のコマンドでこれを行うことができます。

createuser -P --replication streaming_barman

注釈

以下で実行する createuser コマンドは、パスワードの入力を求めます。パスワードは、 barmanhost のBarmanホームディレクトリの下の .pgpass という名前の createuser に追加することをお勧めします。さらに、Postgresが提供するものの中から希望のクライアント認証方法を選択できます。詳細については、 createuser を確認してください。

次のコマンドを使用して、ストリーミング接続が機能することを確認できます。

psql -U streaming_barman -h pghost -c "IDENTIFY_SYSTEM" replication=1

接続が機能している場合は、システム識別子、現在のタイムラインID、現在のWALフラッシュの場所を含む応答が表示されます。例

      systemid       | timeline |  xlogpos   | dbname
---------------------+----------+------------+--------
7139870358166741016 |        1 | 1/330000D8 |
(1 row)

Postgresで max_wal_senders パラメーターを構成する必要もあります。 WAL送信者の数は、実装したPostgresアーキテクチャによって異なります。この例では、 2 に設定しています。

max_wal_senders = 2

このオプションは、Postgresが管理できる同時ストリーミング接続の最大数を表します。

もう1つの重要なパラメーターは max_replication_slots で、これはPostgresが管理できるレプリケーションスロットの最大数を表します。このパラメーターは、ストリーミング接続を使用してストリーミング接続を介してWALファイルを受信する予定がある場合に関連します。

max_replication_slots = 2

max_replication_slots および max_wal_senders として提案された値は例として考えられる必要があり、実際のセットアップで使用する値は、アーキテクチャを注意深く評価した後に選択する必要があります。ガイドラインと説明については、 Postgresのドキュメントを参照してください。

SSH接続#

archive_command を介してRsyncバックアップまたはWALアーカイブを使用する予定がある場合、SSH接続が必要です。

SSHは、リモートサーバーへのリモートシェルを開き、サーバーとローカルシステム間でファイルをコピーできるプロトコルとツールセットです。 SSHの使用に関する詳細ドキュメントは article /"SSH Essentials/" by Digital Ocean で見つけることができます。

SSHキー交換は、別のマシン上のユーザー間の安全なパスワードレス接続を実装するために使用される非常に一般的な手法であり、WALのアーカイブとバックアップにRsyncを使用するために必要です。

postgresユーザーのSSH構成#

これまでに行ったことがない限り、 postgres ユーザーのSSHキーを作成する必要があります。 pghost に postgres としてログインし、実行します。

ssh-keygen -t rsa

このキーは、パスワードを提供せずにホストから接続するために使用する必要があるため、キーペアの作成中にパスフレーズを入力する必要はありません。

barmanユーザーのSSH構成#

barman ユーザーのSSHキーも作成する必要があります。 barmanhost に barman としてログインし、実行します。

ssh-keygen -t rsa

繰り返しますが、パスフレーズは入力する必要はありません。

PostgresからBarmanへ#

pghost から barmanhost へのSSH接続は、 archive_command を使用してWALファイルを正しくアーカイブするために必要です。

pghost から barmanhost に正常に接続するには、 pghost ユーザ`の公開キーを、 barmanhost の pghost ユーザの許可されたキーに保存する必要があります。このキーは、 .ssh/id_rsa.pub という名前のファイルの pghost ユーザーホームディレクターにあり、そのコンテンツは、 barmanhost の pghost ユーザーのホームディレクトリ内の .ssh/authorized_keys という名前のファイルに含まれる必要があります。 authorized_keys ファイルが存在しない場合は、権限として 600 を使用して作成します。

SSHキーペアの交換が正常に完了した場合、次のコマンドは出力なしで成功するはずです。

ssh barman@barmanhost -C true

BarmanからPostgresへ#

barmanhost から pghost 間のSSH接続は、Rsyncを使用した従来のバックアップに使用されます。

barmanhost から pghost に正常に接続するには、 barmanhost ユーザ`の公開キーを、 pghost の barmanhost ユーザの許可されたキーに保存する必要があります。このキーは、 barmanhost ユーザーホームディレクトリの .ssh/id_rsa.pub という名前のファイルにあります。そのコンテンツは、 pghost の barmanhost ユーザーのホームディレクトリ内の .ssh/authorized_keys という名前のファイルに含まれる必要があります。 authorized_keys ファイルが存在しない場合は、権限として 600 を使用して作成します。

SSHキーペアの交換が正常に完了した場合、次のコマンドは出力なしで成功するはずです。

ssh postgres@pghost -C true

archive_command を介したWALアーカイブ#

WALアーカイブ戦略 セクションで述べたように、 Barmanでwalsをアーカイブするには2つのオプションがあります。ストリーミングレプリケーションプロトコルを使用してWALファイルをアーカイブする場合は、 WALアーカイブ戦略 概念と WALアーカイブ戦略 セクション、特にWALストリーミングによるストリーミングバックアップサブセクションを参照してください。それ以外の場合は、 WALアーカイブ戦略 またはRsync / SSHで archive_command を使用してWALアーカイブを構成できます。

barman-wal-archiveを使用する#

Barman 2.6以降、書き込み先行ログファイルを安全にアーカイブするための推奨アプローチは、 barman-cli パッケージの barman-wal-archive コマンドを利用することです。このパッケージをインストールする方法については、 barman-wal-archive セクションを参照してください。

rsyncやSSHなどの従来の方法の代わりに barman-wal-archive を使用すると、WALファイルのBarmanサーバーへの転送中のデータ破損のリスクを最小限に抑えます。従来の方法には、ファイルのコンテンツが宛先のディスクに適切にフラッシュおよびfsyncされるという保証がありません。

barman-wal-archive ユーティリティは、 barman-wal-archive コマンドと直接対話します。このコマンドは、受信したWALファイルがfsyncされ、各サーバーの正しい受信ディレクトリに保存されるようにします。 archive_command に必要なパラメーターはサーバーの名前だけであるため、誤って配置される可能性が減少します。

注釈

barman-wal-archive クライアントは、障害を最小限に抑え、PostgreSQLサーバーにWALファイルが蓄積するのを防ぐように設計されています。重複したWALファイルがBarmanホストに送信されると、コマンドは成功コード0で終了し、メッセージがログに記録されます。

複製ファイルの内容がBarmanホストに既に保存されているものと一致する場合、ファイルは無視されます。ただし、コンテンツが異なる場合、ファイルはBarmanサーバーのerrorsディレクトリに移動します。これにより、今後の barman check 実行では、不一致による障害が報告されます。

barman-wal-archive がBarmanサーバーに接続できること、およびPostgresサーバーが着信WALファイルを受け入れるように正しく構成されていることを確認するには、次のコマンドを実行します。

barman-wal-archive --test backup pg DUMMY

ここで、 backup はBarmanホストを指し、 pg はBarmanで構成されたPostgresサーバーの名前であり、 DUMMY は -t オプションを使用する場合に無視されるWALファイル名のプレースホルダーです。

設定が正しい場合は、次が表示されます。

Ready to accept WAL files for the server pg

ユーティリティはSSHを介して通信するため、postgresユーザーがバックアップサーバーにbarmanとしてログインするようにSSHキー認証が設定されていることを確認します。 SSH接続がデフォルト22以外のポートを使用する場合、 --port オプションを使用してポートを指定できます。

WALアーカイブを使用したRsyncバックアップ を参照して、作業を開始します。

Rsync / SSHを使用する#

archive_command を構成するための alternative approach は、SSHを介してrsyncコマンドを利用することです。ここでは、 pg という名前のPostgresサーバー、 backup という名前のBarmanサーバー、および barman という名前のユーザーを効果的に設定するための初期手順を示します。

着信WALディレクトリを見つけるには、次のコマンドを使用して、 incoming_wals_directory 値を確認します。

barman show-servers pg | grep incoming_wals_directory

    incoming_wals_directory: /var/lib/barman/pg/incoming

次に、 pg ホスト上のPostgresインスタンスの postgresql.conf ファイルを編集して、アーカイブモードを有効にします。

archive_mode = on
wal_level = 'replica'
archive_command = 'rsync -a %p barman@backup:INCOMING_WALS_DIRECTORY/%f'

INCOMING_WALS_DIRECTORY プレースホルダーを、前のコマンドから取得した実際のパスに置き換えてください。これらの変更を行った後、Postgresサーバーを再起動します。

archive_command プロセスのセキュリティを強化するには、より厳密なチェックを実装することを検討します。たとえば、次のコマンドは、rsyncを実行する前にホスト名が一致することを確認します。

archive_command = 'test $(/bin/hostname --fqdn) = HOSTNAME \
    && rsync -a %p barman@backup:INCOMING_WALS_DIRECTORY/%f'

HOSTNAME を hostname --fqdn からの出力に置き換えます。このアプローチは、サーバーがクローン化される際の潜在的な問題に対するセーフガードとして機能し、復旧したPostgresインスタンスからWALファイルが送信されないようにします。