データベース全般におけるバックアップ

データベースのバックアップには、PostgreSQLに限らず、一般的に論理/物理、また、オンライン/オフラインがあります。まず、この分類の説明をします。また、RPO/RTOという考え方についても説明します。

論理バックアップ/物理バックアップ

論理バックアップは、データベースの内容をSQL文のテキスト形式や同内容のバイナリ形式でバックアップすることです。リストアはそのSQL文を実行することで行います。物理バックアップとは、データベースのOS上のデータ格納ファイルをそのままの形でバックアップすることです。利用しているOSやデータベースソフトウェアのみ理解できる形式です。

オンラインバックアップ/オフラインバックアップ

オンラインバックアップは、データベースサービスが起動している状態で行うバックアップです。ホットバックアップとも言います。オフラインバックアップとは、データベースサービスが停止している状態で行うバックアップです。コールドバックアップとも言います。

後述するPostgreSQLのバックアップ用のコマンドは全てオンラインバックアップを実行します。オフラインバックアップは、サービスが停止している状態で、OSのコマンド(cp, tar 等)や、ストレージ装置や仮想化基盤によるスナップショット機能で、データベースの格納ディレクトリを丸ごとコピーして、それを物理バックアップとすることで実現できます。

RPO/RTO

RPO（Recovery Point Objective）はおおまかに「障害発生時にどの時点までデータベースをリカバリするか」という意味です。バックアップ方式によって実現可能なRPOが異なりますので、RPOはバックアップ方式を選択するときの判断基準の一つです。データが日々更新される状況において、データベースに障害が発生した場合、理想は障害の直前のデータまで復旧することになります。

RPO と同じ文脈でよく語られる言葉としてRTO（Recovery Time Objective）があります。これは「リカバリ作業にどのくらい時間がかかるか」という意味です。こちらもバックアップ方式の重要な選択基準となります。

PostgreSQL におけるバックアップ

ここからはPostgreSQL についての説明になります。なお、文中で PostgreSQLドキュメントのリンクを提示するときにはバージョン17文書のURLを使用していますので、皆さんが実際に使っている PostgreSQLバージョンに読み替えてください。

バックアップ対象

バックアップ対象となるデータベースサーバの構成を図示すると下記の様になります。物理的な見方と論理的な見方があります。前者はファイルとディレクトリであり、後者は利用者から見えるデータベース内の要素です。

PostgreSQLは1つのデータベースクラスタとWALファイル群に対応して、1つのサービスを起動します。データベースクラスタはinitdbコマンドで作成するものです。

「データベースクラスタ」の中には「データベース」がいくつか存在します。「データベース」の中には「スキーマ」がいくつか存在します。スキーマにはデータベースを作成した時に自動的に作成されるパブリックスキーマの他に、ユーザがそれぞれの用途で使用するスキーマがあります。

pg_dump は論理バックアップを行い、その対象は「データベース」や「スキーマ」です。テーブル単位の指定も可能です。実行時にデータベースやスキーマを指定することで、それぞれの単位でバックアップファイルを作成します。pg_dumpallも論理バックアップを行い、その対象は「データベースクラスタ」です。実行するとデータベースクラスタ全体のバックアップファイルを作成します。pg_basebackupのバックアップは物理バックアップを行い、対象は「データベースクラスタ」です。

グローバルオブジェクト

データベースクラスタにはグローバルオブジェクトが存在します。グローバルオブジェクトとは、個々のデータベースに属さないロール情報やアクセス制限に関する情報などです。これらは各データベースから共通して使用されます。

WALファイル

WALファイルとは更新情報が書き込まれるファイルです。データベースクラスタの更新よりも先にWALファイルが更新されます。データベースへの更新（INSERT等）が発生した場合、データの更新の順序は下記の通りです。

1. データ更新は共有バッファ（メモリ）上のデータで実行されます。
2. 更新内容はWALファイルに書き出されます。
3. 共有バッファ上のデータ更新は下記のタイミングでデータベースクラスタ内のファイルに反映されます。
   • 時間経過や更新量に応じて発生するチェックポイント処理で
   • 共有バッファが不足したとき
   • バックグラウンドライターの動作で

このようにすることで、データ更新中にデータベースサーバの電源が落ちたり、PostgreSQLサーバプロセスが強制終了されたりしても、次にサービス起動するときには、WALファイルを読み込んで記録されている変更を適用することで、整合性のあるデータ状態に復旧する仕組みになっています。

対応する更新内容をデータベースクラスタに反映し終えたWALファイルは、チェックポイント処理の時に順次削除されます。

バックアップ方法

それではPostgreSQLの具体的なバックアップ方法を見ていきます。

ダンプ

PostgreSQL付属コマンドのpg_dumpとpg_dumpallを使用して、オンライン論理バックアップを取得することができます。このバックアップはダンプと呼ばれます。pg_dumpは1つのデータベース、または、その中の指定スキーマや指定テーブルを対象とします。pg_dumpall はグローバルオブジェクトを含むデータベースクラスタ全体を対象とします。pg_dumpall を -g (--globals-only) オプションで実行して、グローバルオブジェクトのみをバックアップすることも可能です。

pg_dumpとpg_dumpallはPostgreSQLのクライアントアプリケーションとして動作します。したがって、データベースサーバ内からでも、リモートサーバからでもバックアップの取得が可能です。

バックアップファイルの形式は、pg_dumpではテキスト形式かいくつかのバイナリ形式を選択できます。pg_dumpallはテキスト形式のみです。バイナリ形式はpg_restoreでテキスト形式に変換できます（pg_restoreで直接リストアすることもできます）。これらのコマンドはデータ定義だけのバックアップ、データだけのバックアップなども可能です。対象のデータベース、スキーマ、テーブルを限定することもできます。

ダンプは論理バックアップであるため、PostgreSQLのメジャーアップデート時のデータ移行にも利用できます。ただし、PostgreSQL固有のSQL文(COPY等やSET文)が含まれるため、他のデータベースソフトウェアむけにそのまま適用することはできません。pg_dumpに--insertsオプションを指定して、COPY文をINSERT文に変えて出力することはできます。

ベースバックアップ

PostgreSQL付属コマンドのpg_basebackupではオンラインの物理バックアップを取得できます。これにより取得するバックアップはベースバックアップと呼ばれます。取得されるのはデータベースクラスタディレクトリのコピー、または、それをいくつかのtar形式のファイルに纏めたものです。デフォルト動作ではバックアップ取得中に生じたWALファイルも取得されます。

ベースバックアップは、動作プラットフォームやPostgreSQLのメジャーバージョンに依存しています。異なる環境むけにリストアすることができません。が異なる場合は利用できません。PostgreSQLマイナーバージョンが異なる環境にはリストア可能ですが追加の対処が必要なケースもあるので、個別のバージョンの情報の確認も必要になります。

ディレクトリをバックアップする任意の手段でベースバックアップを取得することもできます。バックアップの取得前に管理者ユーザ（一般的にはpostgresユーザ）でデータベースに接続し、pg_backup_start()関数を実行して、オフラインバックアップと同様に、OSのコマンドでデータベースのディレクトリ構成を丸ごとコピーして、最後に同じセッションでpg_backup_stop()関数を実行し、応答行のbackup_label列、tablespace_map列の内容をそれぞれ列名と同じファイル名でバックアップ先のデータベースクラスタディレクトリ下に保存します。これらの手順を行なうことで整合性のあるリストアが可能となります。これはpg_basebackupコマンドが内部で実行していることとほぼ同じです。なお、PostgreSQL 14 までは、pg_backup_start()、pg_backup_stop() 関数はそれぞれ、pg_start_backup()、pg_stop_backup() という名前でした。

ベースバックアップ取得は、SQLとしてのデータ参照を行わないため、ダンプ取得と比べると稼働中のPostgreSQLに対する負荷が低いという特徴があります。一般的には取得のための所要時間もより短くなります。

リストア方法

ダンプのリストア

ダンプのリストアは、稼働中のPostgreSQLサービスに対して、ダンプに書かれているSQLを実行することで行います。ダンプを取得開始した時点のデータ状態に戻すことができます。

テキスト形式のダンプをリストアするにはpsqlコマンドでダンプに書かれているSQLを実行します。-f (--file=) オプションで指定する、リダイレクションで標準入力として与える、接続後に \iメタコマンドで読み込む、など、いずれの方法でも構いません。

バイナリ形式のダンプのリストアにはpg_restoreコマンドを使用します。pg_restoreコマンドでテキスト形式に戻して、SQL文をpsqlコマンドで実行することも可能です。

pg_dumpallで取得したテキスト形式のダンプをリストアする場合には、initdb コマンドで初期状態のデータベースクラスタを作成して、そこでPostgreSQLサービスを起動して、そこにpsqlコマンドでダンプファイルを実行します。

ベースバックアップのリストア

ベースバックアップのリストアは、バックアップを元通りのデータベースクラスタディレクトリとして配置して、そこでPostgreSQLサービスを起動することで行います。取得中のWALファイルを含むベースバックアップであれば、起動過程でWALファイルの適用が行われて、バックアップ取得が完了した時点の整合性のあるデータ状態にリストアされます。

WALファイルを含まないベースバックアップのリストアには、別途WALファイルを適用させる手順が必要です。これについて次節で述べます。

ベースバックアップからのリストアは、一般にダンプからのリストアよりも高速です。ダンプからのリストアは全データを復元するSQLの実行であるのに対して、ベースバックアップからのリストアはバックアップ取得中の差分のWALを適用するだけであるからです。

PITR (Point-In-Time Recovery)

ベースバックアップからのリストアでは、バックアップ取得時だけでなく、その後の任意の時点にリストアすることができます。これを PITR（Point-In-Time Recovery）と呼びます。

PostgreSQL の設定でWALファイルを指定したディレクトリに退避して保管(アーカイブ)させることができます。具体的には、postgresql.conf の archive_modeを on に、archive_commandに WALファイルをアーカイブ格納先にコピーするコマンドを設定します。

古いWAL ファイルは自動的に削除されますが、アーカイブとしてWALファイルを退避してすることで、それらのWAL書き込みがあった時点まで復元することが可能になります。この処理はバックアップ取得の操作とは別個に、バックグラウンドで適時実行されます。ベースバックアップに加えてWALファイルのアーカイブを使うことで、PITRが実現できます。障害が発生した直前までのアーカイブWALをベースバックアップからのリストアに使用することで、RPO を障害直前時点とすることができます。また、誤操作を復旧するために、誤操作した時刻直前を指定してリストアする使い方もできます。

WALアーカイブを使ったベースバックアップからのリストアを行うには、データベースクラスタディレクトリにrecovery.signalファイル（空ファイルで良い）を置いて、postgresql.conf の restore_commandにアーカイブからWALをコピーするコマンドを設定したうえで、PostgreSQLサービスを起動します。

PITRを行うときに復元時点がベースアップ取得時点から離れていると、その分リストアに時間がかかり、保存しておくWALアーカイブも大量に必要となります。そのため、定期的にベースバックアップを取得して、古いベースバックアップを削除して、その削除したベースバックアップのリストアのために必要だったWALもアーカイブから削除していくのが一般的です。あるベースバックアップがどのアーカイブWALファイルまでを必要としているかは、ベースバックアップ時に生成される .backup サフィックスのファイルに書かれています。このファイルは WALと同じディレクトリに作られて、WALと共にアーカイブもされます。pg_archivecleanupコマンドに残したい最も古いベースバックアップに対応した .backupファイルを指定すれば、不要なアーカイブWALファイルを削除してくれますので、これが簡単な方法です。

PITRの具体的な構成手順とリストア手順はPostgreSQLドキュメントに記載があります。

増分バックアップ

PostgreSQL 17以降、pg_basebackupでベースバックアップの増分バックアップを行う-i（--incremental)オプションが利用可能になりました。ベースバックアップを比較的短い周期で何世代も取得する場合、ほとんど同じ内容のバックアップを多数持つことになります。増分バックアップでは、前回のベースバックアップを指定して、それに対するデータベースクラスタの変更分だけをバックアップします。これにより、格納サイズを節約できます。増分バックアップを行うためには、postgresql.conf で summarize_wal = on の設定と、wal_summary_keep_timeにバックアップ周期以上の期間を設定することが必要です。

リストアには完全なフルバックアップとその後に実行した複数の増分バックアップを全てマージする必要があります。マージにはpg_combinebackupコマンドを利用し、フルバックアップのパス、増分バックアップのパス(複数指定可)、出力先を指定して実行します。マージすると完全なベースバックアップが作られて、以降のリカバリ手順は通常のベースバックアップと同じです。

なお、WALファイルも変更差分が書かれたものですが、1つのベースバックアップと大量のWALファイルからリストアするよりも、完全なベースバックアップといくつかの増分バックアップ、少量のWALファイルでリストアする方が、一般的に所要時間が短くて済みます。

設定ファイルのバックアップ

設定ファイルもバックアップが必要です。ダンプバックアップの場合、設定ファイルは対象外ですので、pg_dumpや pg_dumpallコマンドの実行に加えて、postgresql.conf 等の .confファイルを明示的にバックアップ先にコピーしておくことが必要です。pg_basebackupはデータベースクラスタディレクトリをまるまるバックアップするので、設定ファイルもバックアップデータに含まれる結果となります。

まとめ

最後にこれまで説明してきたバックアップ方式について一覧にまとめます。

本稿がPostgreSQLバックアップ方式の検討、選定に役立てば幸いです。

PostgreSQL には様々なバックアップの方法が提供されています。
それぞれのバックアップの方法は利点が違い、運用方法も手順も異なります。
今回はバックアップ方法の簡単なおさらいと、PostgreSQL 17 で標準機能として追加された増分バックアップについて紹介します。

PostgreSQLのバックアップの種類

PostgreSQL のバックアップは大きく論理バックアップ と 物理バックアップの 2 種類に分類できます。

論理バックアップ

SQL レベルでデータを取得する方式です。
CREATE TABLE や INSERT 文などで現在のデータベースの状態を再現できるファイルを生成します。
異なるOSアーキテクチャ間や PostgreSQL メジャーバージョン間でもリストア可能という柔軟性が大きな利点です。

物理バックアップ

データベースクラスタ全体のディレクトリを丸ごと保存する方式です。
Linux の cp コマンドや PostgreSQL 標準ツールである pg_basebackup を利用できます。
pg_basebackup では PITR（Point-In-Time Recovery）や PostgreSQL 17 で追加された 増分バックアップ を利用できる点が最大の特徴です。

今回は、この「増分バックアップ」について詳しく紹介します。

増分バックアップとメリット

増分バックアップは、ある時点で取得したフルバックアップをベースとし、その後に変更された部分だけを保存する方式です。

たとえば、10 TB のデータベースを毎日 30 日分フルバックアップで保存すると、
10 TB × 30 日 = 300 TB もの容量が必要になります。

しかし増分バックアップであれば、
初日のフル 10 TB + 毎日の変更分のみを保存すればよく、大幅なストレージ削減が可能です。
上記の図は毎日の変更分を10GBと想定した場合の比較図となります。

また、バックアップ取得時間も短縮できます。
フルバックアップではすべてのデータをコピーするため時間がかかりますが、増分バックアップは変更分だけを取得するためバックアップ時間の短縮につながります。
また結果としてサーバー負荷の軽減にも寄与します。

増分バックアップの手順

従来、PostgreSQL で増分バックアップを行いたい場合は、サードパーティツールである pg_rman の利用が一般的でした。
ただし、pg_rman は Windows 非対応という課題がありました。

PostgreSQL 17 ではこれらの問題が解消され、標準機能として増分バックアップがサポートされました。
主な追加項目は以下のとおりです。

1. pg_basebackup に増分バックアップを取得する -​-incremental オプションが追加
2. フルバックアップと増分バックアップを統合する pg_combinebackup コマンドの追加
3. 増分バックアップの制御にかかわる summarize_wal, wal_keep_summary パラメータの追加

これらによって増分バックアップの取得が可能になっています。
それぞれのコマンドやパラメータの扱い方について詳しく見ていきましょう。

動作確認環境と postgresql.conf のパラメータは以下です。

動作環境

postgresql.conf パラメータ

増分バックアップのコマンド

増分バックアップの手順は大きく分けて以下です。

1. pg_basebackup によるフルバックアップの取得
2. pg_basebackup -​-incremental による増分バックアップの取得
3. pg_combinebackup によるフルバックアップと増分バックアップの統合

コマンド実行例をもとに見ていきましょう。

フルバックアップ取得前の時点では full_backup というテーブルがあるのみです。

これから各増分バックアップ取得時点でテーブルを追加していき、各世代のバックアップの状態にリストアできるかを見ていきます。

$ psql
psql (17.6)
"help"でヘルプを表示します。
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
(1 行)

最初に pg_basebackup コマンドでフルバックアップを取得します。

# -P オプションでサイズや進捗を確認可能
$ pg_basebackup  -D backup/full -P
23818/23818 kB (100%), 1/1 テーブル空間

その後 inc1 テーブルを作成し、一回目の増分バックアップを取得します。

ここで pg_basebackup に新規で追加された -​-incremental オプションを用います。
引数には前回取得したバックアップ、つまりフルバックアップの backup_manifest ファイルを指定します。
backup_manifest ファイルはバックアップのトップディレクトリにあるのでそちらのパスを指定してください。

postgres=# create table inc1 (i int);
CREATE TABLE
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1

二回目の増分バックアップも同様に inc2 テーブルを作成後取得します。

この時注意が必要なのが前回のバックアップを指定することです。
今回だとフルバックアップではなく一回目の増分バックアップの backup_manifest を指定します。

postgres=# create table inc2 (i int);
CREATE TABLE
$ pg_basebackup --incremental=backup/inc1/backup_manifest -D backup/inc2

最後に pg_combinebackup で各世代を統合していきます。
pg_combinebackup の -o オプションでは統合バックアップの出力先を指定し、その後の引数はフルバックアップから統合したい世代までの増分バックアップをすべて指定します。

統合後はpg_verifybackupでバックアップの整合性も忘れずチェックするようにしてください。

# フルバックアップからinc1(inc1 テーブルがある時点)まで
$ pg_combinebackup -o backup/combine_full_inc1 backup/full/ backup/inc1
# フルバックアップからinc2(inc1, inc2 テーブルがある時点)まで
$ pg_combinebackup -o backup/combine_full_inc2 backup/full/ backup/inc1 backup/inc2/
# 各統合バックアップを pg_verifybackup で検証
$ pg_verifybackup backup/combine_full_inc1
バックアップが正常に検証されました
$ pg_verifybackup backup/combine_full_inc2
バックアップが正常に検証されました

各世代増分バックアップの中身を確認

では、各世代のバックアップが正しく取得できているか確認してみましょう。

統合バックアップを、それぞれ異なる port 番号 に設定して起動すると、各世代におけるinc1、inc2テーブルの状態が、作成時点の内容として保持されていることが分かります。

この検証により、全ての世代でバックアップが正しく取得されていることを確認できました。

$ pg_ctl -o "-p 5433" start -D backup/combine_full_inc1/
$ psql –p 5433
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
 public   | inc1        | テーブル | postgres
$ pg_ctl -o "-p 5434" start -D backup/combine_full_inc2/
$ psql –p 5434
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
 public   | inc1        | テーブル | postgres
 public   | inc2        | テーブル | postgres

増分バックアップのストレージコストと取得時間

最初に挙げたメリットとして、ストレージコストとバックアップ取得時間を抑えられる点がありました。
ここでは、実際にどの程度削減できているのか確認してみます。

まずストレージ使用量を比較すると、初回に取得したフルバックアップは 888 MB と比較的大きなサイズでした。
一方、続いて取得した増分バックアップは どれも約 4 MB 程度 と非常に小さく抑えられています。

これを「すべての世代をフルバックアップで保存する場合」と比べてみると、毎回 888 MB 近く消費することになります。
それに対して増分バックアップは変更分のみを保存すればよいため、世代を重ねてもバックアップ容量を大幅に抑えられる ことが分かります。

$ du -h  --max-depth=1 backup/
888M     backup/full
6M     backup/inc1
4M     backup/inc2

また time コマンドでバックアップ取得の時間も比べてみましょう。

pg_basebackup -​-incremental と -​-incremental オプションなしのフルバックアップの取得時間を比べてみると、-​-incremental での増分バックアップは取得時間がかなり短いことが分かります。

$ time pg_basebackup -D backup/inc_3 --incremental=backup/inc2/backup_manifest -c fast -P
  4045/888986 kB (100%), 1/1 テーブル空間
real    0m4.391s
$ time pg_basebackup -D backup/full_3 -c fast -P
888986/888986 kB (100%), 1/1 テーブル空間
real    0m32.777s

pg_combinebackup のオプション

pg_combinebackup には統合のファイルコピーを高速化するオプションが用意されています。

ファイルコピーを高速化するオプション

デフォルトのオプション以外はすべて高速化できるものの、すべて入出力のディレクトリが同じファイルシステムである必要がある点には注意してください。
-​-copy-file-range, -​-clone については実行できる環境に上記表のような制限もあります。

同期のオプション

同期する範囲を指定できるオプションもあり、
同期対象を増やすほどディスクへの書き込みがより確実に行われるようになります。

デフォルトではバックアップ対象のディレクトリのみですが、-​-plain で WAL ファイルとテーブル空間全体のシンボリックリンクまで、-​-syncfs ではバックアップディレクトリを含むファイルシステム全体を同期の対象とできます。

-​-syncfs はファイルを一つ一つ開かず同期をチェックするため同期が素早く完了できるというメリットもあります。

増分バックアップ使用上の注意点

注意点は大きく分けて以下の3つです。それぞれ見ていきます。

1. パラメータの管理
2. フルバックアップ～増分バックアップの保存
3. ストレージ容量

パラメータの管理

増分バックアップで管理すべきパラメータは以下です。

1. summarize_wal
2. wal_level
3. wal_summary_keep_time

summarize_wal は pg_basebackup -​-incremental をする際に参照する wal の情報をまとめたサマリファイルを作成するか否かを制御するパラメータです。

このファイルがない状態で増分バックアップを取得しようとするとエラーとなり取得に失敗してしまいます。
デフォルトでは off となっていますので忘れずに on としてください。

# summarize_wal が off で取得したフルバックアップを対象とするとエラー
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1
pg_basebackup: エラー: ベースバックアップを開始できませんでした: 
ERROR:  WAL集約が有効でなければ差分バックアップは取得できません

wal_level についても replica 以上が必要です。
これが replica 以上でないと summarize_wal のパラメータが無効となる仕様となっています。

wal_summary_keep_time はサマリファイルを保存する期間を指定するパラメータです。
例えば以下のように 1d に設定し、2 日後に増分バックアップを取得しようとすると必要なサマリファイルが削除されているため、取得に失敗してしまいます。
そのため、増分バックアップを取得する運用間隔よりも長い期間を設定する必要があります。

# postgresql.conf の wal_summary_keep_time を 1d に設定
wal_summary_keep_time = '1d'

$ ls –l  data/pg_wal/summaries/
-rw-------. 1 postgres postgres 32 11月 1 16:52 0000000100000001CF00002800000001D0000028.summary
# 2 日後に増分バックアップを取得しようとすると失敗
$ date
2025年 11月 3日 月曜日 15:37:55 JST
$ pg_basebackup -D backup/inc_1 --incremental=backup/full/backup_manifest -P -c fast
pg_basebackup: エラー: ベースバックアップを開始できませんでした:
ERROR:  WAL集計がタイムライン1上の1/CD000060から1/CF000028まで必要ですが、そのタイムライン上のそのLSN範囲での集計は不完全です
DETAIL:  この範囲で集計されていない最初のLSNは1/CD000060です

フルバックアップ～増分バックアップの保存

pg_combinebackup をする際に引数フルバックアップ～統合したい世代までのフルバックアップがすべてないと以下エラーとなります。

# 最初の引数にフルバックアップを指定せずに実行
$ pg_combinebackup -o backup/combine_test backup/inc1 backup/inc2
pg_combinebackup: エラー: "backup/inc1"のバックアップは差分バックアップですが、最初のバックアップはフルバックアップである必要があります
# backup/inc_1 を引数に渡さず実行
# LSN 位置に飛びが見られエラーとなる
$ pg_combinebackup -o backup/combine_1 backup/full/ backup/inc_2
pg_combinebackup: エラー: "backup/full/"のバックアップはLSN 1/1A000060で始まっていますが、1/1C000028を期待していました

そのため、実際の運用ではフルバックアップと、最新世代までのすべての増分バックアップを保持しておく必要があります。
削除のタイミングとしては、定期的に pg_combinebackup を実行し、統合によって 不要になった過去のフルバックアップおよび増分バックアップを削除するフローになります。

また、統合して生成されたバックアップは、次回の pg_combinebackup におけるフルバックアップとして利用可能 であるため、統合元となった古いフルバックアップは削除して問題ありません。

ストレージ容量

ストレージコストの低さがメリットの増分バックアップですが、pg_combinebackup をした直後は古いバックアップと統合バックアップが共存する状態になりますので、それらすべてを保存できるストレージサイズを確保する必要があります。

増分バックアップと
PITR と両立したリストア手順

増分バックアップ PITR と両立しての増分バックアップを利用することができます。

PITR(Point In Time Recovery) は WAL アーカイブをもとにして任意の時点までのリストアを可能にするリストア方法です。

WAL アーカイブはデータの変更履歴が記載されたもので、事前に取得しておいたフルバックアップに WAL アーカイブの変更履歴を任意の時点まで適用することで任意の時点に復旧できることが強みのリストア方法です。

この PITR と増分バックアップと両立することで以下メリットが得られます。

1. 増分バックアップによるバックアップ取得でストレージコストや取得時間を短く抑えられる
2. PITR によるリストアでより任意の時点に復旧することができる

今回はこれらを両立する設計で具体的な設定手順を紹介します。

まずパラメータの設定を行います。

#wal をアーカイブする設定
#%p は保管するWALファイルの相対パス, %f がWALのファイル名に置き換わる
archive_mode = on
archive_command = 'cp "%p" "/pg_arc/%f"'
#restore を行う設定
restore_command = 'cp "/pg_arc/%f" "%p"'

その後増分バックアップ取得を行います。
フルバックアップ、増分バックアップ取得、バックアップの統合、検証の手順で取得します。

# フルバックアップ～バックアップの取得・統合、検証まで実施
$ pg_basebackup  -D backup/full
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1
$ pg_combinebackup -o backup/combine_full_inc1 backup/full/ backup/inc1
$ pg_verifybackup backup/combine_full_inc1

その後 mv コマンドで疑似的にデータベースのデータが消えてしまった状態を作ります。

そして統合したバックアップを元のデータディレクトリに mv で移動し、recovery.signal を作成して起動すると PITR のリカバリモードで起動します。
リカバリ終了後に状態を見に行くとデータが指定した時点に復旧していることが分かります。

# データを移動して障害を疑似的に起こす
$ mv data data_crash
# 統合したバックアップを元ディレクトリにコピー
$ cp –r databackup/combine_full_inc1 data
# リカバリモードで起動するよう指示するrecovery.signal を作成して起動
$ touch data/recovery.signal
# 必要に応じて postgresql.conf を設定し復旧タイミングを指定
recovery_target_time = '2025-10-20 14:05:00'
$ pg_ctl start
# ログに以下が出力されていれば復旧完了
LOG: starting archive recovery
LOG: archive recovery complete

まとめ

今回は PostgreSQL 17 で追加された増分バックアップの運用方法と注意点について紹介しました。

PostgreSQL18ではさらに機能が追加されたりと今後より便利になっていく注目の手法です。
紹介した手順を参考に増分バックアップの利用を検討いただけると幸いです。