Barman とは PostgreSQL のPITR（ポイントインタイムリカバリ）を簡単に管理してくれるツールです。
PITRとはバックアップ／リストア方式の一つで、過去の指定した時点の状態に復元することが可能です。PITRは、データベースクラスタの物理コピー（ベースバックアップと呼びます）を取得し、以降のデータ変更が書き出される WALファイルを継続的に保存する（保存したものをWALアーカイブやアーカイブログと呼びます）ことで実現されます。現在稼働しているデータベースクラスタを障害やオペレーションミスから復旧したい場合には、保存していたベースバックアップにWALアーカイブを適用することで、ベースバックアップ取得時点からWALアーカイブが適用できる限りの任意の時点に復元することができます。
PITR は PostgreSQL のバックアップ方式としてよく用いられる手法ですが、DB 管理者が考慮すべきことや操作手順が増え、運用管理の手間が増えます。例えば、PITR の運用はベースバックアップの世代管理や、溜まり続ける古いアーカイブログファイルの削除は PostgreSQL の本体機能として備わっておらず、DB 管理者がそのような処理を行うスクリプトを用意しなければなりません。バックアップからのリカバリ作業も DB 管理者が手動で煩雑な手順を実施する必要があります。
Barman を利用すると、PITR に関する種々の操作を Barman のコマンド経由で簡単にできるようになります。また、Barman は複数のデータベースクラスタの PITR を一元管理できます。逆に言えば、PITR の世代管理やアーカイブログのパージ、リカバリ操作を自動で行えるようなスクリプトを既に自前で作成し運用している場合や、管理するデータベースクラスタが多くない場合は、Barman に利点を見出すことは少ないでしょう。
Barman 主な特徴は以下の通りです。
- PostgreSQL の PITR（ベースバックアップと WAL アーカイビング）を基にしている。
- ベースバックアップは ssh + rsync や pg_basebackup が使える。
- WAL アーカイビングは archive_command やストリーミングレプリケーションプロトコルが使える。
- フルバックアップのインクリメンタルバックアップができる。
- バックアップ・WAL の取得前後にフックスクリプトを呼び出せる。
- ネットワーク制限・データ転送の圧縮・WAL の圧縮・並行ジョブの実施によってワークロードを調整できる。
- 複数のデータベースクラスタのバックアップを Barman でまとめて管理できる。
- 世代管理などのバックアップポリシーを規定できる。
本文書では、Barman のインストールと基本的な使い方の解説をします。また、執筆時点で最新のBarmanバージョン 2.5 を基準に記載しています。
Barman のシステム要求
Barman 導入のための要件はドキュメントによると以下の通りです。
対応 OS: Linux/Unix 使用言語: Python 2.6 or 2.7 Python modules: argcomplete argh >= 0.21.2 <= 0.26.2 argparse (Python 2.6 only) psycopg2 >= 2.4.2 python-dateutil <> 2.0 setuptools 対応 PostgreSQL: 8.3 以上 ただし、全ての機能を使いたい場合は 9.5.5 以上 オプション: rsync >= 3.0.4 (optional for PostgreSQL >= 9.2)
Barman は Windows には非対応ですが、Docker を通して Windows 上で動作させることは可能です。
Barman のインストールとセットアップ
この記事では 2 台の仮想マシン barman と pgsql01 を用い、barman サーバに Barman をインストールし、pgsql01 サーバには PostgreSQL 10 がセットアップ済みであるものとします。
それでは Barman を yumを使ってインストールいきます。
Barman の yumインストールは、EPEL リポジトリと PGDGリポジトリ（PostgreSQL の公式 yumリポジトリ）が登録されている必要があります。PGDGリポジトリはバックアップ対象の PostgreSQL と同一メジャーバージョンのリポジトリを選択するとよいです。異なるメジャーバージョンの PostgreSQL をバックアップ対象とする場合は、最も新しいメジャーバージョンの PGDG リポジトリを選択するとよいです。Barman は PGDGリポジトリから PostgreSQL の共有ライブラリをインストールしますが、共有ライブラリは後方互換性が保たれているからです。
（PGDGリポジトリのインストール） [root@barman ~]# yum --assumeyes install epel-release https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
その後、Barman と PostgreSQL をインストールします。PostgreSQL（のクライアントアプリケーション）は Barman のバックアップ・リカバリ処理時に必要となります。
（barmanパッケージのインストール） [root@barman ~]# yum --assumeyes install barman postgresql10
インストールが完了すると、barman ユーザと barman グループが自動作成されます。barman ユーザのホームディレクトリは /var/lib/barman になります。しかし、barman ユーザを利用すると、バックアップファイルやリカバリ先の所有者権限が barman ユーザとなってしまいます。ここでは、PostgreSQL に合わせて postgresユーザを利用していきます。
（barmanユーザが作られていることを確認する） [root@barman ~]# id barman uid=997(barman) gid=995(barman) groups=995(barman) [root@barman ~]# grep barm /etc/passwd barman:x:997:995:Backup and Recovery Manager for PostgreSQL:/var/lib/barman:/bin/bash
まずは Barman 自体と、管理対象のサーバ情報を設定します。設定ファイルは INI 形式です。Barman 自体のグローバル設定は /etc/barman.conf で行います。[barman] セクション以下に各パラメータを設定することになります。Barman 実行ユーザを postgres とし、Barman のホームディレクトリを postgres ユーザのホームディレクトリとする以外は、デフォルトのままとしておきます。
（barmanのグローバル設定を変更する） [root@barman ~]# vi /etc/barman.conf barman_user = postgres barman_home = /var/lib/pgsql
Barman の管理対象となる PostgreSQL サーバの情報は、/etc/barman.d 以下にサーバ単位でファイルを作成します。ファイル名は任意で構いませんが、PostgreSQL サーバ名と合わせておくと識別しやすいです。 ファイルの内容は、一意なセクションが一つのバックアップ設定となります。たとえば、以下では、pgsql01 サーバに対して、[ssh-pgsql01] セクションと [streaming-pgsqo01] セクションという 2 つのバックアップ設定を設定しています。Barman の公式ドキュメントではこのセクションにサーバ名を指定し、barman コマンドの < server_name > 引数で使うことが記載されていますが、とくにセクションとサーバ名を合わせる必要はありません。あくまで、一つのセクションが一つのバックアップ設定です。
（barman個別設定を追加する） [root@barman ~]# cat << EOT > /etc/barman.d/pgsql01.conf > [ssh-pgsql01] > ssh_command = ssh -q postgres@pgsql01 > conninfo = host=pgsql01 user=postgres dbname=postgres > backup_method = rsync ; ベースバックアップは rsync で行なう > archiver = on ; archive_command による WAL アーカイビング > > [streaming-pgsql01] > conninfo = host=pgsql01 user=postgres dbname=postgres port=5433 > backup_method = postgres ; ベースバックアップは pg_basebackup で行なう > streaming_archiver = on ; ストリーミングレプリケーションプロトコルによる WAL アーカイビング > slot_name = barman ; レプリケーションスロットを使う（streaming_archiver = on の場合に推奨） > EOT
その他のパラメータについては man 5 barman コマンドで調べることができます。
/etc/barman.d 以下にテンプレートファイルが用意されているので、それを流用してもよいです。なお、barman 実行ユーザが $HOME/.barman.conf を所有していると、そちらが優先されます。
パスワード無しの SSH 接続設定
ベースバックアップの取得に SSH と rsync を用いる場合は Barman 実行ユーザと PostgreSQL 実行ユーザが両方向にパスワード無しで SSH 接続できるようにしておく必要があります。以下のように SSH 鍵の作成と、公開鍵の配布を行います。事前に（セキュリティ上の制約があるならば、一時的に） barman 実行ユーザと PostgreSQL 実行ユーザにパスワードを設定し、パスワード認証で SSH 接続ができるようにしておく必要があります。
（パスワード入力無しでssh接続できるようにする） [postgres@barman ~]$ ssh-keygen -t rsa [postgres@barman ~]$ ssh-copy-id postgres@pgsql01 /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/var/lib/pgsql/.ssh/id_rsa.pub" /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Warning: Permanently added 'pgsql01,192.168.1.12' (ECDSA) to the list of known hosts. postgres@pgsql01's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'postgres@pgsql01'" and check to make sure that only the key(s) you wanted were added.
[postgres@pgsql01 ~]$ ssh-keygen -t rsa [postgres@pgsql01 ~]$ ssh-copy-id postgres@barman /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/var/lib/pgsql/.ssh/id_rsa.pub" /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Warning: Permanently added 'barman,192.168.1.11' (ECDSA) to the list of known hosts. postgres@barman's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'postgres@barman'" and check to make sure that only the key(s) you wanted were added.
ここまでで barman のインストールと設定ができました。
archive_command による WALアーカイブと SSH + rsync によるベースバックアップ
それでは /etc/barman.d/pgsql01.conf の [ssh-pgsql01] セクションで定義したバックアップを試していきましょう。
barman の check サブコマンドで指定のバックアップ設定が正しいかどうか確認します。また、これによってバックアップに必要なディレクトリが自動作成されます。この操作は新しいバックアップ設定を追加する都度、必須です。WAL archive と PostgreSQL 以外は全て OK となることを確認してください。なお、出力結果に「ssh output clean: FAILED (the configured ssh_command must not add anything to the remote command output)」た含まれる場合は、当該のバックアップセクションの ssh_command パラメータに設定した ssh コマンドに -q オプションを加えると、出力を抑制できます。
（barmanバックアップ設定が正しいか確認する） [postgres@barman ~]$ barman check ssh-pgsql01 Server ssh-pgsql01: WAL archive: FAILED (please make sure WAL shipping is setup) PostgreSQL: FAILED directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) 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 archiver errors: OK
続けて PostgreSQLサーバで WALアーカイビングが行われるように postgresql.conf を設定します。
（postgresql.confファイル） #wal_level = replica archive_mode = on archive_command = 'rsync -a %p postgres@barman:/var/lib/pgsql/ssh-pgsql01/incoming/%f'
なお、archive_command に指定するアーカイブWAL の出力先は barmanコマンドで確認できます。サブコマンド show-server の引数に確認したいバックアップ設定セクション名を指定すると、設定地を確認できます。
（ssh-pgsql01 の incoming_wals_directory設定を確認する） [postgres@barman ~]$ barman show-server ssh-pgsql01 | grep incoming_wals_directory incoming_wals_directory: /var/lib/pgsql/ssh-pgsql01/incoming
また、Barman と PostgreSQL 間のクライアント認証を trust接続にしておきます。これは本記事の試験用の設定であってパスワード認証にすることもできます。
host all all samenet trust host replication all samenet trust
設定が完了したら PostgreSQL を起動します。
[postgres@pgsql01 ~]$ pg_ctl -w start
pgbenchコマンドでデータを生成して barman サーバに WALアーカイビングが行われることを確認します。合わせて、Barman がテーブルスペースもバックアップできることを確認するため、テーブルスペースも作成しておきます。
（テーブルスペース作成し、pgbenchでデータ生成する） [postgres@pgsql01 ~]$ mkdir /tmp/ssh_tbls [postgres@pgsql01 ~]$ psql << EOQ > CREATE TABLESPACE ssh_tbls LOCATION '/tmp/ssh_tbls'; > CREATE DATABASE bench TABLESPACE ssh_tbls; > EOQ [postgres@pgsql01 ~]$ pgbench -i -s 10 bench #### #### #### #### [postgres@barman ~]$ find ssh-pgsql01 -name ???????????????????????? -ls 101300493 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:06 ssh-pgsql01/incoming/000000010000000000000001 101300494 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000002 101300495 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000003 101300496 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000004 101300497 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000005 101300498 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000006 101300499 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000007 101300500 16384 -rw------- 1 postgres postgres 16777216 Oct 25 11:08 ssh-pgsql01/incoming/000000010000000000000008
barmanサーバに WAL がアーカイブされています。PostgreSQL 側で設定したアーカイブ先は /var/lib/pgsql/ssh-pgsql01/incoming ですが、自動で /var/lib/pgsql/ssh-pgsql01/wals 以下にタイムライン ID + xlogID というディレクトリ毎に分けて格納されるようです。
barman からオンラインでベースバックアップを取得します。動作検証のため、バックアップを取るときに PostgreSQLサーバでは pgbenchコマンドを適当に 60 秒ほど実行させてトランザクションが発生している状態にしておきます。
[postgres@pgsql01 ~]$ pgbench -T 60 bench #### #### #### #### [postgres@barman ~]$ barman backup --immediate-checkpoint ssh-pgsql01 Starting backup using rsync-exclusive method for server ssh-pgsql01 in /var/lib/pgsql/ssh-pgsql01/base/20181025T111311 Backup start at LSN: 0/A000070 (00000001000000000000000A, 00000070) This is the first backup for server ssh-pgsql01 WAL segments preceding the current backup have been found: 000000010000000000000001 from server ssh-pgsql01 has been removed 000000010000000000000002 from server ssh-pgsql01 has been removed 000000010000000000000003 from server ssh-pgsql01 has been removed 000000010000000000000004 from server ssh-pgsql01 has been removed 000000010000000000000005 from server ssh-pgsql01 has been removed 000000010000000000000006 from server ssh-pgsql01 has been removed 000000010000000000000007 from server ssh-pgsql01 has been removed 000000010000000000000008 from server ssh-pgsql01 has been removed 000000010000000000000009 from server ssh-pgsql01 has been removed Starting backup copy via rsync/SSH for 20181025T111311 Copy done (time: 5 seconds) This is the first backup for server ssh-pgsql01 Asking PostgreSQL server to finalize the backup. Backup size: 193.0 MiB Backup end at LSN: 0/1527D560 (000000010000000000000015, 0027D560) Backup completed (start time: 2018-10-25 11:14:59.514997, elapsed time: 7 seconds) Processing xlog segments from file archival for ssh-pgsql01 00000001000000000000000A.00000070.backup 000000010000000000000015
出力結果から、rsync と SSH によってベースバックアップが /var/lib/pgsql/ssh-pgsql01/base/20181025T111311 に取得され、不要となったアーカイブログが自動で削除されていることが読み取れます。また、テーブルスペースも格納されています。
（テーブルスペースの確認） [postgres@pgsql01 ~]$ oid2name -s All tablespaces: Oid Tablespace Name ------------------------ 1663 pg_default 1664 pg_global 16384 ssh_tbls #### #### #### #### [postgres@barman ~]$ ls ssh-pgsql01/base/20181025T111311/ 16384 backup.info data
barman コマンドからも list-backup サブコマンドにバックアップ設定を渡すと指定の設定で取得したバックアップ情報を確認することができます。バックアップ情報のうち、「20181025T111311」といったタイムスタンプは barman の各種コマンドで指定する < backup_id > で使われます。
（list-backup サブコマンドによる確認） [postgres@barman ~]$ barman list-backup ssh-pgsql01 ssh-pgsql01 20181025T111311 - Thu Oct 25 11:14:00 2018 - Size: 385.0 MiB - WAL Size: 0 B (tablespaces: ssh_tbls:/tmp/ssh_tbls) [postgres@barman ~]$ barman list-backup --minimal ssh-pgsql01 20181025T111311
パラレルジョブによるリカバリ
それでは取得したバックアップをリカバリしてみます。ここでは並列処理でのリカバリを試すことにします。リカバリ先は pgsql01 サーバですが、既存のデータベースクラスタはそのままにしておき、異なるデータベースクラスタのパスとテーブルスペースのパスを使うようにリカバリします。
--remote-ssh-command オプションを指定しないと barmanコマンドを実行したサーバでリカバリがされます。--jobs オプションでリカバリ時の並列度を指定することができます。並列度は Barman の設定ファイルでも指定可能です。なお、並列処理が有効となるのはバックアップ方法（設定ファイルの backup_method）に rsync を指定した場合のみです。
[postgres@barman ~]$ barman recover --jobs 4 --remote-ssh-command 'ssh postgres@pgsql01' --tablespace ssh_tbls:/tmp/ssh_tbls_recover ssh-pgsql01 20181025T111311 /var/lib/pgsql/10/data_recover
{{ 前略 }}
IMPORTANT
These settings have been modified to prevent data losses
postgresql.conf line 218: archive_command = false
Recovery completed (start time: 2018-10-25 14:11:10.084191, elapsed time: 17 seconds)
Your PostgreSQL server has been successfully prepared for recovery!
pgsql01 サーバにデータベースクラスタが配置されており、テーブルスペースのリンボリックリンクも正しく修正されていることが確認できます。
[postgres@pgsql01 ~]$ ls -l /var/lib/pgsql/10/data_recover/base/ total 36 drwx------. 2 postgres postgres 8192 Oct 25 11:06 1 drwx------. 2 postgres postgres 8192 Oct 25 11:06 12952 drwx------. 2 postgres postgres 8192 Oct 25 11:07 12953 [postgres@pgsql01 ~]$ ls -l /var/lib/pgsql/10/data_recover/pg_tblspc/ total 0 lrwxrwxrwx. 1 postgres postgres 21 Oct 25 14:10 16384 -> /tmp/ssh_tbls_recover
ストリーミングレプリケーションプロトコルによる WALアーカイブとベースバックアップ
今度はストリーミングレプリケーションプロトコルを使った WALアーカイブとベースバックアップを試します。
/etc/barman.d/pgsql01.conf の [streaming-pgsql01] セクションで定義したバックアップを使用します。
なお、この方法は、barman サーバ側に PostgreSQL コマンドの pg_receivewal と pg_basebackup が必要です。
事前に Barman 実行ユーザが両コマンドを使えるようにしておく必要があります。
新しいサーバ設定を実行する場合は、check サブコマンドを実行しておきます。
[postgres@barman ~]$ barman check streaming-pgsql01
先程リカバリしたデータベースクラスタ (/var/lib/pgsql/10/data_recover) のポート番号を変更し、アーカイブロギングをオフにして起動します。
（postgresql.conf設定） port = 5433 #wal_level = replica #archive_mode = on #max_wal_senders = 10 #max_replication_slots = 10
PostgreSQL を起動します。
[postgres@pgsql01 ~]$ pg_ctl -w start -D 10/data_recover
ストリーミングレプリケーションプロトコルを使って WAL をアーカイビングを開始できるようにします。まず WAL の送信元に barman 向けのレプリケーションスロットを作成し、WAL アーカイブにそれを用いるようにオプション指定します。これはオンライン WAL がアーカイブされる前にそれが再利用または削除されるのを防ぐためです。
[postgres@barman ~]$ barman receive-wal --create-slot streaming-pgsql01 Creating physical replication slot 'barman' on server 'streaming-pgsql01' Replication slot 'barman' created
レプリケーションスロットが作成されたら WAL の受信を開始します。このコマンドはフォアグランドプロセスなので、バックグラウンドに回しておきます。
（barmanによるWAL受信） [postgres@barman ~]$ barman receive-wal streaming-pgsql01 &>/dev/null & [1] 26697
PostgreSQL サーバで pgbench コマンドを適当に 30 秒ほど実行させてトランザクション進めます。
[postgres@pgsql01 ~]$ pgbench -T 30 -p 5433 bench
WAL がアーカイビングされています。
[postgres@barman ~]$ find streaming-pgsql01 -name ???????????????????????? -ls 802583 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/000000010000000000000016 433861 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/000000010000000000000017 433874 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/000000010000000000000018 433875 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/000000010000000000000019 433876 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/00000001000000000000001A 433877 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/00000001000000000000001B 433878 16384 -rw------- 1 postgres postgres 16777216 Oct 25 15:54 streaming-pgsql01/streaming/00000001000000000000001C
barman からベースバックアップを取得します。ストリーミングレプリケーションプロトコルを用いた WAL アーカイビングの場合、予め Barman のメンテナンスコマンドを実行していなければいけません。
[postgres@barman ~]$ barman archive-wal streaming-pgsql01 Processing xlog segments from streaming for streaming-pgsql01 00000001000000000000002B 00000001000000000000002C 00000001000000000000002D 00000001000000000000002E 00000001000000000000002F 000000010000000000000030 000000010000000000000031
これによって Barman サーバで受信した WAL アーカイブが、今度は Barman の wal ディレクトリにアーカイブされます。なお、この操作は barman cron サブコマンドでも可能です。cron サブコマンドの場合は Barman が管理している全てのバックアップを対象に WAL アーカイブのアーカイブ処理が行われます。加えて、追加の設定をしている場合は、WAL アーカイブの圧縮・ベースバックアップの世代管理・事前事後のフックスクリプト実行が行われます。/etc/crond.d/barman ファイルが Barman インストール時に用意されるので、定期実行したい場合はそのファイルを編集するとよいでしょう。
Barman のメンテナンスコマンドを実行したら、barman backup サブコマンドでベースバックアップの取得が行えます。
[postgres@barman ~]$ barman backup streaming-pgsql01
Starting backup using postgres method for server streaming-pgsql01 in /var/lib/pgsql/streaming-pgsql01/base/20181026T090225
Backup start at LSN: 0/4B5B0898 (00000001000000000000004B, 005B0898)
Starting backup copy via pg_basebackup for 20181026T090225
Copy done (time: 1 second)
Finalising the backup.
Backup size: 191.7 MiB
Backup end at LSN: 0/4D000000 (00000001000000000000004C, 00000000)
Backup completed (start time: 2018-10-26 09:02:25.064266, elapsed time: 1 second)
Processing xlog segments from streaming for streaming-pgsql01
00000001000000000000004B
barman コマンドの list-backup サブコマンドでバックアップが取得できていることが確認できます。
（list-backup サブコマンドによる確認） [postgres@barman ~]$ barman list-backup streaming-pgsql01 streaming-pgsql01 20181026T090225 - Fri Oct 26 09:02:27 2018 - Size: 207.7 MiB - WAL Size: 96.0 MiB (tablespaces: ssh_tbls:/tmp/ssh_tbls_recover)
任意の時点にリカバリ
それでは取得したバックアップをリカバリしてみます。PITR によって任意の時間にデータベースをリカバリしてみます。リカバリ先は pgsql01 サーバですが、既存のデータベースクラスタはそのままにしておき、異なるデータベースクラスタのパスを使うようにリカバリします。
先程ベースバックアップを取得したので、PostgreSQL サーバで pgbench を実行してトランザクションを進めます。
[postgres@pgsql01 ~]$ pgbench -T 30 -p 5433 bench
ベンチマークテーブルの pgbench_history テーブルに格納されているタイムスタンプを確認して、リカバリする時刻を決定します。
（ベンチマークの開始と終了時刻を確認）
[postgres@pgsql01 ~]$ psql -p 5433 bench
bench=# select min(mtime), max(mtime) from pgbench_history;
min | max
----------------------------+----------------------------
2018-10-26 09:02:57.827964 | 2018-10-26 09:03:27.823867
(1 row)
ここでは、リカバリ時刻を 2018-10-26 09:03:15 として、barman コマンドの recover サブコマンドでリカバリします。
[postgres@barman ~]$ barman recover --remote-ssh-command 'ssh postgres@pgsql01' --tablespace ssh_tbls:/tmp/ssh_tbls_recover02 --target-ti
me '2018-10-26 09:03:15' streaming-pgsql01 20181026T090225 /var/lib/pgsql/10/data_recover02
Starting remote restore for server streaming-pgsql01 using backup 20181026T090225
Destination directory: /var/lib/pgsql/10/data_recover02
Doing PITR. Recovery target time: '2018-10-26 09:03:15+00:00'
Using safe horizon time for smart rsync copy: 2018-10-26 08:11:09+00:00
16384, ssh_tbls, /tmp/ssh_tbls_recover02
Copying the base backup.
Copying required WAL segments.
Generating recovery.conf
Identify dangerous settings in destination directory.
IMPORTANT
These settings have been modified to prevent data losses
postgresql.conf line 219: archive_command = false
Recovery completed (start time: 2018-10-26 09:07:15.312212, elapsed time: 21 seconds)
Your PostgreSQL server has been successfully prepared for recovery!
リカバリしたデータベースクラスタ (/var/lib/pgsql/10/data_recover02) のポート番号を変更して起動し、pgbench_history テーブルに格納されているタイムスタンプの最大値を確認します。
（postgresql.conf設定）
port = 5434
#### #### #### ####
（PostgreSQL の起動）
[postgres@pgsql01 ~]$ pg_ctl -w start -D 10/data_recover02
#### #### #### ####
（ベンチマークテーブルのタイムスタンプを確認）
[postgres@pgsql01 ~]$ psql -p 5434 bench
psql (10.5)
Type "help" for help.
bench=# select min(mtime), max(mtime) from pgbench_history;
min | max
----------------------------+---------------------------
2018-10-26 09:02:57.827964 | 2018-10-26 09:03:14.99833
(1 row)
問題なく、指定の時刻までリカバリができています。
まとめ
以上、PostgreSQL の PITR 補助ツールの Barman を使って基本的なバックアップとリカバリの動作を確認しました。
複数のデータベースインスタンスの PITR を一元管理できる、煩雑な PITR 操作を簡単にできるといった点に魅力を感じるようでしたら、一度試してみてはいかがでしょうか。
Barman は以下の公式サイトから入手可能です。
[Barman]
https://www.pgbarman.org/
同サイトにマニュアルページもあります。
[Barman Manual]
http://docs.pgbarman.org/release/2.5/