ユーザーガイド(Debian/Ubuntu)
DebianおよびUbuntu向けのpgBackRestの設定と使用方法を手順に沿って説明します。
はじめに
このユーザーガイドは、各セクションが前のセクションを前提としているため、最初から順に読むことを想定しています。たとえば、リストア
のセクションは、クイックスタート
で行う設定を前提としています。pgBackRestを起動して運用できるようになった後は必要な箇所を参照できますが、初回は順に読み進めることをお勧めします。
このガイドの例はDebian/UbuntuとPostgreSQL 17を対象としていますが、どのUnixディストリビューションやPostgreSQLバージョンにも比較的容易に応用できます。OS固有のコマンドは、PostgreSQLクラスターの作成、起動、停止、削除に使うものだけです。pgBackRestのコマンドはどのUnixシステムでも同じですが、実行ファイルの場所は異なる場合があります。pgBackRestはPostgreSQLの各バージョンで一貫した動作を目指していますが、PostgreSQLのパス名、ファイル名、設定など、バージョン間の微妙な違いがこのガイドの例に現れる場合があります。
PostgreSQLの設定情報とドキュメントは、PostgreSQLのマニュアル
を参照してください。
このユーザーガイドでは、ドキュメントの作成に少し変わった方法を採用しています。XMLソースからドキュメントをビルドする際、各コマンドを仮想マシンで実行します。そのため、記載された順序でコマンドが正しく動作することを高い確度で期待できます。必要に応じて出力を取得し、コマンドの下に表示しています。出力を載せていないのは、説明に関係しないか、説明の妨げになると判断したためです。
すべてのコマンドは、rootとpostgresの両ユーザーに対するsudo権限を持つ一般ユーザーで実行することを想定しています。各コマンドは対応するユーザーで直接実行することもでき、その場合はsudoの部分を取り除くだけで、ほかの変更は不要です。
概念
ここでは、pgBackRest、PostgreSQL、およびこのユーザーガイドに関係する概念を定義します。
バックアップ
バックアップとは、データベースクラスターの整合性のあるコピーです。リストアすることで、ハードウェア障害からの復旧、ポイントインタイムリカバリー、新しいスタンバイの起動に利用できます。
フルバックアップ :pgBackRestはデータベースクラスターの内容全体をバックアップにコピーします。データベースクラスターの最初のバックアップは必ずフルバックアップになります。pgBackRestはフルバックアップを常に直接リストアできます。フルバックアップの整合性は、そのバックアップ外のファイルに依存しません。
差分バックアップ :pgBackRestは、最後のフルバックアップ以降に変更されたデータベースクラスターのファイルだけをコピーします。差分バックアップのリストアでは、選択した差分バックアップの全ファイルと、その前のフルバックアップに含まれる変更のない該当ファイルをコピーします。差分バックアップはフルバックアップより少ないディスク容量で済みますが、リストアするには差分バックアップとフルバックアップの両方が有効でなければなりません。
増分バックアップ :pgBackRestは、最後のバックアップ(増分、差分、フルのいずれか)以降に変更されたデータベースクラスターのファイルだけをコピーします。増分バックアップには直前のバックアップ以降に変更されたファイルしか含まれないため、通常はフルバックアップや差分バックアップより大幅に小さくなります。差分バックアップと同様、増分バックアップのリストアには、依存先のバックアップも有効である必要があります。増分バックアップには最後のバックアップ以降のファイルしか含まれないため、リストアするには、前の差分バックアップまでさかのぼるすべての増分バックアップ、その差分バックアップ、およびその前のフルバックアップがすべて有効でなければなりません。差分バックアップが存在しない場合は、必ず存在する前のフルバックアップまでのすべての増分バックアップと、そのフルバックアップ自体が有効でなければなりません。
リストア
リストアとは、稼働するデータベースクラスターとして起動するシステムに、バックアップをコピーする操作です。正しくリストアするには、バックアップファイルと1つ以上のWALセグメントが必要です。
先行書き込みログ(WAL)
WALは、コミット済みの変更が失われないことをPostgreSQLが保証するための仕組みです。トランザクションはWALに順次書き込まれ、その書き込みがディスクにフラッシュされるとコミットされたとみなされます。その後、バックグラウンドプロセスが変更をデータベースクラスターの本体ファイル(ヒープとも呼ばれます)に書き込みます。クラッシュ時にはWALを再生して、データベースの整合性を回復します。
WALは概念上は無限に続きますが、実際にはセグメントと呼ばれる16MBの個別ファイルに分割されます。WALセグメントの名前は0000000100000A1E000000FEという形式で、先頭の16進数8桁がタイムライン、続く16桁が論理シーケンス番号(LSN)を表します。
暗号化
暗号化とは、適切なパスワード(パスフレーズとも呼ばれます)を指定しない限り認識できない形式にデータを変換する処理です。
pgBackRestはユーザーが指定したパスワードに基づいてリポジトリを暗号化し、リポジトリ内のデータへの不正アクセスを防ぎます。
pgBackRestのアップグレード
pgBackRestをv2.xからv2.yにアップグレードする
v2.xからv2.yへのアップグレードは簡単です。リポジトリ形式は変わっていないため、ほとんどの環境では新しいバージョンのバイナリをインストールするだけで済みます。古いバージョンでサポートされていない新機能を使用していなければ、ダウングレードも可能です。
重要:
ローカルとリモートのpgBackRestのバージョンは完全に一致する必要があるため、同時にアップグレードすることをお勧めします。一致しない場合、バージョンが揃うまでWALアーカイブとバックアップは動作しません。その場合、次のエラーが報告されます:[ProtocolError] expected value '2.x' for greeting key 'version' but got '2.y'。
ビルド
pgBackRestはソースからビルドするより、パッケージからインストールすることをお勧めします。パッケージの詳細はインストール
を参照してください。
ソースからビルドする場合は、本番環境ではなくビルド用ホストを使うことをお勧めします。ビルドに必要なツールの多くは、通常、本番環境にはインストールしないほうがよいものです。pgBackRestは単一の実行ファイルで構成されるため、ビルド後は簡単に別のホストにコピーできます。
build ⇒ pgBackRestのバージョン2.59.3を/buildパスにダウンロードする
mkdir -p /build
curl -fsSL \
https://github.com/pgbackrest/pgbackrest/releases/download/release%2F2.59.3/pgbackrest-2.59.3.tar.gz | \
tar zx -C /build
build ⇒ ビルドの依存パッケージをインストールする
sudo apt-get install python3-distutils meson gcc libpq-dev libssl-dev libxml2-dev \
pkg-config liblz4-dev libzstd-dev libbz2-dev libz-dev libssh2-1-dev libsystemd-dev
build ⇒ pgBackRestのビルドを設定してコンパイルする
meson setup /build/pgbackrest /build/pgbackrest-2.59.3
ninja -C /build/pgbackrest
build ⇒ 必要に応じてスモークテストを実行し、pgBackRestが正しくビルドされたことを確認する
meson test -C /build/pgbackrest --suite smoke
ninja: Entering directory `/build/pgbackrest'
ninja: no work to do.
1/1 smoke OK 11.07s
[filtered 7 lines of output]
インストール
デモクラスターを配置してpgBackRestの例を実行するために、pg-primaryという新しいホストを作成します。
pgBackRestはソースからビルドするより、パッケージからインストールすることをお勧めします。パッケージからインストールする場合、このセクションの残りの手順は通常不要ですが、パッケージが一部のディレクトリを作成しなかったり、誤った権限を設定したりする可能性があります。その場合は、手動でディレクトリを作成したり権限を更新したりする必要がある場合があります。
pgBackRestのDebian/Ubuntuパッケージはapt.postgresql.org
から入手できます。
使用するディストリビューションやバージョン向けのパッケージがない場合は、ソースからビルド
し、ここに示す手順で手動インストールできます。
pg-primary ⇒ 依存パッケージをインストールする
sudo apt-get install postgresql-client libxml2 libssh2-1
pg-primary ⇒ ビルド用ホストからpgBackRestバイナリをコピーする
sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest
pgBackRestには、ログディレクトリ、設定ディレクトリ、設定ファイルが必要です。
pg-primary ⇒ pgBackRestの設定ファイルとディレクトリを作成する
sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf
これでpgBackRestは正しくインストールされているはずですが、確認することをお勧めします。依存パッケージに不足があると、コマンドラインからpgBackRestを実行した際にエラーが発生します。
pg-primary ⇒ インストールが成功したことを確認する
sudo -u postgres pgbackrest
pgBackRest 2.59.3 - General help
Usage:
pgbackrest [options] [command]
Commands:
annotate add or modify backup annotation
archive-get get a WAL segment from the archive
archive-push push a WAL segment to the archive
backup backup a database cluster
check check the configuration
expire expire backups that exceed retention
help get help
info retrieve information about backups
repo-get get a file from a repository
repo-ls list files in a repository
restore restore a database cluster
server pgBackRest server
server-ping ping pgBackRest server
stanza-create create the required stanza data
stanza-delete delete a stanza
stanza-upgrade upgrade a stanza
start allow pgBackRest processes to run
stop stop pgBackRest processes from running
verify verify contents of a repository
version get version
Use 'pgbackrest help [command]' for more information.
クイックスタート
クイックスタートでは、pgBackRestとPostgreSQLの基本設定を行い、backup、restore、infoコマンドを紹介します。
デモクラスターのセットアップ
デモクラスターの作成は任意ですが、このユーザーガイドのコマンド例がデモクラスターを参照するため、特に初めて使用する場合は作成を強くお勧めします。例では、デモクラスターがデフォルトのポート(5432)で稼働していることを前提としています。まだ設定が必要なため、クラスターの起動は後のセクションで行います。
pg-primary ⇒ デモクラスターを作成する
sudo -u postgres /usr/lib/postgresql/17/bin/initdb \
-D /var/lib/postgresql/17/demo -k -A peer
sudo pg_createcluster 17 demo
Configuring already existing cluster (configuration: /etc/postgresql/17/demo, data: /var/lib/postgresql/17/demo, owner: 102:103)
Ver Cluster Port Status Owner Data directory Log file
17 demo 5432 down postgres /var/lib/postgresql/17/demo /var/log/postgresql/postgresql-17-demo.log
stanzaは、PostgreSQLデータベースクラスターの場所、バックアップ方法、アーカイブオプションなどを定義する設定です。ほとんどのデータベースサーバーにはPostgreSQLデータベースクラスターが1つしかないためstanzaも1つですが、バックアップサーバーにはバックアップ対象のデータベースクラスターごとにstanzaがあります。
stanzaにプライマリークラスターの名前を付けたくなるかもしれませんが、クラスターに含まれるデータベースを表す名前のほうが適切です。stanza名はプライマリーとすべてのレプリカで使うため、mainやprodのようなローカルクラスター名ではなく、appやdwのようにクラスターの実際の用途を表す名前を選ぶのが適切です。
「demo」はこのクラスターの目的を正確に表しているため、stanza名にも適しています。
pgBackRestは、PostgreSQLクラスターの基本データディレクトリの場所を知る必要があります。このパスはPostgreSQLに直接問い合わせることもできますが、リカバリー時にはPostgreSQLプロセスを利用できません。バックアップ時には、pgBackRestに指定された値をPostgreSQLが稼働しているパスと比較し、一致しなければエラーになります。pg-pathがPostgreSQLの報告するdata_directoryと完全に一致していることを確認してください。
Debian/Ubuntuではデフォルトでクラスターを/var/lib/postgresql/[version]/[cluster]に保存するため、正しいデータディレクトリのパスを容易に判断できます。
/etc/pgbackrest/pgbackrest.confファイルを作成する際は、データベース所有者(通常はpostgres)に読み取り権限を付与する必要があります。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ PostgreSQLクラスターのデータディレクトリを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
pgBackRestの設定ファイルはWindowsのINIファイルに似た形式を使用します。セクションは角括弧で囲んだテキストで表し、各セクションにキーと値のペアを記述します。#で始まる行は無視されるためコメントに使用できますが、値と同じ行の末尾にコメントを付けることはできません。引用符による囲みはサポートされず、キーと値の前後の空白は除去されます。同じセクションが複数回現れた場合は統合されます。
pgBackRestの設定ファイルは、次のいずれかの方法で読み込めます。
configとconfig-include-pathがデフォルトの場合:デフォルトの設定ファイルが存在すれば読み込み、デフォルトの設定インクルードパスに*.confファイルが存在すれば追加します。
configオプションが指定されている場合:指定された設定ファイルだけを読み込みます。このファイルは存在する必要があります。
config-include-pathが指定されている場合:設定インクルードパスの*.confファイルを読み込みます。このパスは存在する必要があります。デフォルトの設定ファイルも、存在すれば読み込みます。指定した設定インクルードパスのファイルだけを読み込むには、--no-configオプションも指定します。
configとconfig-include-pathが指定されている場合:ユーザー指定の値を使って設定ファイルを読み込み、設定インクルードパスの*.confファイルを追加します。これらのファイルは存在する必要があります。
config-pathが指定されている場合:この設定は、設定ファイルのデフォルト配置先のベースパスと、デフォルトのconfig-include-path設定のベースパスの一方または両方を上書きします。ただし、configまたはconfig-include-pathオプションを明示的に設定した場合は、その設定が優先されます。
ファイルは1つの大きなファイルとして連結されますが、各ファイルは単独でも有効でなければなりません。つまり、キーと値を格納するセクションは、必要となる各ファイルで指定する必要があります。順序は関係ありませんが、セクションによる優先順位があります。優先順位は高い順に次のとおりです。
[stanza :command ]
[stanza ]
[global:command ]
[global]
注:
--config、--config-include-path、--config-pathはコマンドライン専用のオプションです。
pgBackRestは環境変数でも設定できます(下の例を参照)。これらの変数はbackup
、restore
、archive-push
などのコマンドに適用されます。
pg-primary ⇒ 環境変数でlog-pathを設定する
sudo -u postgres bash -c ' \
export PGBACKREST_LOG_PATH=/path/set/by/env && \
pgbackrest --log-level-console=error help backup log-path'
pgBackRest 2.59.3 - 'backup' command - 'log-path' option help
Path where log files are stored.
The log path provides a location for pgBackRest to store log files. Note that
if log-level-file=off then no log path is required.
current: /path/set/by/env
default: /var/log/pgbackrest
リポジトリの作成
リポジトリは、pgBackRestがバックアップを保存し、WALセグメントをアーカイブする場所です。
必要な容量を事前に見積もるのは難しい場合があります。まず何度かバックアップを取り、各種類(full/incr/diff)のバックアップサイズを記録するとともに、1日あたりのWAL生成量を測定するのが最善です。これで必要容量のおおよその見当が付きますが、もちろんデータベースの変化に伴って必要容量も変わる可能性があります。
このデモでは、PostgreSQLサーバーと同じホストにリポジトリを保存します。これは最も単純な構成で、従来のバックアップソフトウェアでデータベースホストをバックアップする場合に有用です。
pg-primary ⇒ pgBackRestのリポジトリを作成する
sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest
pgBackRestがリポジトリを見つけられるよう、リポジトリのパスを設定する必要があります。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRestのリポジトリパスを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-path = /var/lib/pgbackrest
複数のリポジトリも設定できます。詳細は複数のリポジトリ
を参照してください。
稼働中のPostgreSQLクラスターをバックアップするには、WALアーカイブを有効にする必要があります。%pは、PostgreSQLがアーカイブ対象のWALセグメントの場所を指定する方法です。クラスターに明示的な書き込みがなくても、バックアップ中には少なくとも 1つのWALセグメントが作成されます。
pg-primary:/etc/postgresql/17/demo/postgresql.conf ⇒ アーカイブを設定する
archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
これらの変更後、バックアップを実行する前にPostgreSQLクラスターを再起動する必要があります。
pg-primary ⇒ デモクラスターを再起動する
sudo pg_ctlcluster 17 demo restart
hot_standbyはデフォルトで有効になっており、すべてのクラスターで有効のままにしておくことをお勧めします。フェイルオーバー後にプライマリーをスタンバイとして再構築する場合など、どのクラスターも後でスタンバイとしてリストアされる可能性があり、この設定がないとスタンバイは読み取り専用接続を受け付けません。
WALセグメントをpgBackRestリポジトリにアーカイブするのに60秒(デフォルト)を超える時間がかかると予想される場合は、pgBackRestのarchive-timeoutオプションを増やすことをお勧めします。このオプションは、WALセグメントの切り替えを強制するPostgreSQLのarchive_timeoutオプションとは異なります。後者は、長時間操作がないデータベースに有用です。PostgreSQLのarchive_timeoutオプションの詳細は、PostgreSQLの先行書き込みログ
を参照してください。
archive-pushコマンドには固有のオプションを設定できます。たとえば、バックアップの圧縮には影響を与えずに、圧縮レベルを下げてアーカイブを高速化できます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ archive-pushの圧縮レベルを低く設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-path = /var/lib/pgbackrest
[global:archive-push]
compress-level = 3
この設定方法はどのコマンドにも使用でき、demo:archive-pushのように特定のstanzaだけを対象にすることもできます。
pgBackRestは保持オプションに基づいてバックアップを期限切れにします。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ フルバックアップを2つ保持するよう設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
[global:archive-push]
compress-level = 3
保持の詳細は保持
を参照してください。
暗号化の例として、リポジトリに暗号方式とキーを設定します。リポジトリの種類(S3などのオブジェクトストア)が暗号化に対応している場合でも、暗号化は常にクライアント側で行います。
暗号キーには、長くランダムなパスフレーズを使用することが重要です。生成するにはopenssl rand -base64 48を実行する方法が適しています。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRestリポジトリの暗号化を設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
[global:archive-push]
compress-level = 3
注:
上の例では、infoコマンドがすべてのstanzaを読み込めるよう、暗号化設定を[global]セクションに記述しています。stanzaオプションを指定しない場合、infoコマンドは[global]セクションからのみ暗号化設定を読み込みます。stanzaごとに暗号化を設定した場合は、暗号化されたstanzaを読み込むためにstanzaオプションが必要です。
リポジトリを設定し、stanzaを作成して確認した後は、リポジトリの暗号化設定を変更できません。
stanzaの作成
stanzaを初期化するには、stanza-createコマンドを実行する必要があります。アーカイブとバックアップが正しく設定されていることを確認するため、stanza-createの後にcheckコマンドを実行することをお勧めします。
pg-primary ⇒ stanzaを作成して設定を確認する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info stanza-create
P00 INFO: stanza-create command begin 2.59.3: --exec-id=415-9c2d1500 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00 INFO: stanza-create for stanza 'demo' on repo1
P00 INFO: stanza-create command end: completed successfully
設定の確認
checkコマンドは、指定されたstanzaのアーカイブとバックアップについて、pgBackRestとarchive_commandが正しく設定されていることを検証します。コマンドを実行するホストに設定された、すべてのリポジトリとデータベースの確認を試みます。特にアーカイブの設定ミスにより、必要なWALセグメントがアーカイブに届かずバックアップが不完全になる問題を検出します。このコマンドはPostgreSQLホストまたはリポジトリホストで実行できます。スタンバイホストでも実行できますが、スタンバイではpg_switch_xlog()/pg_switch_wal()を実行できないため、リポジトリの設定だけを検証します。
PostgreSQLにWALセグメントを強制的にアーカイブさせるため、pg_create_restore_point('pgBackRest Archive Check')とpg_switch_xlog()/pg_switch_wal()が呼び出されます。
pg-primary ⇒ 設定を確認する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info check
P00 INFO: check command begin 2.59.3: --exec-id=424-7270037b --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00 INFO: check repo1 configuration (primary)
P00 INFO: check repo1 archive for WAL (primary)
P00 INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000100000000/000000010000000000000001-e8eb01b8d8aaf321d368dc8edf5b559247841eb1.gz' on repo1
P00 INFO: check command end: completed successfully
pgBackRestには、リポジトリの後方互換性を維持するため、デフォルトでは無効になっている性能関連のオプションがあります。ただし、新しいリポジトリを作成する場合は、次のオプションをお勧めします。既存のリポジトリにも使用できますが、古いバージョンのpgBackRestではそのリポジトリを読み込めなくなる点に注意してください。どのバージョンと互換性がなくなるかは、以下に示す各機能の導入時期によって異なります。
compress-type - backupとarchive-pushコマンドで使用する圧縮アルゴリズムを決めます。デフォルトはgz(Gzip)ですが、はるかに高速でgzと同程度の圧縮率が得られるzst(Zstandard)をお勧めします。compress-typeオプションはv2.27
からzstに対応しています。詳細は圧縮形式
を参照してください。
repo-bundle - バックアップ時に小さなファイルをまとめ、容量を節約し、backupとrestoreの両コマンドを高速化します。特にS3などのオブジェクトストアで効果があります。repo-bundleオプションはv2.39
で導入されました。詳細はファイルのバンドル化
を参照してください。
repo-block - diff/incrのbackupで、ファイル全体ではなく変更された部分だけを保存します。これにより容量を節約し、backupを高速化できます。repo-blockオプションはv2.46
で導入されましたが、少なくともv2.52.1
をお勧めします。詳細はブロック単位の増分バックアップ
を参照してください。
このほかにも、追加設定が必要なため、またはデフォルトが安全な値(ただし最適ではない値)であるため、デフォルトでは有効になっていない性能関連のオプションがあります。これらはpgBackRestのすべてのv2バージョンで利用できます。
process-max - コマンドに使用するプロセス数を決めます。デフォルトは1ですが、この値が適切なことはほとんどありません。process-maxの使い方はコマンドごとに異なるため、使用方法の詳細は各コマンドのドキュメントを参照してください。
archive-async - WALファイルをまとめてリポジトリにアーカイブし、アーカイブを大幅に高速化します。スプールパスを作成する必要があるため、デフォルトでは無効です。詳細は非同期アーカイブ
を参照してください。
backup-standby - プライマリーの負荷を減らすため、プライマリーではなくスタンバイでバックアップを実行します。追加設定と1つ以上のスタンバイホストが必要なため、デフォルトでは無効です。詳細はスタンバイからのバックアップ
を参照してください。
pgBackRestはデフォルトで、次の定期チェックポイントを待ってからバックアップを開始します。PostgreSQLのcheckpoint_timeoutとcheckpoint_segmentsの設定によっては、チェックポイントが完了してバックアップを開始できるまでにかなり時間がかかる場合があります。通常は、すぐにバックアップが始まるようstart-fast=yを設定することをお勧めします。これによりチェックポイントが強制されますが、バックアップは通常1日1回実行するため、追加のチェックポイントが性能に目立った影響を与えることはないはずです。ただし、非常に負荷の高いクラスターでは、必要に応じてコマンドラインで--start-fastを指定するほうがよい場合があります。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ バックアップの即時開始を設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
PostgreSQLクラスターのバックアップを行うには、pgBackRestのbackupコマンドを実行します。
pg-primary ⇒ デモクラスターをバックアップする
sudo -u postgres pgbackrest --stanza= demo \
--log-level-console= info backup
P00 INFO: backup command begin 2.59.3: --exec-id=451-67e8eca3 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo --start-fast
P00 WARN: no prior backup exists, incr backup has been changed to full
P00 INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00 INFO: backup start archive = 000000010000000000000002, lsn = 0/2000028
[filtered 3 lines of output]
P00 INFO: check archive for segment(s) 000000010000000000000002:000000010000000000000003
P00 INFO: new backup label = 20261002-190624F
P00 INFO: full backup size = 22MB, file total = 963
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=451-67e8eca3 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo
pgBackRestはデフォルトで増分バックアップの実行を試みます。ただし、増分バックアップには基となるフルバックアップが必要です。この例ではフルバックアップが存在しなかったため、pgBackRestは代わりにフルバックアップを実行しました。
typeオプションでフルバックアップまたは差分バックアップを指定できます。
pg-primary ⇒ デモクラスターの差分バックアップを取る
sudo -u postgres pgbackrest --stanza= demo --type= diff \
--log-level-console= info backup
[filtered 7 lines of output]
P00 INFO: check archive for segment(s) 000000010000000000000004:000000010000000000000005
P00 INFO: new backup label = 20261002-190624F_20261002-190626D
P00 INFO: diff backup size = 8.3KB, file total = 963
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=477-af59c897 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo
今回はフルバックアップがすでに存在していたため、警告はありませんでした。増分バックアップはフルバックアップまたは 差分バックアップを基にできますが、差分バックアップはフルバックアップを基にする必要があります。フルバックアップを実行するには、backupコマンドに--type=fullを指定します。
オンラインバックアップ中、pgBackRestはバックアップの整合性に必要なWALセグメントがアーカイブされるのを待ちます。この待機時間は、デフォルトで60秒のpgBackRestのarchive-timeoutオプションで制御します。個々のセグメントのアーカイブにこの時間を超えることが分かっている場合は、この値を増やすことをお勧めします。
バックアップのスケジュール
cronなどのユーティリティで、バックアップをスケジュールできます。
次の例では2つのcronジョブを設定します。毎週日曜日の午前6:30にフルバックアップを実行し、月曜日から土曜日の午前6:30に差分バックアップを実行します。このcrontabを週の途中で初めて設定した場合、pgBackRestは差分バックアップのジョブが最初に実行されるときにフルバックアップを行い、翌日から差分バックアップを行います。
#m h dom mon dow command
30 06 * * 0 pgbackrest --type= full --stanza= demo backup
30 06 * * 1-6 pgbackrest --type= diff --stanza= demo backup
バックアップをスケジュールしたら、定期的に期限切れになるよう保持設定を行うことが重要です。保持
を参照してください。
バックアップの情報を取得するには、infoコマンドを使用します。
pg-primary ⇒ デモクラスターの情報を取得する
sudo -u postgres pgbackrest info
stanza: demo
status: ok
cipher: aes-256-cbc
db (current)
wal archive min/max (17): 000000010000000000000001/000000010000000000000005
full backup: 20261002-190624F
timestamp start/stop: 2026-10-02 19:06:24+00 / 2026-10-02 19:06:26+00
wal start/stop: 000000010000000000000002 / 000000010000000000000003
database size: 22MB, database backup size: 22MB
repo1: backup set size: 2.9MB, backup size: 2.9MB
diff backup: 20261002-190624F_20261002-190626D
timestamp start/stop: 2026-10-02 19:06:26+00 / 2026-10-02 19:06:28+00
wal start/stop: 000000010000000000000004 / 000000010000000000000005
database size: 22MB, database backup size: 8.3KB
repo1: backup set size: 2.9MB, backup size: 448B
backup reference total: 1 full
infoコマンドは、単一のstanzaまたはすべてのstanzaを対象に動作します。デフォルトのテキスト出力では、指定したstanzaのバックアップ概要を人が読みやすい形式で表示します。この形式は、どのリリースでも変更される可能性があります。
機械処理用の出力には--output=jsonを使用します。JSON出力にはテキスト出力よりはるかに多くの情報が含まれ、バグが見つからない限り安定した形式を維持します。
実行を高速化するには、--detail-level=progressを指定して、進捗情報だけに出力を限定します。この場合、stanzaの可用性以外のすべての確認が省略される点に注意してください。
stanzaごとに個別のセクションがあり、--stanzaオプションで単一のstanzaに出力を限定できます。stanzaの「status」は、そのstanzaの健全性を簡潔に示します。「ok」ならpgBackRestは正常に動作しています。複数のリポジトリがある場合、「mixed」は1つ以上のリポジトリでstanzaが正常でないことを示し、リポジトリごとに状態の詳細が表示されます。リポジトリで既知のエラーコードに該当しないエラーが発生した場合は、エラーコード「other」を使用し、完全なエラー詳細を表示します。「wal archive min/max」は、現在アーカイブに保存されているWALの最小値と最大値です。複数のリポジトリがある場合、--repoオプションを指定しない限り、全リポジトリを通して報告されます。アーカイブ保持ポリシーなどの理由で、途中に欠落がある場合もあります。
ホスト上で該当コマンドが実行中の場合は、「status」情報の横に「backup/expire running」や「restore running」が表示されます。テキスト出力にはリポジトリごとの進捗も表示され、JSON出力には「repo」配列が含まれます。
バックアップは古い順に表示されます。最も古いバックアップは必ず フルバックアップ(ラベル末尾のFで識別)ですが、最新のバックアップはフル、差分(末尾がD)、増分(末尾がI)のいずれかです。
「timestamp start/stop」は、バックアップが実行された期間を示します。「timestamp stop」は、ポイントインタイムリカバリーで使用するバックアップの選択に利用できます。ポイントインタイムリカバリーの詳細は、ポイントインタイムリカバリー
を参照してください。
「wal start/stop」は、リストア時にデータベースの整合性を回復するために必要なWALの範囲を示します。backupコマンドは、完了前にこの範囲のWALがアーカイブに存在することを確認します。
「database size」はデータベース全体の非圧縮サイズで、「database backup size」は実際にバックアップするデータベース内のデータ量です(フルバックアップでは両者は同じです)。
「repo」は、このバックアップを保存しているリポジトリを示します。「backup set size」には、このバックアップからデータベースをリストアするために必要な、このバックアップ自身と参照先バックアップのリポジトリ内の全ファイルが含まれます。一方、「backup size」には、このバックアップのファイルだけが含まれます(フルバックアップではこれらも同じです)。pgBackRestで圧縮を有効にしている場合、リポジトリのサイズは圧縮後のファイルサイズを表します。
「backup reference total」は、このバックアップのリストアに必要な追加バックアップの一覧の概要です。完全な参照一覧を表示するには、--setオプションを使用します。
バックアップのリストア
バックアップはさまざまな障害に備えるためのもので、特に一般的なのはハードウェア障害とデータ破損です。データ破損を最も簡単に再現する方法は、PostgreSQLクラスターの重要なファイルを削除することです。
pg-primary ⇒ デモクラスターを停止し、pg_controlファイルを削除する
sudo pg_ctlcluster 17 demo stop
sudo -u postgres rm /var/lib/postgresql/17/demo/global/pg_control
この重要なファイルがない状態でクラスターを起動すると、エラーになります。
pg-primary ⇒ 破損したデモクラスターの起動を試みる
sudo pg_ctlcluster 17 demo start
Error: /usr/lib/postgresql/17/bin/pg_ctl /usr/lib/postgresql/17/bin/pg_ctl start -D /var/lib/postgresql/17/demo -l /var/log/postgresql/postgresql-17-demo.log -s -o -c config_file="/etc/postgresql/17/demo/postgresql.conf" exited with status 1:
postgres: could not find the database system
Expected to find it in the directory "/var/lib/postgresql/17/demo",
but could not open file "/var/lib/postgresql/17/demo/global/pg_control": No such file or directory
Examine the log output.
PostgreSQLクラスターのバックアップをリストアするには、pgBackRestのrestoreコマンドを実行します。クラスターを停止し(この例ではすでに停止しています)、PostgreSQLのデータディレクトリからすべてのファイルを削除する必要があります。
pg-primary ⇒ デモクラスターから古いファイルを削除する
sudo -u postgres find /var/lib/postgresql/17/demo -mindepth 1 -delete
pg-primary ⇒ デモクラスターをリストアしてPostgreSQLを起動する
sudo -u postgres pgbackrest --stanza= demo restore
sudo pg_ctlcluster 17 demo start
リストアにより欠落していたpg_controlファイルが復元されたため、今回はクラスターが正常に起動しました。
restoreコマンドの詳細はリストア
を参照してください。
監視
監視は、どの本番システムでも重要です。多くのツールがあり、少し手を加えれば、そのいずれでもpgBackRestを監視できます。
pgBackRestはリポジトリの情報をJSON形式で出力できます。この情報には、各stanzaのすべてのバックアップの一覧とWALアーカイブ情報が含まれます。
PostgreSQLでの監視
PostgreSQLのCOPYコマンドを使うと、pgBackRestの情報をテーブルに読み込めます。次の例では、この処理をリアルタイムのクエリーに使える関数にまとめています。
pg-primary ⇒ PostgreSQL用のpgBackRest情報関数を読み込む
sudo -u postgres cat \
/var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql
-- An example of monitoring pgBackRest from within PostgreSQL
--
-- Use copy to export data from the pgBackRest info command into the jsonb
-- type so it can be queried directly by PostgreSQL.
-- Create monitor schema
create schema monitor;
-- Get pgBackRest info in JSON format
create function monitor.pgbackrest_info()
returns jsonb AS $$
declare
data jsonb;
begin
-- Create a temp table to hold the JSON data
create temp table temp_pgbackrest_data (data text);
-- Copy data into the table directly from the pgBackRest info command
copy temp_pgbackrest_data (data)
from program
'pgbackrest --output=json info' (format text);
select replace(temp_pgbackrest_data.data, E'\n', '\n')::jsonb
into data
from temp_pgbackrest_data;
drop table temp_pgbackrest_data;
return data;
end $$ language plpgsql;
sudo -u postgres psql -f \
/var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql
これでmonitor.pgbackrest_info()関数を使って、stanzaの最後に成功したバックアップの時刻と、アーカイブされたWALを確認できます。
pg-primary ⇒ 最後に成功したバックアップの時刻とアーカイブされたWALを取得する
sudo -u postgres cat \
/var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
-- Get last successful backup for each stanza
--
-- Requires the monitor.pgbackrest_info function.
with stanza as
(
select data->'name' as name,
data->'backup'->(
jsonb_array_length(data->'backup') - 1) as last_backup,
data->'archive'->(
jsonb_array_length(data->'archive') - 1) as current_archive
from jsonb_array_elements(monitor.pgbackrest_info()) as data
)
select name,
to_timestamp(
(last_backup->'timestamp'->>'stop')::numeric) as last_successful_backup,
current_archive->>'max' as last_archived_wal
from stanza;
sudo -u postgres psql -f \
/var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
name | last_successful_backup | last_archived_wal
--------+------------------------+--------------------------
"demo" | 2026-10-02 19:06:28+00 | 000000010000000000000005
(1 row)
jqの使用
jqは、JSONから簡単にデータを抽出できるコマンドラインユーティリティです。
pg-primary ⇒ jqユーティリティをインストールする
これでjqを使って、stanzaの最後に成功したバックアップの時刻を取得できます。
pg-primary ⇒ 最後に成功したバックアップの時刻を取得する
sudo -u postgres pgbackrest --output= json --stanza= demo info | \
jq '.[0] | .backup[-1] | .timestamp.stop'
最後にアーカイブされたWALも取得できます。
pg-primary ⇒ 最後にアーカイブされたWALを取得する
sudo -u postgres pgbackrest --output= json --stanza= demo info | \
jq '.[0] | .archive[-1] | .max'
"000000010000000000000005"
注:
この構文にはjq v1.5が必要です。
注:
jqはシステム識別子などの大きな数値を丸める場合があります。クエリーを慎重にテストしてください。
バックアップ
複数のリポジトリが設定されている場合、pgBackRestは--repoオプションを指定しない限り、最も優先順位の高いリポジトリ(例:repo1)にバックアップします。
pgBackRestにはスケジューラーが組み込まれていないため、cronなどのスケジュール機構から実行することをお勧めします。
詳細と例はバックアップの実行
を参照してください。
ファイルのバンドル化
リポジトリ内でファイルをまとめると、バックアップの時間を短縮し、リポジトリの容量もある程度節約できます。特に、S3などのオブジェクトストアやブロックサイズの大きなファイルシステムにリポジトリを保存する場合に効果があります。オブジェクトストアではファイルごとの作成時間が長く、非常に小さなファイルでも大きなファイルと同程度の保存コストがかかる場合があります。
ファイルのバンドル化は、repo-bundleオプションで有効にします。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-bundleを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
ファイルをバンドル化しないフルバックアップでは、バックアップパスに1000以上のファイルがありますが、バンドル化するとファイル総数は大幅に減ります。さらに、通常のバックアップでは長さゼロのファイルも個別に保存するのに対し、バンドル化ではマニフェストへの記録を除いて保存しないという利点もあります。
pg-primary ⇒ フルバックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= full backup
pg-primary ⇒ ファイル総数を確認する
sudo -u postgres find /var/lib/pgbackrest/backup/demo/latest/ -type f | wc -l
repo-bundle-sizeとrepo-bundle-limitオプションで調整できますが、ほとんどの場合はデフォルト値が最適なはずです。
ファイルのバンドル化は一般に効率的ですが、リポジトリからファイルを手動で取り出しにくくなるという欠点があります。フルバックアップのたびにバンドル内のファイル配置が変わるため、重複排除ストレージには適さない場合があります。また、ファイルバンドルの処理は中断位置から再開できないため、repo-bundle-limitを大きくしすぎないよう注意してください。
ブロック単位の増分バックアップ
ブロック単位の増分バックアップでは、ファイル全体ではなく、前のバックアップ以降に変更された部分だけを保存して容量を節約します。
ブロック単位の増分バックアップはrepo-blockオプションで有効にし、すべてのバックアップ種類で有効にすると最も効果的です。ファイルのバンドル化も有効にする必要があります。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-blockを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
バックアップの注釈
バックアップに情報を記したキーと値のペアを付けられます。このオプションは複数回指定でき、複数の注釈を付けられます。
pg-primary ⇒ 注釈付きのフルバックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --annotation= source = "demo backup" \
--annotation= key = value --type= full backup
注釈は、infoコマンドで--setによりバックアップを指定した場合にテキスト出力に表示され、JSON出力には常に表示されます。
pg-primary ⇒ デモクラスターの情報を取得する
sudo -u postgres pgbackrest --stanza= demo --set= 20261002-190643F info
stanza: demo
status: ok
cipher: aes-256-cbc
db (current)
wal archive min/max (17): 000000020000000000000007/000000020000000000000009
full backup: 20261002-190643F
timestamp start/stop: 2026-10-02 19:06:43+00 / 2026-10-02 19:06:44+00
wal start/stop: 000000020000000000000008 / 000000020000000000000009
lsn start/stop: 0/8000028 / 0/9000050
database size: 22MB, database backup size: 22MB
repo1: backup size: 2.9MB
database list: postgres (5)
annotation(s)
key: value
source: demo backup
backupコマンドで付けた注釈は、後でannotateコマンドを使って追加、変更、削除できます。
pg-primary ⇒ バックアップの注釈を変更する
sudo -u postgres pgbackrest --stanza= demo --set= 20261002-190643F \
--annotation= key = --annotation= new_key = new_value annotate
sudo -u postgres pgbackrest --stanza= demo --set= 20261002-190643F info
stanza: demo
status: ok
cipher: aes-256-cbc
db (current)
wal archive min/max (17): 000000020000000000000007/000000020000000000000009
full backup: 20261002-190643F
timestamp start/stop: 2026-10-02 19:06:43+00 / 2026-10-02 19:06:44+00
wal start/stop: 000000020000000000000008 / 000000020000000000000009
lsn start/stop: 0/8000028 / 0/9000050
database size: 22MB, database backup size: 22MB
repo1: backup size: 2.9MB
database list: postgres (5)
annotation(s)
new_key: new_value
source: demo backup
保持
通常、ポイントインタイムリカバリー
の可能な期間を広げるには、できるだけ多くのバックアップを保持することが望ましいですが、ディスク容量などの実際の制約も考慮する必要があります。保持オプションは、不要になった古いバックアップを削除します。
pgBackRestは、保持方式に応じてフルバックアップをローテーションします。方式には個数または期間を指定できます。個数を指定した場合、期限切れの判定はバックアップの作成日時ではなく、保持すべき個数に基づきます。差分バックアップは個数に基づきますが、依存するフルバックアップが期限切れになると必ず一緒に期限切れになります。増分バックアップが保持設定により単独で期限切れになることはなく、関連するフルバックアップまたは差分バックアップとともに期限切れになります。詳細と例はフルバックアップの保持
と差分バックアップの保持
を参照してください。
アーカイブされたWALは、デフォルトでは期限切れになっていないバックアップのために保持されます。推奨はしませんが、retention-archiveオプションでリポジトリごとにこの保持方針を変更できます。詳細と例はアーカイブの保持
を参照してください。
expireコマンドは、バックアップが成功するたびに自動実行され、ユーザーが実行することもできます。ユーザーが実行した場合、設定された各リポジトリの保持設定に従って期限切れ処理が行われます。--repoオプションを指定した場合、指定したリポジトリだけで期限切れ処理を行います。--setオプションで特定のバックアップセットに期限切れ処理を限定することもできます。この場合、--repoオプションを指定しない限り、すべてのリポジトリを検索してセットの条件に一致するものを期限切れにします。expireコマンドを実行すると、アーカイブの保持方針の確認とそれに基づく処理も毎回行われる点に注意してください。
フルバックアップの保持
repo1-retention-full-typeは、repo1-retention-fullオプションを、保持するフルバックアップの個数として解釈するか、保持日数として解釈するかを決めます。期限切れ処理には、新しいバックアップが完了している必要があります。つまり、repo1-retention-full-type=countかつrepo1-retention-full=2の場合は、3つのフルバックアップが保存された後に最も古いものが期限切れになります。repo1-retention-full-type=timeかつrepo1-retention-full=20の場合は、少なくとも20日前のフルバックアップが1つ存在しなければ期限切れ処理は行われません。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-fullを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
バックアップの設定はrepo1-retention-full=2ですが、現在フルバックアップは1つしかないため、次のフルバックアップを実行しても、どのフルバックアップも期限切れになりません。
pg-primary ⇒ フルバックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= full \
--log-level-console= detail backup
[filtered 975 lines of output]
P00 INFO: repo1: remove expired backup 20261002-190641F
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190643F, start = 000000020000000000000008
P00 INFO: repo1: 17-1 remove archive, start = 000000020000000000000007, stop = 000000020000000000000007
P00 INFO: expire command end: completed successfully
一方、最も古いバックアップより前に生成されたWALセグメントがあるため、アーカイブは期限切れになります 。これらはリカバリーには使えません。バックアップのリカバリーに利用できるのは、そのバックアップ以降に生成されたWALセグメントだけです。
pg-primary ⇒ フルバックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= full \
--log-level-console= info backup
[filtered 11 lines of output]
P00 INFO: repo1: expire full backup 20261002-190643F
P00 INFO: repo1: remove expired backup 20261002-190643F
P00 INFO: repo1: 17-1 remove archive, start = 000000020000000000000008, stop = 00000002000000000000000A
P00 INFO: expire command end: completed successfully
フルバックアップ20261002-190624Fが期限切れになり、アーカイブの保持は、最も古いフルバックアップとなった20261002-190646Fを基準に行われます。
差分バックアップの保持
repo1-retention-diffに、必要な差分バックアップの個数を設定します。差分バックアップは前のフルバックアップだけに依存するため、直近1日以上の差分バックアップを順次入れ替えながら保持できます。これにより、全体の容量を抑えながら、最近の時点へすばやくリストアできます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diffを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 1
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
バックアップの設定はrepo1-retention-diff=1のため、1つを期限切れにするには2つの差分バックアップを実行する必要があります。増分バックアップの期限切れ処理も示すため、増分バックアップを追加します。この例では、差分バックアップの期限切れに連動します。
pg-primary ⇒ 差分バックアップと増分バックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= diff backup
sudo -u postgres pgbackrest --stanza= demo --type= incr backup
ここで差分バックアップを実行すると、前の差分バックアップと増分バックアップが期限切れになり、差分バックアップが1つだけ残ります。
pg-primary ⇒ 差分バックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= diff \
--log-level-console= info backup
[filtered 10 lines of output]
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=956-fb652d58 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-diff=1 --repo1-retention-full=2 --stanza=demo
P00 INFO: repo1: expire diff backup set 20261002-190648F_20261002-190650D, 20261002-190648F_20261002-190651I
P00 INFO: repo1: remove expired backup 20261002-190648F_20261002-190651I
P00 INFO: repo1: remove expired backup 20261002-190648F_20261002-190650D
P00 INFO: expire command end: completed successfully
アーカイブの保持
pgBackRestはバックアップの期限切れ処理時にアーカイブ済みWALセグメントを自動削除します(デフォルトではrepo1-retention-fullオプションに基づいてフルバックアップのWALを期限切れにします)。ただし、ディスク容量の節約のために、アーカイブをより積極的に期限切れにすることが有用な場合もあります。差分アーカイブの保持では、フルバックアップも差分バックアップとして扱われます。
アーカイブの期限切れ処理で、バックアップの整合性に必要なWALセグメントが削除されることはありません。ただし、ポイントインタイムリカバリー(PITR)は連続したWALストリームでしか機能しないため、通常のバックアップ期限切れ処理とは別にアーカイブを積極的に期限切れにする際は注意してください。実際には何も期限切れにせず、対象だけを確認するには、コマンドラインでexpireコマンドにdry-runオプションを指定できます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diffを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 2
repo1-retention-full = 2
start-fast = y
[global:archive-push]
compress-level = 3
pg-primary ⇒ 差分バックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= diff \
--log-level-console= info backup
[filtered 6 lines of output]
P00 INFO: backup stop archive = 000000020000000000000017, lsn = 0/17000050
P00 INFO: check archive for segment(s) 000000020000000000000016:000000020000000000000017
P00 INFO: new backup label = 20261002-190648F_20261002-190654D
P00 INFO: diff backup size = 8.3KB, file total = 963
P00 INFO: backup command end: completed successfully
[filtered 2 lines of output]
pg-primary ⇒ アーカイブを期限切れにする
sudo -u postgres pgbackrest --stanza= demo --log-level-console= detail \
--repo1-retention-archive-type= diff --repo1-retention-archive= 1 expire
P00 INFO: expire command begin 2.59.3: --exec-id=1037-f7b8ca1a --log-level-console=detail --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-archive=1 --repo1-retention-archive-type=diff --repo1-retention-diff=2 --repo1-retention-full=2 --stanza=demo
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190646F, start = 00000002000000000000000B, stop = 00000002000000000000000B
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F, start = 00000002000000000000000C, stop = 00000002000000000000000D
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F_20261002-190652D, start = 000000020000000000000012, stop = 000000020000000000000013
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F_20261002-190654D, start = 000000020000000000000016
P00 INFO: repo1: 17-1 remove archive, start = 00000002000000000000000E, stop = 000000020000000000000011
P00 INFO: repo1: 17-1 remove archive, start = 000000020000000000000014, stop = 000000020000000000000015
P00 INFO: expire command end: completed successfully
差分バックアップ20261002-190648F_20261002-190652Dには、古いバックアップの整合性を回復するために保持しなければならないアーカイブ済みWALセグメントがあります。これらを使ってPITRでさらに先へ再生することはできません。20261002-190648F_20261002-190652Dより後、20261002-190648F_20261002-190654Dより前に生成されたWALセグメントは削除されます。新しいバックアップ20261002-190648F_20261002-190654Dより後に生成されたWALセグメントは残り、PITRに利用できます。
差分アーカイブの保持ではフルバックアップも差分バックアップとして扱われるため、同じ設定でここからフルバックアップを実行すると、そのフルバックアップのアーカイブだけがPITR用に保持されます。
リストア
restoreコマンドはデフォルトで、バックアップが存在する最初のリポジトリから最新のバックアップを自動選択します(クイックスタート - バックアップのリストア
を参照)。リポジトリの確認順序はpgbackrest.confで決まります(たとえばrepo1をrepo2より先に確認します)。特定のリポジトリから選択するには、--repoオプション(例:--repo=1)を指定できます。最新以外のバックアップを使用するには、--setオプションを指定します。
PITR に --type=time または --type=lsn を指定する場合は、--target オプションで対象の時刻または LSN を指定する必要があります。--set を指定しない場合、設定済みのリポジトリを順に調べ、終了時刻が対象時刻より前のバックアップ、または終了 LSN が対象 LSN 以下のバックアップを選択します。一致するバックアップが見つからない場合、--type=time と --type=lsn のどちらでも pgBackRest はエラーを返し、最新のバックアップにフォールバックしません。xid など、その他の PITR の種類では、対象が最新のバックアップより前であれば --set オプションを指定する必要があります。詳細と例については、ポイントインタイムリカバリ
を参照してください。
PostgreSQLの推奨に従い、レプリケーションスロットは含めません。詳細はPostgreSQLドキュメントのデータディレクトリのバックアップ
を参照してください。
以降のセクションでは、restoreコマンドの追加機能を紹介します。
ファイルの所有権
通常のようにroot以外のユーザーでrestoreを実行した場合、リストアしたすべてのファイルはpgBackRestを実行するユーザーとグループに属します。既存ファイルの所有者が実行ユーザーやグループと異なり、所有権を変更できない場合はエラーになります。この場合、権限を持つユーザーがファイルの所有権を更新してから、リストアを再試行する必要があります。
rootユーザーでrestoreを実行した場合、pgBackRestはバックアップ時にマニフェストに記録した所有権の再現を試みます。マニフェストに保存されるのはユーザーとグループの名前 だけなので、リストア先ホストに同じ名前が存在する必要があります。ローカルでユーザー名やグループ名が見つからない場合は、PostgreSQLのデータディレクトリのユーザーとグループを使用します。それらにも対応する名前がない場合は、最後にrootを使用します。
deltaオプション
クイックスタート
のバックアップのリストア
では、restoreを実行する前にデータベースクラスターのディレクトリを空にする必要がありました。deltaオプションを使うと、pgBackRestはデータベースクラスターのディレクトリ内でそのまま残せるファイルと、バックアップからリストアすべきファイルを自動で判別できます。また、バックアップのマニフェストにないファイルも削除 するため、バックアップと異なる変更を取り除きます。この判別には、データベースクラスターのディレクトリ内の各ファイルについて計算したSHA-1
暗号学的ハッシュを使用します。SHA-1ハッシュがバックアップに保存されたハッシュと一致しない場合、そのファイルをリストアします。process-maxオプションと組み合わせると、非常に効率的に処理できます。リストア中はPostgreSQLサーバーが停止しているため、サーバーが稼働するバックアップ時より多くのプロセスを使用できます。
pg-primary ⇒ デモクラスターを停止し、deltaリストアを実行する
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo --delta \
--log-level-console= detail restore
[filtered 2 lines of output]
P00 DETAIL: check '/var/lib/postgresql/17/demo' exists
P00 DETAIL: remove 'global/pg_control' so cluster will not start if restore does not complete
P00 INFO: remove invalid files/links/paths from '/var/lib/postgresql/17/demo'
P00 DETAIL: remove invalid file '/var/lib/postgresql/17/demo/backup_label.old'
P00 DETAIL: remove invalid file '/var/lib/postgresql/17/demo/base/1/pg_internal.init'
[filtered 769 lines of output]
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/1/113 - exists and matches backup (bundle 20261002-190648F/1/2665832, 8KB, 88.00%) checksum 1cd643347b87a472ff001ae124e4b532ce998d2f
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/1/112 - exists and matches backup (bundle 20261002-190648F/1/2665920, 8KB, 88.03%) checksum 2cbd5cf8fb22ef627eb539776c5ec7457bdb2890
P01 DETAIL: restore file /var/lib/postgresql/17/demo/PG_VERSION - exists and matches backup (bundle 20261002-190648F/1/2666008, 3B, 88.03%) checksum ad48103e4fc71796e9708cafc43adeed0d1076b7
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/5/2608_fsm - exists and matches backup (bundle 20261002-190648F/1/2666032, 24KB, 88.14%) checksum e807fe622bbfccc5e9ad7f453ecb4f0eaccb75e2
P01 DETAIL: restore file /var/lib/postgresql/17/demo/postgresql.auto.conf - exists and matches backup (bundle 20261002-190648F/1/2666272, 229B, 88.14%) checksum e1b0002d9a33d70466c5a348f4e0c1f1f80639f6
[filtered 233 lines of output]
pg-primary ⇒ PostgreSQLを再起動する
sudo pg_ctlcluster 17 demo start
選択したデータベースのリストア
クラスターのバックアップから、特定のデータベースだけを選んでリストアしたい場合があります。性能上の理由や、クラスター全体のバックアップをリストアする容量がないマシンに、選択したデータベースを移動する場合などです。
この機能を示すため、test1とtest2の2つのデータベースを作成します。
pg-primary ⇒ テスト用データベースを2つ作成する
sudo -u postgres psql -c "create database test1;"
sudo -u postgres psql -c "create database test2;"
選択的なリストアでもリカバリーが機能することを示すため、各テスト用データベースにテーブルとデータを用意します。
pg-primary ⇒ 各データベースにテスト用テーブルを作成する
sudo -u postgres psql -c "create table test1_table (id int); \
insert into test1_table (id) values (1);" test1
sudo -u postgres psql -c "create table test2_table (id int); \
insert into test2_table (id) values (2);" test2
pgBackRestが新しいデータベースを認識できるよう、新しくバックアップを取ります。
pg-primary ⇒ バックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= incr backup
選択的リストアを使う主な理由の1つは容量の節約です。リストア後のディスク使用量と比較できるよう、ここでtest1データベースのサイズを表示します。
pg-primary ⇒ test1データベースの使用容量を表示する
sudo -u postgres du -sh /var/lib/postgresql/17/demo/base/32768
7.4M /var/lib/postgresql/17/demo/base/32768
リストアするデータベースが分からない場合は、infoコマンドのsetオプションを使って、バックアップセットに含まれるデータベースを調べます。
pg-primary ⇒ バックアップのデータベース一覧を表示する
sudo -u postgres pgbackrest --stanza= demo \
--set= 20261002-190648F_20261002-190702I info
[filtered 12 lines of output]
repo1: backup size: 1.9MB
backup reference list: 20261002-190648F, 20261002-190648F_20261002-190654D
database list: postgres (5), test1 (32768), test2 (32769)
クラスターを停止し、test2データベースだけをリストアします。組み込みデータベース(template0、template1、postgres)は常にリストアされます。
警告:
--type=immediateを指定しないと、リカバリーでエラーが発生する場合があります。整合性が確立された後は、PostgreSQLがフルページ書き込みの場合でもゼロ埋めページをエラーとして扱うためです。PostgreSQL ≥ 13では、ignore_invalid_pages設定で無効なページを無視できます。その場合は、リカバリー後にログを確認し、選択したデータベースで無効なページが報告されていないことを確かめることが重要です。
pg-primary ⇒ 最後のバックアップからtest2データベースだけを含めてリストアする
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo --delta \
--db-include= test2 --type= immediate --target-action= promote restore
sudo pg_ctlcluster 17 demo start
リカバリーが完了すると、test2データベースには以前に作成したすべてのテーブルとデータが含まれます。
pg-primary ⇒ test2データベースがリカバリーされたことを確認する
sudo -u postgres psql -c "select * from test2_table;" test2
test1データベースは、リカバリー自体は成功していてもアクセスできません。データベース全体をゼロ埋めのスパースファイルとしてリストアしたためです。PostgreSQLはゼロ埋めファイルにWALを正常に適用できますが、重要なファイルにデータがないため、データベース全体としては無効です。これは意図した動作で、WALの再生中に適用された一部のデータだけを含む可能性があるデータベースを、誤って使用することを防ぎます。
pg-primary ⇒ test1データベースへの接続を試みるとエラーになる
sudo -u postgres psql -c "select * from test1_table;" test1
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: relation mapping file "base/32768/pg_filenode.map" contains invalid data
test1データベースはゼロ埋めのスパースファイルとしてリストアされるため、必要な容量はリカバリー中に書き込まれるWALの量だけです。バックアップ中に生成され、リカバリー中に適用されるWALの量は大きくなることもありますが、通常はデータベース全体のサイズのごく一部です。この機能が特に役立つ大規模なデータベースでは、なおさらです。
選択的リストアでtest1データベースが使用するディスク容量は、データベース全体をリストアした場合より大幅に少ないことが分かります。
pg-primary ⇒ リカバリー後のtest1データベースの使用容量を表示する
sudo -u postgres du -sh /var/lib/postgresql/17/demo/base/32768
8.0K /var/lib/postgresql/17/demo/base/32768
この時点で無効なtest1データベースに行える操作は、drop databaseだけです。リカバリーが完了してクラスターにアクセスできるようになるまでデータベースを削除できないため、pgBackRestは自動削除を行いません。
pg-primary ⇒ test1データベースを削除する
sudo -u postgres psql -c "drop database test1;"
無効なtest1データベースを削除したので、test2と組み込みデータベースだけが残ります。
pg-primary ⇒ 残っているデータベースを一覧表示する
sudo -u postgres psql -c "select oid, datname from pg_database order by oid;"
oid | datname
-------+-----------
1 | template1
4 | template0
5 | postgres
32769 | test2
(4 rows)
ポイントインタイムリカバリー
クイックスタート
のバックアップのリストア
では、WALストリームの末尾まで再生するデフォルトのリカバリーを行いました。ハードウェア障害の場合は通常これが最適ですが、機械または人の操作に起因するデータ破損の場合は、ポイントインタイムリカバリー(PITR)のほうが適していることがよくあります。
ポイントインタイムリカバリー(PITR)では、バックアップから、指定したlsn、時刻、トランザクションID、またはリカバリーポイントまでWALを再生できます。一般的なリカバリーでは、時刻に基づく方式が最も有用でしょう。典型的な例は、誤って削除したテーブルやデータを復元する場合です。ここでは効果が分かりやすいテーブルの復元を例にしますが、削除されたデータもまったく同じ方法で復元できます。
pg-primary ⇒ 非常に重要なデータを持つテーブルを作成する
sudo -u postgres psql -c "begin; \
create table important_table (message text); \
insert into important_table values ('Important Data'); \
commit; \
select * from important_table;"
[filtered 4 lines of output]
message
----------------
Important Data
(1 row)
時刻はPostgreSQLが認識する値で表し、タイムゾーンのオフセットを含めることが重要です。これにより、意図しないタイムゾーン変換や、予想外のリカバリー結果の可能性を減らせます。
pg-primary ⇒ PostgreSQLから時刻を取得する
sudo -u postgres psql -Atc "select current_timestamp"
2026-10-02 19:07:12.060959+00
時刻を記録したので、テーブルを削除します。実際には、テーブルが削除された正確な時刻を見つけるのは、この例よりはるかに困難です。正確な時刻が分からないこともありますが、履歴などを調べれば近い時刻を特定できるはずです。
pg-primary ⇒ 重要なテーブルを削除する
sudo -u postgres psql -c "begin; \
drop table important_table; \
commit; \
select * from important_table;"
BEGIN
DROP TABLE
COMMITERROR: relation "important_table" does not exist
LINE 1: ...le important_table; commit; select * from important_...
^
リストアするバックアップを誤って選ぶと、必要な目標時刻へのリカバリーは失敗します。これを示すために、important_tableが存在しない状態で新しい増分バックアップを実行します。
pg-primary ⇒ 増分バックアップを実行する
sudo -u postgres pgbackrest --stanza= demo --type= incr backup
sudo -u postgres pgbackrest info
[filtered 38 lines of output]
backup reference total: 1 full, 1 diff
incr backup: 20261002-190648F_20261002-190713I
timestamp start/stop: 2026-10-02 19:07:13+00 / 2026-10-02 19:07:14+00
wal start/stop: 00000004000000000000001A / 00000004000000000000001A
[filtered 2 lines of output]
PostgreSQLは前方への再生しかできず、後方には戻れないため、このバックアップから失われたテーブルを復元することはできません。
pg-primary ⇒ 誤ったバックアップからのリカバリーを試みる
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo --delta \
--set= 20261002-190648F_20261002-190713I --target-timeline= current \
--type= time "--target=2026-10-02 19:07:12.060959+00" --target-action= promote restore
sudo pg_ctlcluster 17 demo start
[filtered 13 lines of output]
LOG: database system is ready to accept read-only connections
LOG: redo done at 0/1A000120 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.03 s
FATAL: recovery ended before configured recovery target was reached
LOG: startup process (PID 1437) exited with exit code 1
LOG: terminating any other active server processes
[filtered 3 lines of output]
確実な方法は、目標時刻までリカバリーできるバックアップ、つまり指定した時刻より前に完了したバックアップを、pgBackRestに自動選択させることです。
注:
リストアの種類がxidまたはnameの場合、pgBackRestはバックアップを自動選択できません。
pg-primary ⇒ デモクラスターを2026-10-02 19:07:12.060959+00の時点にリストアする
sudo -u postgres pgbackrest --stanza= demo --delta \
--type= time "--target=2026-10-02 19:07:12.060959+00" \
--target-action= promote restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
[filtered 9 lines of output]
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
recovery_target_time = '2026-10-02 19:07:12.060959+00'
recovery_target_action = 'promote'
pgBackRestがpostgresql.auto.confにリカバリー設定を生成したので、すぐにPostgreSQLを起動できます。%fはPostgreSQLが必要とするWALセグメントの指定、%pはそのコピー先の場所です。PostgreSQLのリカバリーが完了すると、テーブルが再び存在するようになり、クエリーを実行できます。
pg-primary ⇒ PostgreSQLを起動し、重要なテーブルが存在することを確認する
sudo pg_ctlcluster 17 demo start
sudo -u postgres psql -c "select * from important_table"
message
----------------
Important Data
(1 row)
PostgreSQLのログにも有用な情報があります。リカバリーが停止した時刻とトランザクションに加え、最後に適用したトランザクションの時刻も表示されます。
pg-primary ⇒ PostgreSQLのログ出力を確認する
sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
[filtered 7 lines of output]
LOG: restored log file "00000004.history" from archive
LOG: restored log file "000000040000000000000019" from archive
LOG: starting point-in-time recovery to 2026-10-02 19:07:12.060959+00
LOG: restored log file "00000003.history" from archive
LOG: redo starts at 0/19000028
[filtered 2 lines of output]
LOG: database system is ready to accept read-only connections
LOG: restored log file "00000004000000000000001A" from archive
LOG: recovery stopping before commit of transaction 748, time 2026-10-02 19:07:13.389359+00
LOG: redo done at 0/1901CC00 system usage: CPU: user: 0.00 s, system: 0.01 s, elapsed: 0.07 s
LOG: last completed transaction was at log time 2026-10-02 19:07:10.778316+00
LOG: restored log file "000000040000000000000019" from archive
LOG: selected new timeline ID: 5
[filtered 5 lines of output]
stanzaの削除
stanza-deleteコマンドは、stanzaに関連するデータをリポジトリから削除します。
警告:
このコマンドは慎重に使用してください。指定したstanzaのすべてのバックアップとアーカイブを、pgBackRestリポジトリから完全に削除します。
stanzaを削除するには、次の手順を実行します。
stanzaに関連付けられたPostgreSQLクラスターを停止します(または–forceでこの要件を無視します)。
stanza-deleteコマンドを実行するホストで、stopコマンドを実行します。
stanza-deleteコマンドを実行します。
コマンドが正常に完了したら、すべてのpgBackRest設定ファイルや環境変数からstanzaを削除するのはユーザーの責任です。
stanzaは一度に1つのリポジトリからしか削除できません。複数のリポジトリから削除するには、--repoオプションを指定し、リポジトリごとにstanza-deleteコマンドを繰り返し実行してください。
pg-primary ⇒ 削除対象のPostgreSQLクラスターを停止する
sudo pg_ctlcluster 17 demo stop
pg-primary ⇒ 対象のstanzaについてpgBackRestを停止する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info stop
P00 INFO: stop command begin 2.59.3: --exec-id=1568-4c984637 --log-level-console=info --no-log-timestamp --stanza=demo
P00 INFO: stop command end: completed successfully
pg-primary ⇒ 1つのリポジトリからstanzaを削除する
sudo -u postgres pgbackrest --stanza= demo --repo= 1 \
--log-level-console= info stanza-delete
P00 INFO: stanza-delete command begin 2.59.3: --exec-id=1576-48368d9e --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=1 --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00 INFO: stanza-delete command end: completed successfully
複数のリポジトリ
S3のサポート
に示すように、複数のリポジトリを設定できます。利点の1つは、高速なリストア用のローカルリポジトリと、冗長性のためのリモートリポジトリを併用できることです。
stanza-create
/stanza-upgrade
など、一部のコマンドは設定済みのすべてのリポジトリを自動で処理します。一方、stanza-delete
などのコマンドでは、repoオプションでリポジトリを指定する必要があります。
後方互換性を維持するため、repo1だけが設定されている場合はrepoオプションは不要です。ただし、リポジトリが1つでも、たとえばrepo2として設定されている場合はrepoオプションが必要です 。これは、後で新しいリポジトリを追加した際に、コマンドが動作しなくなることを防ぐためです。
archive-pushコマンドは、設定済みのすべてのリポジトリのアーカイブに常にWALを送信します。あるリポジトリに接続できなくても、ほかのリポジトリへの送信は続きます。ただし、これを有効に機能させるにはarchive-async=yを有効にする必要があります。そうしないと、ほかのリポジトリは接続できないリポジトリよりWALセグメント1つ分しか先に進めません。また、いずれかのリポジトリにWALを送信できない場合、PostgreSQLはそのWALをpg_walディレクトリから削除しないため、ボリュームの空き容量がなくなる可能性があります。
バックアップはリポジトリごとに個別にスケジュールする必要があります。バックアップの種類や保持設定はリポジトリごとに異なるため、多くの場合これは望ましい動作です。同様に、リストアでもリポジトリを指定する必要があります。一般に、リカバリー時間が長くなっても、レイテンシーやコストの低いリポジトリをリストアに指定するほうが適しています。どのリポジトリが最も効率的かは、リストアのテストでしか判断できません。
Azure互換オブジェクトストアのサポート
pgBackRestは、Azure互換オブジェクトストアへのリポジトリの配置をサポートします。リポジトリを保存するコンテナーは事前に作成する必要があり、pgBackRestは自動作成しません。コンテナーのルート(/)にもリポジトリを配置できますが、通常はサブパスに配置するほうが適しています。これにより、オブジェクトストアのログなどのデータも競合せずに同じコンテナーに保存できます。
警告:
階層型名前空間を有効にしないでください。期限切れ処理でエラーが発生します。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Azureを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 2
repo1-retention-full = 2
repo2-azure-account = pgbackrest
repo2-azure-container = demo-container
repo2-azure-key = YXpLZXk=
repo2-path = /demo-repo
repo2-retention-full = 4
repo2-type = azure
start-fast = y
[global:archive-push]
compress-level = 3
repo2-azure-key-typeオプションをsasに、repo2-azure-keyオプションを共有アクセス署名トークンに設定すると、共有アクセス署名を使用できます。
コマンドは、リポジトリをローカルディスクに保存した場合とまったく同じように実行します。
pg-primary ⇒ stanzaを作成する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info stanza-create
P00 INFO: stanza-create command begin 2.59.3: --exec-id=1657-1f40c982 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo2-type=azure --stanza=demo
P00 INFO: stanza-create for stanza 'demo' on repo1
P00 INFO: stanza-create for stanza 'demo' on repo2
P00 INFO: stanza-create command end: completed successfully
Azureではファイル作成に比較的時間がかかるため、ファイルのバンドル化
を有効にするとbackup/restoreの性能が向上します。
pg-primary ⇒ デモクラスターをバックアップする
sudo -u postgres pgbackrest --stanza= demo --repo= 2 \
--log-level-console= info backup
P00 INFO: backup command begin 2.59.3: --exec-id=1666-1ab08562 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo --start-fast
P00 WARN: no prior backup exists, incr backup has been changed to full
P00 INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00 INFO: backup start archive = 00000005000000000000001B, lsn = 0/1B000028
[filtered 3 lines of output]
P00 INFO: check archive for segment(s) 00000005000000000000001B:00000005000000000000001B
P00 INFO: new backup label = 20261002-190727F
P00 INFO: full backup size = 29.2MB, file total = 1265
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=1666-1ab08562 --log-level-console=info --no-log-timestamp --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo
S3互換オブジェクトストアのサポート
pgBackRestは、S3互換オブジェクトストアへのリポジトリの配置をサポートします。リポジトリを保存するバケットは事前に作成する必要があり、pgBackRestは自動作成しません。バケットのルート(/)にもリポジトリを配置できますが、通常はサブパスに配置するほうが適しています。これにより、オブジェクトストアのログなどのデータも競合せずに同じバケットに保存できます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ S3を設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 2
repo1-retention-full = 2
repo2-azure-account = pgbackrest
repo2-azure-container = demo-container
repo2-azure-key = YXpLZXk=
repo2-path = /demo-repo
repo2-retention-full = 4
repo2-type = azure
repo3-path = /demo-repo
repo3-retention-full = 4
repo3-s3-bucket = demo-bucket
repo3-s3-endpoint = s3.us-east-1.amazonaws.com
repo3-s3-key = accessKey1
repo3-s3-key-secret = verySecretKey1
repo3-s3-region = us-east-1
repo3-type = s3
start-fast = y
[global:archive-push]
compress-level = 3
注:
リージョンとエンドポイントは、バケットの配置場所に合わせて設定する必要があります。ここに示す値はus-east-1リージョン用です。
pgBackRestを実行するロールを作成し、バケットの権限は可能な限り制限することをお勧めします。AWSのインスタンスにロールが関連付けられている場合、repo3-s3-key-type=autoにするとpgBackRestが一時的な認証情報を自動取得するため、/etc/pgbackrest/pgbackrest.confにキーを明示的に設定する必要はありません。
このAmazon S3ポリシーの例では、すべての読み取りと書き込みを、指定のバケットとリポジトリパスに制限します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::demo-bucket"
],
"Condition": {
"StringEquals": {
"s3:prefix": [
"",
"demo-repo"
],
"s3:delimiter": [
"/"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::demo-bucket"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"demo-repo/*"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectTagging",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::demo-bucket/demo-repo/*"
]
}
]
}
コマンドは、リポジトリをローカルディスクに保存した場合とまったく同じように実行します。
pg-primary ⇒ stanzaを作成する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info stanza-create
[filtered 4 lines of output]
P00 INFO: stanza 'demo' already exists on repo2 and is valid
P00 INFO: stanza-create for stanza 'demo' on repo3
P00 INFO: stanza-create command end: completed successfully
S3ではファイル作成に比較的時間がかかるため、ファイルのバンドル化
を有効にするとbackup/restoreの性能が向上します。
pg-primary ⇒ デモクラスターをバックアップする
sudo -u postgres pgbackrest --stanza= demo --repo= 3 \
--log-level-console= info backup
P00 INFO: backup command begin 2.59.3: --exec-id=1767-6031c435 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo --start-fast
P00 WARN: no prior backup exists, incr backup has been changed to full
P00 INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00 INFO: backup start archive = 00000005000000000000001D, lsn = 0/1D000028
[filtered 3 lines of output]
P00 INFO: check archive for segment(s) 00000005000000000000001D:00000005000000000000001D
P00 INFO: new backup label = 20261002-190741F
P00 INFO: full backup size = 29.2MB, file total = 1265
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=1767-6031c435 --log-level-console=info --no-log-timestamp --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo
SFTPのサポート
pgBackRestは、SFTPホストへのリポジトリの配置をサポートします。SFTPのファイル転送は比較的遅いため、process-maxを増やしてファイル転送を並列化するとコマンドの性能が向上します。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ SFTPを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
process-max = 4
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 2
repo1-retention-full = 2
repo2-azure-account = pgbackrest
repo2-azure-container = demo-container
repo2-azure-key = YXpLZXk=
repo2-path = /demo-repo
repo2-retention-full = 4
repo2-type = azure
repo3-path = /demo-repo
repo3-retention-full = 4
repo3-s3-bucket = demo-bucket
repo3-s3-endpoint = s3.us-east-1.amazonaws.com
repo3-s3-key = accessKey1
repo3-s3-key-secret = verySecretKey1
repo3-s3-region = us-east-1
repo3-type = s3
repo4-bundle = y
repo4-path = /demo-repo
repo4-sftp-host = sftp-server
repo4-sftp-host-key-hash-type = sha1
repo4-sftp-host-user = pgbackrest
repo4-sftp-private-key-file = /var/lib/postgresql/.ssh/id_rsa_sftp
repo4-sftp-public-key-file = /var/lib/postgresql/.ssh/id_rsa_sftp.pub
repo4-type = sftp
start-fast = y
[global:archive-push]
compress-level = 3
SFTPを利用する場合、libssh2がOpenSSHに対してコンパイルされていれば、repo4-sftp-public-key-fileは省略できます。
pg-primary ⇒ SFTPバックアップ用のSSHキーペアを生成する
sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa_sftp \
-t rsa -b 4096 -N "" -m PEM
sftp-server ⇒ pg-primaryのSFTPバックアップ用公開鍵をsftp-serverにコピーする
sudo -u pgbackrest mkdir -m 750 -p /home/pgbackrest/.ssh
( sudo ssh root@pg-primary cat /var/lib/postgresql/.ssh/id_rsa_sftp.pub) | \
sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys
コマンドは、リポジトリをローカルディスクに保存した場合とまったく同じように実行します。
pg-primary ⇒ repo4-sftp-host-key-check-typeのデフォルトが「strict」のため、sftp-serverのフィンガープリントをknown_hostsファイルに追加する
ssh-keyscan -H sftp-server >> /var/lib/postgresql/.ssh/known_hosts 2>/dev/null
pg-primary ⇒ stanzaを作成する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info stanza-create
[filtered 6 lines of output]
P00 INFO: stanza 'demo' already exists on repo3 and is valid
P00 INFO: stanza-create for stanza 'demo' on repo4
P00 INFO: stanza-create command end: completed successfully
pg-primary ⇒ デモクラスターをバックアップする
sudo -u postgres pgbackrest --stanza= demo --repo= 4 \
--log-level-console= info backup
P00 INFO: backup command begin 2.59.3: --exec-id=1859-efaa8e87 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=4 --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo4-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo --start-fast
P00 WARN: option 'repo4-retention-full' is not set for 'repo4-retention-full-type=count', the repository may run out of space
HINT: to retain full backups indefinitely (without warning), set option 'repo4-retention-full' to the maximum.
P00 WARN: no prior backup exists, incr backup has been changed to full
P00 INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00 INFO: backup start archive = 00000005000000000000001E, lsn = 0/1E000028
[filtered 3 lines of output]
P00 INFO: check archive for segment(s) 00000005000000000000001E:00000005000000000000001F
P00 INFO: new backup label = 20261002-190759F
P00 INFO: full backup size = 29.2MB, file total = 1265
P00 INFO: backup command end: completed successfully
P00 INFO: expire command begin 2.59.3: --exec-id=1859-efaa8e87 --log-level-console=info --no-log-timestamp --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo
P00 INFO: expire command end: completed successfully
GCS互換オブジェクトストアのサポート
pgBackRestは、GCS互換オブジェクトストアへのリポジトリの配置をサポートします。リポジトリを保存するバケットは事前に作成する必要があり、pgBackRestは自動作成しません。バケットのルート(/)にもリポジトリを配置できますが、通常はサブパスに配置するほうが適しています。これにより、オブジェクトストアのログなどのデータも競合せずに同じバケットに保存できます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ GCSを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
process-max = 4
repo1-block = y
repo1-bundle = y
repo1-cipher-pass = zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type = aes-256-cbc
repo1-path = /var/lib/pgbackrest
repo1-retention-diff = 2
repo1-retention-full = 2
repo2-azure-account = pgbackrest
repo2-azure-container = demo-container
repo2-azure-key = YXpLZXk=
repo2-path = /demo-repo
repo2-retention-full = 4
repo2-type = azure
repo3-path = /demo-repo
repo3-retention-full = 4
repo3-s3-bucket = demo-bucket
repo3-s3-endpoint = s3.us-east-1.amazonaws.com
repo3-s3-key = accessKey1
repo3-s3-key-secret = verySecretKey1
repo3-s3-region = us-east-1
repo3-type = s3
repo4-bundle = y
repo4-path = /demo-repo
repo4-sftp-host = sftp-server
repo4-sftp-host-key-hash-type = sha1
repo4-sftp-host-user = pgbackrest
repo4-sftp-private-key-file = /var/lib/postgresql/.ssh/id_rsa_sftp
repo4-sftp-public-key-file = /var/lib/postgresql/.ssh/id_rsa_sftp.pub
repo4-type = sftp
repo5-gcs-bucket = demo-bucket
repo5-gcs-key = /etc/pgbackrest/gcs-key.json
repo5-path = /demo-repo
repo5-type = gcs
start-fast = y
[global:archive-push]
compress-level = 3
GCEで実行する場合は、repo5-gcs-key-type=autoを設定すると、インスタンスのサービスアカウントを使用して自動認証します。
コマンドは、リポジトリをローカルディスクに保存した場合とまったく同じように実行します。
GCSではファイル作成に比較的時間がかかるため、ファイルのバンドル化
を有効にするとbackup/restoreの性能が向上します。
リポジトリの目標時刻
目標時刻は、バージョン管理されたストレージ上のリポジトリをコマンドが読み込む際の時点を指定します。これにより、ある時点のリポジトリを読み込み、ユーザーの誤操作やマルウェアによって削除または破損されたデータを復元できます。
S3、GCS、Azureはストレージのバージョン管理に対応していますが、通常はデフォルトで有効になっていません。バージョン管理に加えて、S3ではオブジェクトロック、GCSやAzureでは論理削除を有効にすると有用な場合があります。
repo-target-timeオプションを指定する場合は、repoオプションも指定する必要があります。すべてのリポジトリ種類がバージョン管理に対応するとは限らず、一般にリカバリーでは単一のリポジトリを対象にするのが妥当です。
ストレージのタイムスタンプとの比較は、指定したタイムスタンプ以下(<=)で行われ、指定したタイムスタンプのミリ秒部分は切り捨てられます。
この機能を示すため、S3リポジトリのdemostanzaを削除します。
pg-primary ⇒ S3リポジトリのstanzaを削除する
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo stop
sudo -u postgres pgbackrest --stanza= demo --repo= 3 stanza-delete
stanzaを削除すると、infoコマンドはリポジトリがエラー状態であることを示します。
pg-primary ⇒ infoでエラーを確認する
sudo -u postgres pgbackrest --stanza= demo --repo= 3 info
stanza: demo
status: error (missing stanza path)
ただし、ストレージはバージョン管理されているため、stanzaの削除前の時点のリポジトリを確認できます。状況によっては目標時刻の特定が難しい場合もありますが、この例ではbackup.infoの削除時刻を調べることで、stanzaが削除された時刻を特定できます。
pg-primary ⇒ バケット内のbackup.infoのバージョンを一覧表示する
key = demo-repo/backup/demo/backup.info; \
aws s3api list-object-versions --bucket demo-bucket \
--prefix $key --output table \
--query "sort_by([Versions[?Key==' $key '].{Action:'PUT', \
Modified:LastModified,Object:Key}, \
DeleteMarkers[?Key==' $key '].{Action:'DELETE', \
Modified:LastModified,Object:Key}][],&Modified)"
-----------------------------------------------------------------------------
| ListObjectVersions |
+--------+----------------------------+-------------------------------------+
| Action | Modified | Object |
+--------+----------------------------+-------------------------------------+
| PUT | 2026-10-02T19:07:41.474Z | demo-repo/backup/demo/backup.info |
| PUT | 2026-10-02T19:07:56.815Z | demo-repo/backup/demo/backup.info |
| DELETE| 2026-10-02T19:08:04.878Z | demo-repo/backup/demo/backup.info |
+--------+----------------------------+-------------------------------------+
これで、目標時刻を指定してinfoコマンドを実行すると、削除前のリポジトリを表示できます。
pg-primary ⇒ 目標時刻を指定してinfoを実行する
sudo -u postgres pgbackrest --stanza= demo --repo= 3 \
--repo-target-time= "2026-10-02 19:07:57+00" info
[filtered 5 lines of output]
wal archive min/max (17): 00000005000000000000001C/00000005000000000000001D
full backup: 20261002-190741F
timestamp start/stop: 2026-10-02 19:07:41+00 / 2026-10-02 19:07:56+00
wal start/stop: 00000005000000000000001D / 00000005000000000000001D
repo3: backup set size: 3.8MB, backup size: 3.8MB
必要なバックアップがinfoコマンドで表示されれば、同じ目標時刻を使ってリストアできます。
pg-primary ⇒ 目標時刻を指定してリストアする
sudo -u postgres pgbackrest --stanza= demo --repo= 3 --delta \
--repo-target-time= "2026-10-02 19:07:57+00" --log-level-console= info restore
P00 INFO: restore command begin 2.59.3: --delta --exec-id=1953-a0a01a5a --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=4 --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo5-gcs-bucket=demo-bucket --repo5-gcs-key=<redacted> --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo5-path=/demo-repo --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo-target-time="2026-10-02 19:07:57+00" --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --repo5-type=gcs --stanza=demo
P00 INFO: repo3: restore backup set 20261002-190741F, recovery will start at 2026-10-02 19:07:41
P00 INFO: remove invalid files/links/paths from '/var/lib/postgresql/17/demo'
P00 INFO: write updated /var/lib/postgresql/17/demo/postgresql.auto.conf
[filtered 2 lines of output]
sudo pg_ctlcluster 17 demo start
専用リポジトリホスト
クイックスタート
で説明した構成は単純な構成に適していますが、企業での構成では通常、バックアップとWALアーカイブファイルを保存する専用リポジトリホストを用意します。これにより、バックアップとWALアーカイブをデータベースサーバーから分離し、データベースホストの障害による影響を減らせます。それでも、従来のバックアップソフトウェアでリポジトリホストをバックアップすることをお勧めします。
PostgreSQLホストでは、pg1-pathをローカルのPostgreSQLクラスターのパスにする必要があり、pg1-hostは設定しないことをお勧めします。リポジトリホストを設定する際は、pgbackrest設定ファイルのpg-hostオプションで、プライマリーホストとスタンバイホスト(存在する場合)への接続を設定する必要があります。複数のPostgreSQLホストを認識するpgbackrest設定は、リポジトリホストのものだけにします。順序は関係なく、たとえばpg1-path/pg1-hostとpg2-path/pg2-hostは、どちらをプライマリーまたはスタンバイにしてもかまいません。
インストール
クラスターのバックアップを保存するため、repositoryという新しいホストを作成します。
注:
リポジトリホストにインストールするpgBackRestのバージョンは、PostgreSQLホストのバージョンと完全に一致する必要があります。
pgBackRestリポジトリの所有者として、pgbackrestユーザーを作成します。どのユーザーでもリポジトリの所有者にできますが、混乱を避けるため、postgresが存在しても使用しないことをお勧めします。
注:
pgBackRestをパッケージからインストールすると、/etc/logrotate.d/pgbackrestのようなlogrotate設定が付属し、suディレクティブ(例:su postgres postgres)により特定のユーザーでログをローテーションする場合があります。/var/log/pgbackrestのファイルは、pgBackRestを実行するユーザー(ここではpgbackrest)が所有するため、suディレクティブもそのユーザーに合わせて更新する必要があります。そうしないとlogrotateが権限エラーで失敗します。
repository ⇒ pgbackrestユーザーを作成する
sudo adduser --disabled-password --gecos "" pgbackrest
pgBackRestはソースからビルドするより、パッケージからインストールすることをお勧めします。パッケージからインストールする場合、このセクションの残りの手順は通常不要ですが、パッケージが一部のディレクトリを作成しなかったり、誤った権限を設定したりする可能性があります。その場合は、手動でディレクトリを作成したり権限を更新したりする必要がある場合があります。
pgBackRestのDebian/Ubuntuパッケージはapt.postgresql.org
から入手できます。
使用するディストリビューションやバージョン向けのパッケージがない場合は、ソースからビルド
し、ここに示す手順で手動インストールできます。
repository ⇒ 依存パッケージをインストールする
sudo apt-get install postgresql-client libxml2 libssh2-1
repository ⇒ ビルド用ホストからpgBackRestバイナリをコピーする
sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest
pgBackRestには、ログディレクトリ、設定ディレクトリ、設定ファイルが必要です。
repository ⇒ pgBackRestの設定ファイルとディレクトリを作成する
sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown pgbackrest:pgbackrest /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown pgbackrest:pgbackrest /etc/pgbackrest/pgbackrest.conf
repository ⇒ pgBackRestのリポジトリを作成する
sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown pgbackrest:pgbackrest /var/lib/pgbackrest
パスワードなしのSSHの設定
pgBackRestは、パスワードなしのSSHを使用してホスト間で通信できます。TLSも使用できます。TLSの設定
を参照してください。
repository ⇒ repositoryホストのキーペアを作成する
sudo -u pgbackrest mkdir -m 750 /home/pgbackrest/.ssh
sudo -u pgbackrest ssh-keygen -f /home/pgbackrest/.ssh/id_rsa \
-t rsa -b 4096 -N ""
pg-primary ⇒ pg-primaryホストのキーペアを作成する
sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
-t rsa -b 4096 -N ""
repositoryとpg-primaryの間で鍵を交換します。
repository ⇒ pg-primaryの公開鍵をrepositoryにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@pg-primary cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys
pg-primary ⇒ repositoryの公開鍵をpg-primaryにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys
repositoryからpg-primary、およびその逆方向に接続できることをテストします。
repository ⇒ repositoryからpg-primaryへの接続をテストする
sudo -u pgbackrest ssh postgres@pg-primary
pg-primary ⇒ pg-primaryからrepositoryへの接続をテストする
sudo -u postgres ssh pgbackrest@repository
注:
sshは、パスワードなしの接続でpgBackRestの実行だけを許可するように設定されています。これにより、サービスアカウントのいずれかが乗っ取られた場合のセキュリティを高めます。
設定
リポジトリホストには、pg-primaryのホスト名、ユーザー、データベースパスを設定する必要があります。後でスタンバイを追加できるよう、プライマリーはpg1として設定します。
repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-userとpg1-pathを設定する
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/17/demo
[global]
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
データベースホストには、リポジトリのホスト名とユーザーを設定する必要があります。repo1-host-userオプションのデフォルトはpgbackrestです。postgresユーザーがリポジトリホストでリストアを行う場合は、同じpostgresユーザーにバックアップも許可しないことをお勧めします。ただし、postgresユーザーがpgbackrestユーザーと同じグループに属していれば、リポジトリを直接読み取ることはできます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-host/repo1-host-userを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
log-level-file = detail
repo1-host = repository
PostgreSQLの設定はアーカイブの設定
を参照してください。
コマンドの実行方法は単一ホスト構成と同じですが、backupやexpireなど、一部のコマンドはデータベースホストではなくリポジトリホストから実行します。
stanzaの作成と確認
新しいリポジトリにstanzaを作成します。
repository ⇒ stanzaを作成する
sudo -u pgbackrest pgbackrest --stanza= demo stanza-create
データベースホストとリポジトリホストの両方で、設定が正しいことを確認します。checkコマンドの詳細は設定の確認
を参照してください。
pg-primary ⇒ 設定を確認する
sudo -u postgres pgbackrest --stanza= demo check
repository ⇒ 設定を確認する
sudo -u pgbackrest pgbackrest --stanza= demo check
PostgreSQLクラスターのバックアップを行うには、リポジトリホストでpgBackRestのbackupコマンドを実行します。
repository ⇒ デモクラスターをバックアップする
sudo -u pgbackrest pgbackrest --stanza= demo backup
P00 WARN: no prior backup exists, incr backup has been changed to full
リポジトリホストに新しいリポジトリを作成したため、増分バックアップをフルバックアップに変更するという警告が表示されました。
バックアップのリストア
PostgreSQLクラスターをリストアするには、データベースホストでpgBackRestのrestoreコマンドを実行します。
pg-primary ⇒ デモクラスターを停止し、リストアしてPostgreSQLを再起動する
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo --delta restore
sudo pg_ctlcluster 17 demo start
バックアップとリストアの並列実行
pgBackRestは並列処理により、圧縮と転送の性能を向上させます。この機能で使用するプロセス数は、--process-maxオプションで設定します。
通常、backupコマンドで使用するCPUは、利用可能なCPUの25%以内に抑えることをお勧めします。バックアップは定期的に行っていればそれほど高速である必要はなく、できる限りデータベースの性能に影響を与えないようにすることが望まれます。
restoreコマンドでは利用可能なすべてのCPUを使用でき、そうすることをお勧めします。リストア中はPostgreSQLクラスターが停止し、通常はホストでほかの重要な処理が行われていないためです。ホストに複数のクラスターがある場合は、それを考慮してリストアの並列度を設定してください。
repository ⇒ 単一プロセスでバックアップを実行する
sudo -u pgbackrest pgbackrest --stanza= demo --type= full backup
repository:/etc/pgbackrest/pgbackrest.conf ⇒ 複数のbackupプロセスを使用するようpgBackRestを設定する
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/17/demo
[global]
process-max = 3
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
repository ⇒ 複数プロセスでバックアップを実行する
sudo -u pgbackrest pgbackrest --stanza= demo --type= full backup
repository ⇒ デモクラスターのバックアップ情報を取得する
sudo -u pgbackrest pgbackrest info
stanza: demo
status: ok
cipher: none
db (current)
wal archive min/max (17): 000000070000000000000023/000000070000000000000025
full backup: 20261002-190844F
timestamp start/stop: 2026-10-02 19:08:44+00 / 2026-10-02 19:08:48+00
wal start/stop: 000000070000000000000023 / 000000070000000000000023
database size: 29.2MB, database backup size: 29.2MB
repo1: backup set size: 3.8MB, backup size: 3.8MB
full backup: 20261002-190850F
timestamp start/stop: 2026-10-02 19:08:50+00 / 2026-10-02 19:08:52+00
wal start/stop: 000000070000000000000024 / 000000070000000000000025
database size: 29.2MB, database backup size: 29.2MB
repo1: backup set size: 3.8MB, backup size: 3.8MB
複数プロセスを使うことで、最後のバックアップの性能は向上しているはずです。非常に小さなバックアップでは違いが明確でない場合もありますが、データベースが大きくなるほど短縮できる時間も増えます。
開始と停止
テストのためにスタンバイを昇格させたり、本番バックアップからテスト用クラスターをリストアしたりする場合、それらのクラスターがpgBackRestリポジトリに書き込めないようにしておくことをお勧めします。これはstopコマンドで行えます。
stopによってブロックされる書き込みコマンドは、archive-push、backup、expire、stanza-create、stanza-upgradeです。stanza-deleteはこの規則の例外です(詳細はstanzaの削除
を参照)。
pg-primary ⇒ pgBackRestの書き込みコマンドを停止する
sudo -u postgres pgbackrest stop
新たなpgBackRestの書き込みコマンドは実行されなくなります。
repository ⇒ バックアップを試みる
sudo -u pgbackrest pgbackrest --stanza= demo backup
P00 WARN: unable to check pg1: [StopError] raised from remote-0 ssh protocol on 'pg-primary': stop file exists for all stanzas
P00 ERROR: [056]: unable to find primary cluster - cannot proceed
HINT: are all available clusters in recovery?
現在実行中のpgBackRest書き込みコマンドも終了するには、--forceオプションを指定します。非同期のarchive-getも対象に含まれますが、PostgreSQLが必要とすれば再び実行されます。pgBackRestがすでに停止している場合、再度停止すると警告が出ます。
pg-primary ⇒ pgBackRestのサービスを再度停止する
sudo -u postgres pgbackrest stop
P00 WARN: stop file already exists for all stanzas
pgBackRestの書き込みコマンドを再び許可するには、startコマンドを使用します。停止前に進行中だった書き込みコマンドが自動で再開されることはありませんが、新たに開始することは許可されます。
pg-primary ⇒ pgBackRestの書き込みコマンドを開始する
sudo -u postgres pgbackrest start
単一のstanzaについてのみpgBackRestを停止することもできます。
pg-primary ⇒ demostanzaのpgBackRest書き込みコマンドを停止する
sudo -u postgres pgbackrest --stanza= demo stop
指定したstanzaでは、新たなpgBackRestの書き込みコマンドは実行されなくなります。
repository ⇒ バックアップを試みる
sudo -u pgbackrest pgbackrest --stanza= demo backup
P00 WARN: unable to check pg1: [StopError] raised from remote-0 ssh protocol on 'pg-primary': stop file exists for stanza demo
P00 ERROR: [056]: unable to find primary cluster - cannot proceed
HINT: are all available clusters in recovery?
単一のstanzaのpgBackRest書き込みコマンドを開始する場合も、stanzaを指定する必要があります。
pg-primary ⇒ demostanzaのpgBackRest書き込みコマンドを開始する
sudo -u postgres pgbackrest --stanza= demo start
レプリケーション
レプリケーションでは、単一のプライマリーからPostgreSQLクラスターの複数のコピー(スタンバイと呼びます)を作成できます。スタンバイは読み取り負荷の分散に利用でき、プライマリーホストの障害に備えた冗長性も提供します。
インストール
スタンバイを実行するため、pg-standbyという新しいホストを作成します。
pgBackRestはソースからビルドするより、パッケージからインストールすることをお勧めします。パッケージからインストールする場合、このセクションの残りの手順は通常不要ですが、パッケージが一部のディレクトリを作成しなかったり、誤った権限を設定したりする可能性があります。その場合は、手動でディレクトリを作成したり権限を更新したりする必要がある場合があります。
pgBackRestのDebian/Ubuntuパッケージはapt.postgresql.org
から入手できます。
使用するディストリビューションやバージョン向けのパッケージがない場合は、ソースからビルド
し、ここに示す手順で手動インストールできます。
pg-standby ⇒ 依存パッケージをインストールする
sudo apt-get install postgresql-client libxml2 libssh2-1
pg-standby ⇒ ビルド用ホストからpgBackRestバイナリをコピーする
sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest
pgBackRestには、ログディレクトリ、設定ディレクトリ、設定ファイルが必要です。
pg-standby ⇒ pgBackRestの設定ファイルとディレクトリを作成する
sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf
パスワードなしのSSHの設定
pgBackRestは、パスワードなしのSSHを使用してホスト間で通信できます。TLSも使用できます。TLSの設定
を参照してください。
pg-standby ⇒ pg-standbyホストのキーペアを作成する
sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
-t rsa -b 4096 -N ""
repositoryとpg-standbyの間で鍵を交換します。
repository ⇒ pg-standbyの公開鍵をrepositoryにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@pg-standby cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys
pg-standby ⇒ repositoryの公開鍵をpg-standbyにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys
repositoryからpg-standby、およびその逆方向に接続できることをテストします。
repository ⇒ repositoryからpg-standbyへの接続をテストする
sudo -u pgbackrest ssh postgres@pg-standby
pg-standby ⇒ pg-standbyからrepositoryへの接続をテストする
sudo -u postgres ssh pgbackrest@repository
ホットスタンバイ
ホットスタンバイは、WALアーカイブを使ってレプリケーションを行い、読み取り専用のクエリーを受け付けます。
pgBackRestの設定はpg-primaryとほぼ同じですが、WALストリームの末尾に達してもクラスターをリカバリーモードに保つため、リカバリーの種類にstandbyを使用します。
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ スタンバイのpgBackRestを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
log-level-file = detail
repo1-host = repository
PostgreSQLの設定ファイルを作成するため、デモクラスターを作成する必要があります(リストア時に上書きされます)。
pg-standby ⇒ デモクラスターを作成する
sudo pg_createcluster 17 demo
これでrestoreコマンドを使ってスタンバイを作成できます。
重要:
新しいプライマリーにする目的ではなく、レポート作成やテストなどのためにクラスターを昇格させる場合は、--archive-mode=offを使うか、postgresql.confにarchive_mode=offを設定してアーカイブを無効にしてください。無効にしないと、リポジトリに不要なWALが混入し、リストアが難しくなる可能性があります。
pg-standby ⇒ デモのスタンバイクラスターをリストアする
sudo -u postgres pgbackrest --stanza= demo --delta --type= standby restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:30
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:56
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_time = '2026-10-02 19:07:12.060959+00'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_action = 'promote'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:10
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 19:07:57+00" --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:37
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:09:08
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
この設定は、スタンバイがプライマリーに昇格した場合に備えたものです。
pg-standby:/etc/postgresql/17/demo/postgresql.conf ⇒ PostgreSQLを設定する
archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
pg-standby ⇒ PostgreSQLを起動する
sudo pg_ctlcluster 17 demo start
PostgreSQLのログから、リカバリーについて有用な情報が得られます。特に、クラスターがスタンバイモードに入り、読み取り専用接続を受け付ける準備ができたことを確認してください。
pg-standby ⇒ PostgreSQLのログ出力で、成功を示すメッセージを確認する
sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
[filtered 6 lines of output]
LOG: restored log file "00000007.history" from archive
LOG: restored log file "000000070000000000000024" from archive
LOG: entering standby mode
LOG: redo starts at 0/24000028
LOG: restored log file "000000070000000000000025" from archive
[filtered 3 lines of output]
レプリケーションが正しく設定されているかを簡単にテストするには、pg-primaryにテーブルを作成します。
pg-primary ⇒ プライマリーに新しいテーブルを作成する
sudo -u postgres psql -c " \
begin; \
create table replicated_table (message text); \
insert into replicated_table values ('Important Data'); \
commit; \
select * from replicated_table" ;
[filtered 4 lines of output]
message
----------------
Important Data
(1 row)
続いて、pg-standbyで同じテーブルにクエリーを実行します。
pg-standby ⇒ スタンバイで新しいテーブルにクエリーを実行する
sudo -u postgres psql -c "select * from replicated_table;"
ERROR: relation "replicated_table" does not exist
LINE 1: select * from replicated_table;
^
ここで失敗するのは、PostgreSQLがアーカイブからWALセグメントを取得してレプリケーションしているためです。変更を含むWALセグメントがpg-primaryから送信されるまで、その変更はスタンバイに現れません。
pg_switch_wal()を呼び出すと、現在のWALセグメントをアーカイブに手動で送信できます(以後の変更を格納する新しいWALセグメントが作成されます)。
pg-primary ⇒ pg_switch_wal()を呼び出す
sudo -u postgres psql -c "select *, current_timestamp from pg_switch_wal()" ;
pg_switch_wal | current_timestamp
---------------+-------------------------------
0/26019600 | 2026-10-02 19:09:16.993398+00
(1 row)
少し待つと、pg-standbyにテーブルが現れます。
pg-standby ⇒ スタンバイに新しいテーブルが存在することを確認する(数回の再試行が必要な場合があります)
sudo -u postgres psql -c " \
select *, current_timestamp from replicated_table"
message | current_timestamp
----------------+-------------------------------
Important Data | 2026-10-02 19:09:22.793715+00
(1 row)
スタンバイがリポジトリにアクセスできる設定になっていることを確認します。
pg-standby ⇒ 設定を確認する
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info check
P00 INFO: check command begin 2.59.3: --exec-id=654-6b53cbe6 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo
P00 INFO: check repo1 (standby)
P00 INFO: switch wal not performed because this is a standby
P00 INFO: check command end: completed successfully
ストリーミングレプリケーション
ストリーミングレプリケーションは、WALアーカイブだけに頼らず、プライマリーに直接接続して、プライマリーで変更が行われるとすぐに適用します。そのため、プライマリーとスタンバイの間の遅延が大幅に減ります。
ストリーミングレプリケーションには、レプリケーション権限を持つユーザーが必要です。
pg-primary ⇒ レプリケーション用ユーザーを作成する
sudo -u postgres psql -c " \
create user replicator password 'jw8s0F4' replication" ;
スタンバイがレプリケーション用ユーザーとして接続できるよう、pg_hba.confを更新する必要があります。以下のIPアドレスは、必ずpg-standbyの実際のIPアドレスに置き換えてください。pg_hba.confの変更後は再読み込みが必要です。
pg-primary ⇒ レプリケーション用ユーザーのエントリをpg_hba.confに作成する
sudo -u postgres sh -c 'echo \
"host replication replicator 172.17.0.8/32 md5" \
>> /etc/postgresql/17/demo/pg_hba.conf'
sudo pg_ctlcluster 17 demo reload
スタンバイにはプライマリーへの接続方法を知らせる必要があるため、pgBackRestでprimary_conninfoを設定します。
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ primary_conninfoを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
recovery-option = primary_conninfo=host=172.17.0.6 port=5432 user=replicator
[global]
log-level-file = detail
repo1-host = repository
primary_conninfoにパスワードを設定することもできますが、.pgpassファイルのほうが柔軟かつ安全です。
pg-standby ⇒ .pgpassファイルにレプリケーションのパスワードを設定する。
sudo -u postgres sh -c 'echo \
"172.17.0.6:*:replication:replicator:jw8s0F4" \
>> /var/lib/postgresql/.pgpass'
sudo -u postgres chmod 600 /var/lib/postgresql/.pgpass
これでrestoreコマンドを使ってスタンバイを作成できます。
pg-standby ⇒ PostgreSQLを停止し、デモのスタンバイクラスターをリストアする
sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza= demo --delta --type= standby restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:30
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:56
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_time = '2026-10-02 19:07:12.060959+00'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_action = 'promote'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:10
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 19:07:57+00" --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:37
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:09:25
primary_conninfo = 'host=172.17.0.6 port=5432 user=replicator'
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
注:
primary_conninfoは、pgbackrest.confでrecovery-optionとして設定したため、postgresql.auto.confファイルに書き込まれています。既存のpostgresql.auto.confファイルをそのまま残したい場合は、restoreに--type=preserveオプションを指定できます。
pg-standby ⇒ PostgreSQLを起動する
sudo pg_ctlcluster 17 demo start
PostgreSQLのログで、ストリーミングレプリケーションが開始したことを確認できます。
pg-standby ⇒ PostgreSQLのログ出力で、成功を示すメッセージを確認する
sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
[filtered 13 lines of output]
LOG: consistent recovery state reached at 0/25000050
LOG: database system is ready to accept read-only connections
LOG: started streaming WAL from primary at 0/27000000 on timeline 7
これでpg-primaryにテーブルを作成すると、pg_switch_wal()を呼び出さなくても、pg-standbyにすぐ現れます。
pg-primary ⇒ プライマリーに新しいテーブルを作成する
sudo -u postgres psql -c " \
begin; \
create table stream_table (message text); \
insert into stream_table values ('Important Data'); \
commit; \
select *, current_timestamp from stream_table" ;
[filtered 4 lines of output]
message | current_timestamp
----------------+-------------------------------
Important Data | 2026-10-02 19:09:32.302145+00
(1 row)
pg-standby ⇒ スタンバイでテーブルにクエリーを実行する
sudo -u postgres psql -c " \
select *, current_timestamp from stream_table"
message | current_timestamp
----------------+-------------------------------
Important Data | 2026-10-02 19:09:32.491307+00
(1 row)
複数のstanza
pgBackRestは複数のstanzaをサポートします。最も一般的な用途は、複数のstanzaでリポジトリホストを共有することです。
インストール
新しいプライマリーを実行するため、pg-altという新しいホストを作成します。
pgBackRestはソースからビルドするより、パッケージからインストールすることをお勧めします。パッケージからインストールする場合、このセクションの残りの手順は通常不要ですが、パッケージが一部のディレクトリを作成しなかったり、誤った権限を設定したりする可能性があります。その場合は、手動でディレクトリを作成したり権限を更新したりする必要がある場合があります。
pgBackRestのDebian/Ubuntuパッケージはapt.postgresql.org
から入手できます。
使用するディストリビューションやバージョン向けのパッケージがない場合は、ソースからビルド
し、ここに示す手順で手動インストールできます。
pg-alt ⇒ 依存パッケージをインストールする
sudo apt-get install postgresql-client libxml2 libssh2-1
pg-alt ⇒ ビルド用ホストからpgBackRestバイナリをコピーする
sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest
pgBackRestには、ログディレクトリ、設定ディレクトリ、設定ファイルが必要です。
pg-alt ⇒ pgBackRestの設定ファイルとディレクトリを作成する
sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf
パスワードなしのSSHの設定
pgBackRestは、パスワードなしのSSHを使用してホスト間で通信できます。TLSも使用できます。TLSの設定
を参照してください。
pg-alt ⇒ pg-altホストのキーペアを作成する
sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
-t rsa -b 4096 -N ""
repositoryとpg-altの間で鍵を交換します。
repository ⇒ pg-altの公開鍵をrepositoryにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@pg-alt cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys
pg-alt ⇒ repositoryの公開鍵をpg-altにコピーする
( echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys
repositoryからpg-alt、およびその逆方向に接続できることをテストします。
repository ⇒ repositoryからpg-altへの接続をテストする
sudo -u pgbackrest ssh postgres@pg-alt
pg-alt ⇒ pg-altからrepositoryへの接続をテストする
sudo -u postgres ssh pgbackrest@repository
設定
pgBackRestの設定はpg-primaryとほぼ同じですが、demo-altstanzaを使うため、バックアップとアーカイブは別の場所に保存されます。
pg-alt:/etc/pgbackrest/pgbackrest.conf ⇒ 新しいプライマリーのpgBackRestを設定する
[demo-alt]
pg1-path = /var/lib/postgresql/17/demo
[global]
log-level-file = detail
repo1-host = repository
repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-userとpg1-pathを設定する
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/17/demo
[demo-alt]
pg1-host = pg-alt
pg1-path = /var/lib/postgresql/17/demo
[global]
process-max = 3
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
デモクラスターのセットアップ
pg-alt ⇒ デモクラスターを作成する
sudo -u postgres /usr/lib/postgresql/17/bin/initdb \
-D /var/lib/postgresql/17/demo -k -A peer
sudo pg_createcluster 17 demo
Configuring already existing cluster (configuration: /etc/postgresql/17/demo, data: /var/lib/postgresql/17/demo, owner: 102:103)
Ver Cluster Port Status Owner Data directory Log file
17 demo 5432 down postgres /var/lib/postgresql/17/demo /var/log/postgresql/postgresql-17-demo.log
pg-alt:/etc/postgresql/17/demo/postgresql.conf ⇒ PostgreSQLを設定する
archive_command = 'pgbackrest --stanza=demo-alt archive-push %p'
archive_mode = on
pg-alt ⇒ デモクラスターを起動する
sudo pg_ctlcluster 17 demo restart
stanzaの作成と設定の確認
stanzaを初期化するには、stanza-createコマンドを実行する必要があります。アーカイブとバックアップが正しく設定されていることを確認するため、stanza-createの後にcheckコマンドを実行することをお勧めします。
pg-alt ⇒ stanzaを作成して設定を確認する
sudo -u postgres pgbackrest --stanza= demo-alt --log-level-console= info stanza-create
P00 INFO: stanza-create command begin 2.59.3: --exec-id=386-f644abb9 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo-alt
P00 INFO: stanza-create for stanza 'demo-alt' on repo1
P00 INFO: stanza-create command end: completed successfully
sudo -u postgres pgbackrest --log-level-console= info check
P00 INFO: check command begin 2.59.3: --exec-id=396-8c7be3ca --log-level-console=info --log-level-file=detail --no-log-timestamp --repo1-host=repository
P00 INFO: check stanza 'demo-alt'
P00 INFO: check repo1 configuration (primary)
P00 INFO: check repo1 archive for WAL (primary)
P00 INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/17-1/0000000100000000/000000010000000000000001-ef9bc7e061e42fae1596a4f23d34fdb78ee324d0.gz' on repo1
P00 INFO: check command end: completed successfully
リポジトリホストでcheckコマンドを実行すると、すべてのstanzaが確認されます。
repository ⇒ すべてのstanzaの設定を確認する
sudo -u pgbackrest pgbackrest --log-level-console= info check
P00 INFO: check command begin 2.59.3: --exec-id=1284-38748c52 --log-level-console=info --no-log-timestamp --repo1-path=/var/lib/pgbackrest
P00 INFO: check stanza 'demo'
P00 INFO: check repo1 configuration (primary)
P00 INFO: check repo1 archive for WAL (primary)
P00 INFO: WAL segment 000000070000000000000027 successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000700000000/000000070000000000000027-f89bb62652ecba95477379768079564b0243a0d3.gz' on repo1
P00 INFO: check stanza 'demo-alt'
P00 INFO: check repo1 configuration (primary)
P00 INFO: check repo1 archive for WAL (primary)
P00 INFO: WAL segment 000000010000000000000002 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/17-1/0000000100000000/000000010000000000000002-de2b6314bf64b956ede5fad9e01f3d5f0200faff.gz' on repo1
P00 INFO: check command end: completed successfully
非同期アーカイブ
非同期アーカイブはarchive-asyncオプションで有効にします。このオプションにより、archive-pushとarchive-getの両コマンドが非同期に動作します。
スプールパスが必要です。各コマンドはここに一時的なデータを保存しますが、動作が大きく異なるため、スプールパスの使用方法は各セクションで詳しく説明します。
pg-primary ⇒ スプールディレクトリを作成する
sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest
pg-standby ⇒ スプールディレクトリを作成する
sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest
スプールパスを設定し、非同期アーカイブを有効にする必要があります。非同期アーカイブだけでもリモートストレージへの接続回数が減る利点がありますが、process-maxを設定して処理を並列化すると、性能が大幅に向上します。通常のデータベース操作に影響が出るほどprocess-maxを大きくしないようにしてください。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ スプールパスと非同期アーカイブを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
[global]
archive-async = y
log-level-file = detail
repo1-host = repository
spool-path = /var/spool/pgbackrest
[global:archive-get]
process-max = 2
[global:archive-push]
process-max = 2
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ スプールパスと非同期アーカイブを設定する
[demo]
pg1-path = /var/lib/postgresql/17/demo
recovery-option = primary_conninfo=host=172.17.0.6 port=5432 user=replicator
[global]
archive-async = y
log-level-file = detail
repo1-host = repository
spool-path = /var/spool/pgbackrest
[global:archive-get]
process-max = 2
[global:archive-push]
process-max = 2
注:
process-maxは、バックアップとリストアでこの設定を使わないよう、コマンド別のセクションで設定します。これにより、archive-pushとarchive-getに異なる値を設定することもできます。
デモのためにストリーミングレプリケーションを切断し、PostgreSQLがrestore_commandを使ってWALを取得するようにします。
pg-primary ⇒ レプリケーションのパスワードを変更してストリーミングレプリケーションを切断する
sudo -u postgres psql -c "alter user replicator password 'bogus'"
pg-standby ⇒ スタンバイを再起動して接続を切断する
sudo pg_ctlcluster 17 demo restart
アーカイブへの送信
非同期のarchive-pushコマンドは、WALのアーカイブ処理を別のプロセス(または複数のプロセス)に任せてスループットを向上させます。PostgreSQLが現在archive_commandで要求しているセグメントの先を調べ、アーカイブ可能なWALセグメントを確認して処理します。WALセグメントはpg_xlog/pg_walディレクトリから直接アーカイブに転送され、archive_commandが成功を返すのは、WALセグメントがアーカイブに安全に保存された後だけです。
スプールパスには、WALアーカイブの現在の状態を保存します。スプールディレクトリに書き込まれる状態ファイルは通常長さゼロで、使用する容量はごくわずか(最大でも数MB)、I/Oも非常に少ないはずです。このディレクトリの情報はすべて再作成できるため、クラスターを新しいハードウェアに移動する場合も、スプールディレクトリを保持する必要はありません。
重要:
非同期アーカイブの当初の実装では、圧縮と転送の前にWALセグメントをスプールディレクトリにコピーしていました。新しい実装では、pg_xlogディレクトリからWALを直接コピーします。v1.12以前で非同期アーカイブを利用していた場合は、アップグレード前にv1.13のリリースノートをよく読んでください。
[stanza]-archive-push-async.logファイルで、非同期プロセスの動作を監視できます。短時間に複数のWALセグメントを送信すると、動作のテストに適しています。
pg-primary ⇒ 並列の非同期アーカイブをテストする
sudo -u postgres psql -c " \
select pg_create_restore_point('test async push'); select pg_switch_wal(); \
select pg_create_restore_point('test async push'); select pg_switch_wal(); \
select pg_create_restore_point('test async push'); select pg_switch_wal(); \
select pg_create_restore_point('test async push'); select pg_switch_wal(); \
select pg_create_restore_point('test async push'); select pg_switch_wal();"
sudo -u postgres pgbackrest --stanza= demo --log-level-console= info check
P00 INFO: check command begin 2.59.3: --exec-id=2590-c51c0441 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo
P00 INFO: check repo1 configuration (primary)
P00 INFO: check repo1 archive for WAL (primary)
P00 INFO: WAL segment 00000007000000000000002D successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000700000000/00000007000000000000002D-1ed494e7471557cb0563baa2af44d9e1252e424f.gz' on repo1
P00 INFO: check command end: completed successfully
これでログファイルに並列かつ非同期の処理が記録されます。
pg-primary ⇒ ログで結果を確認する
sudo -u postgres cat /var/log/pgbackrest/demo-archive-push-async.log
-------------------PROCESS START-------------------
P00 INFO: archive-push:async command begin 2.59.3: [/var/lib/postgresql/17/demo/pg_wal] --archive-async --exec-id=2576-267f2388 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00 INFO: push 1 WAL file(s) to archive: 000000070000000000000028
P01 DETAIL: pushed WAL file '000000070000000000000028' to the archive
P00 INFO: archive-push:async command end: completed successfully
-------------------PROCESS START-------------------
P00 INFO: archive-push:async command begin 2.59.3: [/var/lib/postgresql/17/demo/pg_wal] --archive-async --exec-id=2594-5115f5d8 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00 INFO: push 5 WAL file(s) to archive: 000000070000000000000029...00000007000000000000002D
P02 DETAIL: pushed WAL file '00000007000000000000002A' to the archive
P01 DETAIL: pushed WAL file '000000070000000000000029' to the archive
P02 DETAIL: pushed WAL file '00000007000000000000002B' to the archive
P01 DETAIL: pushed WAL file '00000007000000000000002C' to the archive
P02 DETAIL: pushed WAL file '00000007000000000000002D' to the archive
P00 INFO: archive-push:async command end: completed successfully
アーカイブからの取得
非同期のarchive-getコマンドは、WALのローカルキューを維持してスループットを向上させます。要求されたWALセグメントがキューにない場合は、キューを満たすだけの後続WALとともにリポジトリから取得します。キューの最大サイズはarchive-get-queue-maxで定義します。キューが半分未満になるたびに、追加のWALを取得して満たします。
非同期動作は、大量のWALを生成する環境や、リポジトリストレージ(S3などのオブジェクトストア)との接続のレイテンシーが高い環境で特に有用です。レイテンシーが高い場合は、process-maxを増やすとよい場合があります。
[stanza]-archive-get-async.logファイルで、非同期プロセスの動作を監視できます。
pg-standby ⇒ ログで結果を確認する
sudo -u postgres cat /var/log/pgbackrest/demo-archive-get-async.log
-------------------PROCESS START-------------------
P00 INFO: archive-get:async command begin 2.59.3: [000000070000000000000024, 000000070000000000000025, 000000070000000000000026, 000000070000000000000027, 000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B] --archive-async --exec-id=871-5afe1731 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00 INFO: get 8 WAL file(s) from archive: 000000070000000000000024...00000007000000000000002B
P02 DETAIL: found 000000070000000000000025 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000024 in the repo1: 17-1 archive
P02 DETAIL: found 000000070000000000000026 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000027 in the repo1: 17-1 archive
P00 DETAIL: unable to find 000000070000000000000028 in the archive
P00 INFO: archive-get:async command end: completed successfully
[filtered 14 lines of output]
P00 INFO: archive-get:async command begin 2.59.3: [000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B, 00000007000000000000002C, 00000007000000000000002D, 00000007000000000000002E, 00000007000000000000002F] --archive-async --exec-id=924-87ccaa43 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00 INFO: get 8 WAL file(s) from archive: 000000070000000000000028...00000007000000000000002F
P02 DETAIL: found 000000070000000000000029 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000028 in the repo1: 17-1 archive
P02 DETAIL: found 00000007000000000000002A in the repo1: 17-1 archive
P01 DETAIL: found 00000007000000000000002B in the repo1: 17-1 archive
P02 DETAIL: found 00000007000000000000002C in the repo1: 17-1 archive
P01 DETAIL: found 00000007000000000000002D in the repo1: 17-1 archive
P00 DETAIL: unable to find 00000007000000000000002E in the archive
P00 INFO: archive-get:async command end: completed successfully
[filtered 15 lines of output]
pg-primary ⇒ レプリケーションのパスワードを変更してストリーミングレプリケーションを修復する
sudo -u postgres psql -c "alter user replicator password 'jw8s0F4'"
スタンバイからのバックアップ
pgBackRestは、プライマリーの代わりにスタンバイでバックアップを実行できます。スタンバイからのバックアップには、pg-standbyホストの設定とbackup-standbyオプションの有効化が必要です。複数のスタンバイが設定されている場合は、最初に見つかった稼働中のスタンバイをバックアップに使用します。
repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg2-host/pg2-host-userとpg2-pathを設定する
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/17/demo
pg2-host = pg-standby
pg2-path = /var/lib/postgresql/17/demo
[demo-alt]
pg1-host = pg-alt
pg1-path = /var/lib/postgresql/17/demo
[global]
backup-standby = y
process-max = 3
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
バックアップの実行には、プライマリーとスタンバイの両データベースが必要ですが、プライマリーの負荷を減らすため、ファイルの大半はスタンバイからコピーします。データベースホストの設定順序は任意です。pgBackRestがプライマリーとスタンバイを自動判別します。
repository ⇒ pg2からデモクラスターをバックアップする
sudo -u pgbackrest pgbackrest --stanza= demo --log-level-console= detail backup
[filtered 2 lines of output]
P00 INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00 INFO: backup start archive = 00000007000000000000002F, lsn = 0/2F000028
P00 INFO: wait for replay on the standby to reach 0/2F000028
P00 INFO: replay on the standby reached 0/2F000028
P00 INFO: check archive for prior segment 00000007000000000000002E
P03 DETAIL: backup file pg-standby:/var/lib/postgresql/17/demo/base/5/2658 (128KB, 8.47%) checksum 6bcdcabc7aaf3e4919655612f77833a1612baf01
P01 DETAIL: backup file pg-primary:/var/lib/postgresql/17/demo/global/pg_control (8KB, 8.99%) checksum aa003dff0afea4b06a88d00138da8e948a563345
P04 DETAIL: backup file pg-standby:/var/lib/postgresql/17/demo/base/5/1247 (120KB, 16.93%) checksum fa2fb6657bf9785e320a8a5516851de78d7a7a33
P01 DETAIL: match file from prior backup pg-primary:/var/lib/postgresql/17/demo/pg_logical/replorigin_checkpoint (8B, 16.93%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532
[filtered 1277 lines of output]
この増分バックアップでは、大半のファイルをpg-standbyホストからコピーし、pg-primaryホストからは少数のファイルだけをコピーしていることが分かります。
pgBackRestがスタンバイから作成するバックアップは、プライマリーで実行したバックアップと同一です。そのために、pg-primaryホストでバックアップを開始・停止し、レプリケーションされるファイルだけをpg-standbyホストからコピーして、残りの少数のファイルをpg-primaryホストからコピーします。したがって、プライマリーデータベースのログと統計情報もバックアップに含まれます。
PostgreSQLのアップグレード
PostgreSQLを新しいメジャーバージョンにアップグレードしたら、直ちにすべてのpgBackRest設定のpg-pathを新しいデータベースの場所に変更し、stanza-upgradeコマンドを実行する必要があります。ホストに複数のリポジトリが設定されている場合は、それぞれでstanzaをアップグレードします。データベースがオフラインの場合は、--no-onlineオプションを使用してください。
以下はPostgreSQLのアップグレードを網羅した手順ではありません。pgBackRestの再設定に必要な手順を示すため、プライマリーとスタンバイのアップグレードの大まかな流れを説明します。アップグレード前にバックアップを取ることをお勧めします。
pg-primary ⇒ 古いクラスターを停止する
sudo pg_ctlcluster 17 demo stop
スタンバイはアップグレードした新しいクラスターからリストアするため、スタンバイの古いクラスターも停止します。
pg-standby ⇒ 古いクラスターを停止する
sudo pg_ctlcluster 17 demo stop
新しいクラスターを作成してアップグレードします。
pg-primary ⇒ 新しいクラスターを作成してアップグレードする
sudo -u postgres /usr/lib/postgresql/18/bin/initdb \
-D /var/lib/postgresql/18/demo -k -A peer
sudo pg_createcluster 18 demo
sudo -u postgres sh -c 'cd /var/lib/postgresql && \
/usr/lib/postgresql/18/bin/pg_upgrade \
--old-bindir=/usr/lib/postgresql/17/bin \
--new-bindir=/usr/lib/postgresql/18/bin \
--old-datadir=/var/lib/postgresql/17/demo \
--new-datadir=/var/lib/postgresql/18/demo \
--old-options=" -c config_file=/etc/postgresql/17/demo/postgresql.conf" \
--new-options=" -c config_file=/etc/postgresql/18/demo/postgresql.conf"'
[filtered 44 lines of output]
Checking for extension updates ok
Upgrade Complete
----------------
Some statistics are not transferred by pg_upgrade.
[filtered 4 lines of output]
新しいクラスターの設定とポートを設定します。
pg-primary:/etc/postgresql/18/demo/postgresql.conf ⇒ PostgreSQLを設定する
archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
すべてのシステムでpgBackRestの設定を更新し、新しいクラスターを参照させます。
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-pathを更新する
[demo]
pg1-path = /var/lib/postgresql/18/demo
[global]
archive-async = y
log-level-file = detail
repo1-host = repository
spool-path = /var/spool/pgbackrest
[global:archive-get]
process-max = 2
[global:archive-push]
process-max = 2
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ pg-pathを更新する
[demo]
pg1-path = /var/lib/postgresql/18/demo
recovery-option = primary_conninfo=host=172.17.0.6 port=5432 user=replicator
[global]
archive-async = y
log-level-file = detail
repo1-host = repository
spool-path = /var/spool/pgbackrest
[global:archive-get]
process-max = 2
[global:archive-push]
process-max = 2
repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-pathとpg2-pathを更新し、スタンバイからのバックアップを無効にする
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/18/demo
pg2-host = pg-standby
pg2-path = /var/lib/postgresql/18/demo
[demo-alt]
pg1-host = pg-alt
pg1-path = /var/lib/postgresql/17/demo
[global]
backup-standby = n
process-max = 3
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y
pg-primary ⇒ hba設定をコピーする
sudo cp /etc/postgresql/17/demo/pg_hba.conf \
/etc/postgresql/18/demo/pg_hba.conf
新しいクラスターを起動する前に、stanza-upgradeコマンドを実行する必要があります。
pg-primary ⇒ stanzaをアップグレードする
sudo -u postgres pgbackrest --stanza= demo --no-online \
--log-level-console= info stanza-upgrade
P00 INFO: stanza-upgrade command begin 2.59.3: --exec-id=3025-70610f0d --log-level-console=info --log-level-file=detail --no-log-timestamp --no-online --pg1-path=/var/lib/postgresql/18/demo --repo1-host=repository --stanza=demo
P00 INFO: stanza-upgrade for stanza 'demo' on repo1
P00 INFO: stanza-upgrade command end: completed successfully
新しいクラスターを起動し、正しくインストールされたことを確認します。
pg-primary ⇒ 新しいクラスターを起動する
sudo pg_ctlcluster 18 demo start
checkコマンドを使って設定をテストします。
pg-primary ⇒ 設定を確認する
sudo pg_lsclusters
sudo -u postgres pgbackrest --stanza= demo check
古いクラスターを削除します。
pg-primary ⇒ 古いクラスターを削除する
sudo pg_dropcluster 17 demo
スタンバイに新しいPostgreSQLバイナリをインストールし、クラスターを作成します。
pg-standby ⇒ 古いクラスターを削除し、新しいクラスターを作成する
sudo pg_dropcluster 17 demo
sudo pg_createcluster 18 demo
リポジトリホストでcheckを実行します。スタンバイクラスターは停止しているため、スタンバイが停止しているという警告は想定どおりです。このコマンドの実行により、リポジトリサーバーがスタンバイを認識し、プライマリーサーバーに対して正しく設定されていることを確認できます。
repository ⇒ 設定を確認する
sudo -u pgbackrest pgbackrest --stanza= demo check
P00 WARN: unable to check pg2: [DbConnectError] raised from remote-0 ssh protocol on 'pg-standby': unable to connect to 'dbname='postgres' port=5432': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
新しいクラスターでフルバックアップを実行し、そのバックアップからスタンバイをリストアします。incrまたはdiffを要求しても、バックアップの種類は自動でfullに変更されます。
repository ⇒ フルバックアップを実行する
sudo -u pgbackrest pgbackrest --stanza= demo --type= full backup
pg-standby ⇒ デモのスタンバイクラスターをリストアする
sudo -u postgres pgbackrest --stanza= demo --delta --type= standby restore
pg-standby ⇒ PostgreSQLを起動し、pgBackRestの設定を確認する
sudo pg_ctlcluster 18 demo start
sudo -u postgres pgbackrest --stanza= demo check
スタンバイのリストアが完了したので、スタンバイからのバックアップを有効にできます。
repository:/etc/pgbackrest/pgbackrest.conf ⇒ スタンバイからのバックアップを再び有効にする
[demo]
pg1-host = pg-primary
pg1-path = /var/lib/postgresql/18/demo
pg2-host = pg-standby
pg2-path = /var/lib/postgresql/18/demo
[demo-alt]
pg1-host = pg-alt
pg1-path = /var/lib/postgresql/17/demo
[global]
backup-standby = y
process-max = 3
repo1-path = /var/lib/pgbackrest
repo1-retention-full = 2
start-fast = y