SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
こんにちは。サイオステクノロジーの橋本です。
前回紹介した pgBackRest に続いて今回は PostgreSQL のバックアップ管理ツール barman を紹介します。
コミュニティページ : barman
https://pgbarman.org/
ちなみに barman はバーテンダーのイギリス英語だそうです。
バーテンダーはアメリカ英語なんですね。
film と movie、Autumn と Fall と同じ関係性で barman と Bartender という単語があるわけです。
お酒の barman とは全く関係なく、
PostgreSQL の barman は Backup and Recovery Manager の略称です。
目次
〇バックアップツールの比較〇
まず、前回ご紹介した pgBackRest と比較してみましょう。
pgBackRest のメリット、デメリット
・メリット
非常に高機能で細かい制御が可能
完全バックアップはもとより、増分や差分バックアップの取得も可能
・デメリット
機能に比例して設定が複雑になりがち
Barman のメリットデメリット
・メリット
ロジカルレプリケーションを利用したリアルタイム WAL ファイルバックアップ
バックアップはpg_basebackup や rsync を利用したものであるため、直感的に理解しやすい
・デメリット
基本的に完全バックアップしか取得できない
言う増分バックアップは
Postgres サーバに対し、完全バックアップを取得、
バックアップファイルがすでに取得済みのバックアップコンテンツで同様のものがある場合、
ハードリンクを作成することで DISK 容量を節約するものです
一般的にいう増分バックアップとは違う点に注意が必要です。
barman の最大の特徴としてストリーミングレプリケーションを用いて、
WAL ファイルをリアルタイムバックアップすることが可能です。
barman を用いることで RPO (Recovery Point Objective) を極めて短くすることが できます。
※EnterpriseDB 社は RPO を 0 にすることができると言っています。
〇用語説明〇
今回、Barman でしか用いない用語はないですが、
人によってブレが出る用語なので、一応説明します。
・アーカイブ WAL
barman の用語ではないですが、本記事では archive_command で退避された WAL ファイルを
全てアーカイブ WAL と呼んでいます。
〇できること、機能紹介〇
さて、できることは以下となります。
– できるバックアップ種別
・完全バックアップ
– 取得できるバックアップ
・リモートバックアップ ☆
・ローカルバックアップ
・レプリケーションを利用した WAL ファイルバックアップ☆
– 機能
複数の PostgreSQL サーババックアップ ☆
WAL圧縮
世代管理
コミュニティマニュアルでは「増分バックアップ」とありますが上記で説明したように、
一般的な「増分バックアップ」と異なるためできることとしては扱っていません。
Barman の最大の特徴はレプリケーションを利用した WAL ファイルバックアップです。
この機能を使えば RTO(Recovery Time Objective) を極めて短くすることができます。
※ Barman の開発元である EnterpriseDB 社は RTO = 0 もできるとドキュメントで説明しています。
実際、それくらい短い時間で復旧が可能です。
〇環境〇
前提として今回は以下の環境で検証しました。
OS , kernel や Python および barman のバージョンは全サーバ共通です。
PostgerSQL サーバは以下の2つバージョンのサーバを用意しました。
また、前提として 1秒に 1レコード、現在時刻を挿入するスクリプトを実装しています。
これを PostgreSQL のリストア時に、いつの時点にリカバリができたか判断に利用します。
〇バックアップイメージ図〇
Barman は pg_basebackup あるいは rsync を用いてベースとなるバックアップを取得します。
今回バージョンが異なる 2 サーバを用意しました。
せっかくなのでそれぞれ別の方法でバックアップを取得してみましょう。
Postgres 10
Postgres 10 サーバは pg_basebackup でバックアップを取得し、
ストリーミングレプリケーションを用いて WAL を受け取ります。
Postgres 14
Postgres 10 サーバは rsync でバックアップを取得しましょう。
また、アーカイブ WAL はPostgreSQL の設定 archive_command で受け取るように設定します。
※この場合 RTO はストリーミングレプリケーションを用いて WAL を受け取るより長くなります。
〇インストール〇
インストールは yum でインストール可能です。
・barman サーバ
yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm yum -y install barman postgresql14
Barman はレプリケーション等を行うため postgresql パッケージが必要です。
しかし、postgresql パッケージ内に含まれる pg_receivewal や pg_basebackup を利用するだけであり、
Barman サーバ内部では Postgresプロセスの稼働はなくDBの構築も不要という点に特徴があります
パッケージに互換性があるため、postgresql14 パッケージを入れておけば、
PostgreSQL 10 サーバのバックアップも取得可能です。
逆はできないので Barman にインストールする PostgreSQL パッケージは最新がおすすめです。
※ PostgreSQL10 のパッケージでは PostgreSQL 14 サーバのバックアップは取得できない。
・PostgreSQL サーバ
yum -y install barman-cli
DBをリストアする際やアーカイブ WALを処理する際に、
barman 系コマンドが必要となるのでbarman コマンドをインストールします。
〇設定〇
・Barman 設定
barman は /etc/barman/barman.conf で全体（グローバル）の設定を
/etc/barman/conf.d/任意ファイル名 で個別サーバ設定を行います。
一つの設定ファイルで全サーバの設定を行うことも可能ですが、
わかりやすく 1 ファイル 1 サーバで設定しましょう
サーバ ： Barman サーバ
設定ファイル ： /etc/barman.d/postgresql10.conf
[postgresql10] # server_name といい任意の名前を設定します。 conninfo = host=172.31.23.90 user=pg-user dbname=postgres port=5432 # Postgres サーバへの接続情報 backup_method = postgres # バックアップ手法を指定 postgres は pg_basebackup でのバックアップとなる streaming_backup_name = barman_streaming_BACKUP # pg_basebackup 時の application_name を指定 streaming_archiver = on # ロジカルレプリケーションで WAL ファイルを受け取る設定を有効化する create_slot = auto # レプリケーションスロットを自動で作る設定 slot_name = slot_for_backup # レプリケーションスロット名を指定 path_prefix = /usr/pgsql-14/bin # barman サーバ内の pg_receivewal などが格納されている場所を指定 archiver = off # archive_command によるバックアップを無効化
設定ファイルはBarman 側の設定は上記です。
注意としてはロジカルレプリケーションでWAL を受け取っているので、archiver を明示的にoff にしています。
archiver の設定は archive_command を用いて Barman サーバへ WAL をバックアップする際に利用します。
rsync でバックアップを行う場合は以下のような設定になります。
サーバ ： Barman サーバ
設定ファイル ： /etc/barman.d/postgresql14.conf
[postgresql14] ssh_command = ssh -i /var/lib/barman/.ssh/id_rsa pg-user@172.31.20.196 conninfo = host=172.31.20.196 user=pg-user dbname=postgres port=5432 backup_method = rsync backup_options = exclusive_backup archiver = on
PostgreSQL 側の設定は pg_hba.conf によるアクセス権限の付与が必要です。
・PostgreSQL 設定
・postgresql10
サーバ ： postgresql10 サーバ
設定ファイル ： pg_hba.conf
host replication pg-user 172.31.16.19/32 trust host postgres pg-user 172.31.16.19/32 trust
Barman は PostgreSQL に接続して、
Checkpioint コマンドの実行や pg_start_backup (pg_stop_backup) を実行します。
加えて、PostgreSQL 10 サーバではレプリケーションでWAL ファイルを受け取るため、
レプリケーション用の設定も必要です。
サーバ ： postgresql14 サーバ
設定ファイル ： pg_hba.conf
host postgres pg-user 172.31.16.19/32 trust
PostgreSQL 14 では archive_command で WAL ファイルを受け取るため、
レプリケーション用の設定は不要です。
Postgresql 14 サーバではarchive_command を用いて WAL ファイルを Barman サーバに渡す必要があるため、
以下のように設定します。
サーバ ： postgresql14 サーバ
設定ファイル ： postgresql.conf
archive_command = 'barman-wal-archive 172.31.16.19 postgresql14 %p'
なお、postgresql10 サーバのアーカイブ wal はストリーミングレプリケーションで受け取っているため
archive_command の設定は不要です。
〇レプリケーション設定〇
さて、次はストリーミングレプリケーションで WAL を受け取る設定です。
シンプルにコマンドだけで言うと「barman receive-wal <server_name>」で可能です。
今回の場合は「barman receive-wal postgresql10」で可能です。
ポイントとしては２つあります。
１つはPostgres プロセスがレプリケーションを受け取るのではなく、
Barman が pg_receivewal を利用してレプリケーションを行う点です。
＊つまり、Postgres プロセスは立ち上がらない
２つ目はフォアグラウンドプロセスで稼働するという点です。
つまり & を付けてバックグラウンドで実行しなければ
コマンドプロンプトがかえって来なくなります。
「barman receive-wal 10 &」を投入してバックグラウンドで実行するでも問題ないが、
この場合 Barman サーバで予期せぬ再起動が発生し、
いつの間にかロジカルレプリケーションが止まっていたという事象があり得ます。
そのため、今回は systemd を使ってデーモンとしてプロセスを稼働させてみましょう
サーバ ： Barman サーバ
設定ファイル ： /usr/lib/systemd/system/barman-streaming-postgresql10.service
[Unit] Description=Barman streaming [Service] Type=simple User=barman Group=barman ExecStart=/bin/barman receive-wal postgresql10 ExecStop=/bin/barman receive-wal postgresql10 --stop [Install] WantedBy=multi-user.target
サービスファイルを作ったの自動起動設定を有効化しつつ、
サービスを立ち上げてみましょう
systemctl enable barman-streaming-postgresql10 --now
・起動状況
# systemctl status barman-streaming-postgresql10.service ● barman-streaming-postgresql10.service - Barman streaming Loaded: loaded (/usr/lib/systemd/system/barman-streaming-postgresql10.service; enabled; vendor preset: disabled) Active: active (running) since 火 2022-09-26 15:50:17 JST; 7min ago Process: 21756 ExecStop=/bin/barman receive-wal postgresql10 --stop (code=exited, status=0/SUCCESS) Main PID: 21767 (barman) CGroup: /system.slice/barman-streaming-postgresql10.service tq21767 /usr/bin/python2 /bin/barman receive-wal postgresql10 mq21769 /usr/pgsql-14/bin/pg_receivewal --dbname=dbname=replication host=172.31.23.90 options=-cdatestyle=iso port=5432 replication=true user=pg-user application_name=barman_receive_wal --verbose --no-loop --no-password --directory=/var... 9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal systemd[1]: Started Barman streaming. 9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal barman[21767]: Starting receive-wal for server postgresql10 9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal barman[21767]: postgresql10: pg_receivewal: 0/3000000 (タイムライン 1)からログのストリーミングを開始 #
プロセスを見ると以下のようになります。
# ps -ef | grep [r]eceive barman 21767 1 0 15:50 ? 00:00:00 /usr/bin/python2 /bin/barman receive-wal postgresql10 barman 21769 21767 0 15:50 ? 00:00:00 /usr/pgsql-14/bin/pg_receivewal --dbname=dbname=replication host=172.31.23.90 options=-cdatestyle=iso port=5432 replication=true user=pg-user application_name=barman_receive_wal --verbose --no-loop --no-password --directory=/var/lib/barman/postgresql10/streaming --slot=slot_for_backup #
これで Postgresql10 サーバもアーカイブ WAL を受け取れるようになりました。
詳細なレプリケーションステータスは「barman replication-status ＜server_name＞」で確認可能です。
# barman replication-status postgresql10 Status of streaming clients for server 'postgresql10': Current LSN on master: 0/305E248 Number of streaming clients: 1 1. Async WAL streamer Application name: barman_receive_wal Sync stage : 2/3 WAL Sent (min) Communication : TCP/IP IP Address : 172.31.16.19 / Port: 44768 / Host: - User name : pg-user Current state : streaming (async) Replication slot: slot_for_backup WAL sender PID : 13464 Started at : 2022-09-26 15:50:17.389410+09:00 Sent LSN : 0/305E248 (diff: 0 B) Write LSN : 0/305E168 (diff: -224 B) Flush LSN : 0/3000000 (diff: -376.6 KiB) #
〇WAL アーカイブ設定確認〇
次に WALアーカイブ構成が正しくできているか確認します。
barman switch-xlog –force –archive ＜server_name＞ を実行することで確認できます。
「確認」とコミュニティマニュアルでも記載されていますが、PostgreSQL サーバでは実際に Checkpioint が発行されます。
# barman switch-xlog --force --archive postgresql10 The WAL file 000000010000000000000004 has been closed on server 'postgresql10' Waiting for the WAL file 000000010000000000000004 from server 'postgresql10' (max: 30 seconds) Processing xlog segments from streaming for postgresql10 000000010000000000000004 #
このコマンドが失敗する場合は、archive_command やレプリケーション設定に誤りがある可能性が高いです。
〇Barman 設定確認〇
これで一通りの設定が完了したはずです。
barman は設定に不備がないか「barman check ＜server_name＞」で確認可能です。
実際に見てみましょう。
# barman check postgresql10 Server postgresql10: PostgreSQL: OK superuser or standard user with backup privileges: OK PostgreSQL streaming: OK wal_level: OK replication slot: OK directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) backup minimum size: OK (0 B) wal maximum age: OK (no last_wal_maximum_age provided) wal size: OK (0 B) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 0 backups, expected at least 0) pg_basebackup: OK pg_basebackup compatible: OK pg_basebackup supports tablespaces mapping: OK systemid coherence: OK (no system Id stored on disk) pg_receivexlog: OK pg_receivexlog compatible: OK receive-wal running: OK archiver errors: OK #
# barman check postgresql14 Server postgresql14: PostgreSQL: OK superuser or standard user with backup privileges: OK wal_level: OK directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) backup minimum size: OK (0 B) wal maximum age: OK (no last_wal_maximum_age provided) wal size: OK (0 B) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 0 backups, expected at least 0) ssh: OK (PostgreSQL server) not in recovery: OK systemid coherence: OK (no system Id stored on disk) archive_mode: OK archive_command: OK continuous archiving: OK archiver errors: OK #
全て OK と出ているので問題がなさそうです。
エラーが出ている場合はエラーの内容と Barman のログ (/var/log/barman/barman.log)から
エラーの原因を特定、修正する必要があります。
＊ミスしがちなポイントやよくあるエラーはブログ末尾でいくつか取り上げます。
〇バックアップ取得〇
バックアップの取得は 「barman backup –wait ＜server_name＞」で可能です。
$ barman backup --wait postgresql10 Starting backup using postgres method for server postgresql10 in /var/lib/barman/postgresql10/base/20220926T160151 Backup start at LSN: 0/40137A0 (000000010000000000000004, 000137A0) Starting backup copy via pg_basebackup for 20220926T160151 Copy done (time: 2 seconds) Finalising the backup. This is the first backup for server postgresql10 WAL segments preceding the current backup have been found: 000000010000000000000003 from server postgresql10 has been removed Backup size: 31.5 MiB Backup end at LSN: 0/6000000 (000000010000000000000005, 00000000) Backup completed (start time: 2022-09-26 16:01:52.008113, elapsed time: 2 seconds) Waiting for the WAL file 000000010000000000000005 from server 'postgresql10' Processing xlog segments from streaming for postgresql10 000000010000000000000004 000000010000000000000005 $
$ barman backup --wait postgresql14 Starting backup using rsync-exclusive method for server postgresql14 in /var/lib/barman/postgresql14/base/20220926T160216 Backup start at LSN: 0/8000028 (000000010000000000000008, 00000028) This is the first backup for server postgresql14 WAL segments preceding the current backup have been found: 000000010000000000000003 from server postgresql14 has been removed 000000010000000000000004 from server postgresql14 has been removed 000000010000000000000005 from server postgresql14 has been removed 000000010000000000000006 from server postgresql14 has been removed Starting backup copy via rsync/SSH for 20220926T160216 Copy done (time: 1 second) This is the first backup for server postgresql14 Asking PostgreSQL server to finalize the backup. Backup size: 34.8 MiB Backup end at LSN: 0/8001CE8 (000000010000000000000008, 00001CE8) Backup completed (start time: 2022-09-26 16:02:17.128906, elapsed time: 3 seconds) Waiting for the WAL file 000000010000000000000008 from server 'postgresql14' Processing xlog segments from file archival for postgresql14 000000010000000000000007 000000010000000000000008 000000010000000000000008.00000028.backup $
取得したバックアップは barman list-backups <server_name> で確認可能です。
$ barman list-backups postgresql10 postgresql10 20220926T160151 - Mon Sep 26 16:01:54 2022 - Size: 47.5 MiB - WAL Size: 16.0 MiB $ barman list-backups postgresql14 postgresql14 20220926T160216 - Mon Sep 26 16:02:18 2022 - Size: 50.8 MiB - WAL Size: 0 B $
〇リストア〇
・疑似障害
リストアに当たり事前に以下のコマンドで障害を発生させます。
$ date ; kill -9 $(head -1 ${PGDATA}/postmaster.pid) ; date
2022年 9月 26日 月曜日 16:20:03 JST
2022年 9月 26日 月曜日 16:20:03 JST
$
バックアップを取得したのは 16:01 と 16:02 なので、
バックアップ取得時刻～16：20 のデータがリストアできていれば PITR の成功と判断できます。
・リストア
リストアは以下のコマンドで可能です。
barman recover <server_name> <backup_id> <復元先ディレクトリ> –remote-ssh-command ‘ssh <user 名>@<IP アドレス>’ –get-wal
backup_id は barman list-backups <server_name> で確認可能です。
postgresql10 の backup_id は 20220926T160151、
postgresql14 の backup_id は 20220926T160216 となっています。
複数のバックアップを取得した環境で、一世代前のバックアップからリストアしたい事情などがある場合に
backup_id を指定します。
今回の場合、持っている最新のバックアップからリストアをしたいので「latest」を指定します。
ポイントとしては 3 つあります。
1: リストア先サーバの指定
–remote-ssh-command を指定しないとコマンドを実行したサーバ (つまり barman サーバ)にリストアがされます。
2: リストアに WAL ファイルを含める
–get-wal を指定することで WAL ファイルを含めたリストアが可能となります。
3: リストア後の archive_command の設定
リストア直後の archive_command 設定は「archive_command = false」となっています。
この状態ではバックアップの取得ができないなどの不都合がありますので、
元の設定に戻しましょう。
具体的なリストアコマンドは以下となります。
barman recover postgresql10 latest /pgdb/data_bk –remote-ssh-command ‘ssh pg-user@172.31.23.90’ –get-wal
このコマンドはシンプルにあるだけ最新の状態にリストアするコマンドです。
特定の時間に戻したい場合は上記に加えて –target-time を付与します。
疑似障害のおよそ 1 分前を指定してリストアしてみましょう。
サンプル
$ barman recover postgresql10 latest /pgdb/data_bk --remote-ssh-command 'ssh pg-user@172.31.31.5' --get-wal --target-time '2022-09-26 16:19:00' Starting remote restore for server postgresql10 using backup 20220926T160151 Destination directory: /pgdb/data_bk Remote command: ssh pg-user@172.31.23.90 Copying the base backup. Generating recovery configuration Identify dangerous settings in destination directory. IMPORTANT These settings have been modified to prevent data losses postgresql.conf line 218: archive_command = false WARNING: 'get-wal' is in the specified 'recovery_options'. Before you start up the PostgreSQL server, please review the recovery.conf file inside the target directory. Make sure that 'restore_command' can be executed by the PostgreSQL user. Recovery completed (start time: 2022-09-26 16:04:12.701154, elapsed time: 6 seconds) Your PostgreSQL server has been successfully prepared for recovery! $
PostgreSQL のデータディレクトリ (PGDATA) は /pgdb/data ですが、
直接上書きリストアするのは怖いので一旦 /pgdb/data_bk に退避します。
そのうえで
mv /pgdb/data /pgdb/data_org
mv /pgdb/data_bk /pgdb/data
を行い、元のデータを残しつつ、バックアップデータを復元します。
PostgreSQL を起動する前に archive_command をもとに戻します。
＊今回の場合ローカルに WAL アーカイブを退避していました。
sed -i -e "s/archive_command \= false/archive_command = 'cp %p \/opt\/backups\/postgres\/archived_wals\/%f \;'/" /pgdb/data/postgresql.conf
1秒に 1レコード、現在時刻を挿入するスクリプトを動かしていたので、
正常にリストアができているか確認してみましょう
$ psql -d INFDB -c "select * from test ORDER BY id DESC FETCH FIRST 5 ROWS ONLY;" id | date | hostname -----+---------------------+------------------------------------------------- 287 | 2022-09-26 16:18:58 | ip-172-31-23-90.ap-northeast-1.compute.internal 286 | 2022-09-26 16:18:57 | ip-172-31-23-90.ap-northeast-1.compute.internal 285 | 2022-09-26 16:18:56 | ip-172-31-23-90.ap-northeast-1.compute.internal 284 | 2022-09-26 16:18:55 | ip-172-31-23-90.ap-northeast-1.compute.internal 283 | 2022-09-26 16:18:54 | ip-172-31-23-90.ap-northeast-1.compute.internal (5 行) $
16:18:58 にリストアができました。
＊スクリプトも厳密に 1,000 msec で動いているわけではないので 1 秒は誤差と判断します。
・PostgreSQL14 のリストア
PostgreSQL14 は archive_command で WAL ファイルを受け取っています。
そのため、最新の状態にリストアすることはできません。
リストアできるのは最後に archive_command で WAL ファイルを受け取った時刻までです。
〇よくあるトラブル〇
本ブログを執筆するにあたり直面したトラブルについて備忘を含め記録します。
・確認ポイント
barman check ＜server_name＞
Barman サーバのログファイル (/var/log/barman/barman.log)
PostgreSQL ログファイル
pg_hba.conf の設定が不足している
$ barman check postgresql10 Server postgresql10: PostgreSQL: FAILED directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) backup minimum size: OK (64.7 MiB) wal maximum age: OK (no last_wal_maximum_age provided) wal size: OK (0 B) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 1 backups, expected at least 0) pg_basebackup: OK pg_basebackup compatible: FAILED (PostgreSQL version: None, pg_basebackup version: 14.3) systemid coherence: OK (no system Id available) pg_receivexlog: OK pg_receivexlog compatible: FAILED (PostgreSQL version: None, pg_receivexlog version: 14.3) receive-wal running: FAILED (See the Barman log file for more details) archiver errors: OK $
pg_hba.conf が不足しているため「PostgreSQL: FAILED」となっています。
そして、PostgreSQL に接続ができないため、バックアップ先サーバの情報がまったくわからない状況です。
そのため pg_basebackup compatible: と pg_receivexlog compatible も FAILED となっています。
焦らず Barman サーバのログファイルを確認すれば、
わかりやすく原因が記載されています。
/var/log/barman/barman.log
2022-09-26 15:26:54,793 [3830] barman.postgres WARNING: Error retrieving PostgreSQL status: connection to server at "172.31.31.5", port 5432 failed: FATAL: no pg_hba.conf entry for host "172.31.19.92", user "pg-user", database "postgres", SSL off 2022-09-26 15:26:54,797 [3830] barman.postgres WARNING: Error retrieving PostgreSQL status: connection to server at "172.31.31.5", port 5432 failed: FATAL: no pg_hba.conf entry for replication connection from host "172.31.19.92", user "pg-user", SSL off
・WAL アーカイブ設定確認がうまくできない
コマンド「barman switch-xlog –force –archive ＜server_name＞」が失敗する場合、
PostgreSQL サーバの設定などが不足している可能性があります。
・「streaming_archiver = on」の場合
そもそもレプリケーションが正常に受けられているか確認しましょう。
barman replication-status postgresql10
streaming_archiver = on はをストリーミングレプリケーションを通して
WAL アーカイブを受け取ります。
そのため原因としてはレプリケーションが受けられていないことほぼほぼです。
archiver = on の場合
この場合、Barman サーバ PostgreSQL サーバの archive_mode に従って WAL アーカイブを取得します。
つまり、PostgreSQL サーバ側に問題がある可能性が高いです。
以下の点で問題がないか確認してください。
・PostgreSQL サーバから PostgreSQL プロセス所有ユーザで Barman サーバに対して ssh ができる
・PostgreSQL サーバに barman-cli パッケージがインストールされている
この 2 点が不足していることが原因である可能性が高いです。
そのうえで PostgreSQL ログファイルを確認して原因を確認しましょう。
〇まとめ〇
Barman は比較的シンプルな設定ながら RTO を極めて短くできる OSS です。
リストアも比較的簡単にできるのでぜひ触ってみて下さい！
Be the first to comment