はじめに

こんにちは！NTTテクノクロスでPostgreSQLの技術支援をやっています、中村です。

PostgreSQL17の新機能として、pg_basebackup の増分バックアップが実装されましたね。

PostgreSQLで増分バックアップといえば周辺ツールの pg_rman ですが、本体機能としても提供されるようになったことで、どちらを使っていけば良いか気になるところだと思います。
そこで今回は、pg_basebackup の増分バックアップと、pg_rman の増分バックアップについて比較していきます。

また、pg_rman については、NTTテクノクロスのアドベントカレンダーとして、Qiita の記事でも紹介していますので、あわせてご覧ください。

Qiita記事：
pg_rman の増分バックアップは前回バックアップからの差分だった！もう迷わない！

バックアップ管理のしやすさは pg_rman、利用環境の制約が少ないのは pg_basebackup

pg_rman と pg_basebackup の機能面の違いを比較すると、以下のようになります。

比較項目	pg_rman	pg_basebackup
オンラインでのバックアップの取得	〇	〇
増分バックアップの取得	〇	〇
累積増分バックアップの取得	×	×
バックアップの圧縮	〇	〇
追加インストールの要否	必要	不要
バックアップ履歴の自動管理	〇	×
リストアの容易性	〇	△
Windows対応	×	〇
遠隔サーバからのバックアップ	×	〇

後半５つが、pg_rman と pg_basebackup で違いのある項目になります。
それでは個別に確認していきましょう。

追加インストールの要否

pg_basebackup は PostgreSQL本体機能の一部のため、追加のインストールは不要です。

一方で、pg_rman は本体に組み込まれていない周辺ツールのため、追加のインストールが必要になります。
最新の PostgreSQL17 にも対応しており特にデメリットにはなりませんが、PostgreSQLのメジャーバージョンアップから少し遅れて提供されることになるため、 利用可能になるまで若干のタイムラグがあるという点に注意が必要です。

バックアップ履歴の自動管理

pg_rman は、バックアップ履歴のカタログファイルを作成し、ユーザにわかりやすい形で見せることが可能です。
イメージは以下の通りで、バックアップ時間やサイズ、フルバックアップなのか増分バックアップなのかが一目でわかります。

[postgres@localhost ~]$ pg_rman show -B /var/lib/pgsql/pg_rman
=====================================================================
StartTime           EndTime              Mode    Size   TLI  Status 
=====================================================================
2025-03-10 05:45:07  2025-03-10 05:45:09  INCR   295MB     1  DONE
2025-03-10 04:49:47  2025-03-10 04:50:01  FULL  1674MB     1  OK

上記の「Status」は、バックアップファイルの状態を示します。バックアップ直後は「DONE」で、この状態のままではリストアに使用できません。
バックアップ取得後に、pg_rman validate コマンドで検査を行うことにより「OK」になり、リストアに使用可能になります。

－－
pg_basebackup にはバックアップしたファイルの管理機能はありませんので、ユーザ自身でバックアップファイルを管理する必要があります。
必須ではありませんが pg_basebackup で取得したバックアップにも、pg_verifybackup コマンドで検査を行うことが可能です。

pg_basebackup の運用方法は増分バックアップの有無で大きく変わりませんが、増分バックアップを取得する場合はリストアの順序を考慮した管理が必要になるため、煩雑にならないように注意する必要があります。

参考に、 pg_basebackup で取得したフルバックアップと増分バックアップのファイルを見てみましょう。

■フルバックアップ
[root@localhost pg_basebackup]# ls -ltr 17_3_full_2/base/16384/*16394*
-rw-------. 1 postgres postgres 1073741824  3月 10 04:57 17_3_full_2/base/16384/16394
-rw-------. 1 postgres postgres  534036480  3月 10 04:57 17_3_full_2/base/16384/16394.1
-rw-------. 1 postgres postgres     417792  3月 10 04:57 17_3_full_2/base/16384/16394_fsm


■増分バックアップ
[root@localhost pg_basebackup]# ls -ltr 17_3_inc1/base/16384/*16394*
-rw-------. 1 postgres postgres       12  3月 10 05:11 17_3_inc1/base/16384/INCREMENTAL.16394
-rw-------. 1 postgres postgres 76611584  3月 10 05:11 17_3_inc1/base/16384/INCREMENTAL.16394.1
-rw-------. 1 postgres postgres   434176  3月 10 05:11 17_3_inc1/base/16384/16394_fsm

増分バックアップには「INCREMENTAL」という名前が付けられており、増分であることがわかりますね。

このテーブルはINSERTで差分を発生させています。ファイルサイズを見てください。
・フルバックアップの「16394.1」ファイルは 534MB ですが、
・増分バックアップの「INCREMENTAL.16394.1」ファイルは 76MB と、INSERTしたデータ分のサイズ相当になっています。

なお、増分バックアップを取得した実際のデータベースクラスタの中を見ると、

[root@localhost data]# ls -ltr base/16384/*16394*
-rw-------. 1 postgres postgres 1073741824  2月 12 22:46 base/16384/16394
-rw-------. 1 postgres postgres  610598912  3月 10 05:11 base/16384/16394.1
-rw-------. 1 postgres postgres     434176  3月 10 05:11 base/16384/16394_fsm

となっており、
「現在のサイズ：610MB」＝「フルバックアップ時のサイズ：534MB」＋「増分バックアップのサイズ：76MB」
となっていますね。

fsmファイルは「INCREMENTAL」がついていないため、単純に日付の新しいファイルに置き換えられそうです。

リストアの容易性

pg_rman はコマンド一つでリストア（PITR）が可能なため、容易です。これは、増分バックアップの利用有無を問いません。

pg_basebackup で取得したバックアップを用いてリストア（PITR）するには、以下のいずれかの作業が必要になります。

①フルバックアップ＋アーカイブWALを用意し、PostgreSQL設定ファイルを編集してから、起動する
②フルバックアップ＋増分バックアップ＋アーカイブWALを用意し、フルバックアップと増分バックアップをマージしてから、PostgreSQL設定ファイルを編集し、起動する
　※増分バックアップを用いる場合は、先にフルバックアップと増分バックアップを pg_combinebackup コマンドでマージする作業が必要になります。

また、pg_rman はアーカイブWALもバックアップに含まれていますが、pg_basebackup ではアーカイブWALはバックアップに含まれません。 そのため、pg_basebackup を使って取得したバックアップからPITRを行う場合、別途アーカイブWALを準備しておく必要があります。

Windows対応

pg_rman は Windows上での動作に対応していませんが、pg_basebackup コマンドは本体同梱のため Windows上でも利用可能です。

遠隔サーバからのバックアップ

pg_rman は PostgreSQL が動作しているサーバ上でのみ使用することが可能です。遠隔のサーバ上で動作している PostgreSQL のバックアップは 取得できません。
またバックアップ先も同一サーバ内に限定されます。

pg_basebackup は、遠隔サーバ上で動作している PostgreSQL も、ローカルサーバ上の PostgreSQL もバックアップ対象とすることが可能です。
このとき、バックアップ先は、
・PostgreSQL が動作しているサーバ上にバックアップを取得する
・pg_basebackup が動作しているサーバ上にバックアップを取得する
のいずれでも対応が可能です。

そもそも、増分バックアップってどういうときに使えばいいの？

ここまで、pg_rman と pg_basebackup がそれぞれ増分バックアップを使用することができることを説明してきました。
そこで次は、増分バックアップの使いどころについて確認していきたいと思います。

増分バックアップを使うメリットは、以下と考えています。

項目	pg_rman	pg_basebackup
バックアップのディスク容量を減らす	〇	〇
バックアップ時間が速くなる可能性がある	〇	〇
リカバリ時間の短縮が見込める可能性がある	〇	〇

逆に、上記のメリットを必要としないケースでは、増分バックアップを使用しなくてよい、ということになります。
「毎日フルバックアップを取得できる時間的余裕があり」「ディスク容量も気にしなくてよく」「リカバリにかかる時間も要件に収まっている」という状況ですね。
この場合はフルバックアップを使用したほうが、運用が簡易です。

では、増分バックアップを使用するメリットについてみていきましょう。

バックアップ容量を減らす

増分バックアップを使用することで、毎日フルバックアップを取得するよりもバックアップサイクル全体としての バックアップ容量を減らすことが可能と考えます。

例えば、サイズが10GBのデータベースのバックアップを35日間保管するという要件がある場合、 毎日フルバックアップだと
10GB×35日＝350GB
必要になります。
これが、増分バックアップだと1日1GBの場合だと、週1回のフルバックアップ＋週6回の増分バックアップで対応できるため、
（10GB＋1GB×6日）×5週間＝80GB
で済む計算になります。
（実際にはアーカイブWALもバックアップする必要がありますが、アーカイブWAL自体のバックアップサイズには差が生じないため、ここでは省略します。）

バックアップ時間が速くなる可能性がある

上記と同じように、フルバックアップが10GBで、増分バックアップが1GBの場合、単純に10分の1にはなりませんが、 バックアップサイズはディスクの読み書き時間に影響するため、バックアップ時間が高速化される可能性が高いです。

リカバリ時間の短縮が見込める可能性がある

毎日フルバックアップを取得している場合、そこからリカバリするのが最も速いのは間違いありません。

ただし、
・週1でフルバックアップ。残りの曜日はアーカイブWALのみをバックアップ。
という運用を行っているケースでは、リカバリの際に最大7日分のアーカイブWALを適用する必要がありますが、

・週1でフルバックアップ。残りの曜日は増分バックアップとアーカイブWALをバックアップ。
とすることで、リカバリの際にアーカイブWALを適用する時間を短縮でき、復旧が高速になりえます。

さらに、pg_basebackup の増分バックアップの場合、フルバックアップと増分バックアップの結合は、リカバリ時ではないタイミングでも実施できます。
これを利用して、毎日の増分バックアップ後に、フルバックアップとその日取得した増分バックアップをマージしておくことで、リカバリ時の作業時間を短縮するといった運用も可能です。

まとめ

お疲れ様でした。本記事では PostgreSQL17 の新機能である、増分バックアップと、pg_rman の増分バックアップの違いについて説明してきました。

AWSやAzureなどのクラウド環境で提供されているマネージドサービスでは、自動バックアップ機能が提供されているため、ユーザはバックアップ運用を考える必要がありませんが、オンプレ環境などではバックアップ運用についていくつもの選択肢のなかから最適な方法を選択する必要があります。

「毎日フルバックアップを取得」するだけの運用ではバックアップ、リカバリ要件を満足させるのが困難な場合、増分バックアップを使用することでうまく運用できるかもしれません。

それでは、本記事は以上となります！
ここまでお付き合い頂き、ありがとうございました！

PostgreSQLのことならNTTテクノクロスにおまかせください！

NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせや、移行に関する対応を受け付けています。
オンプレだけではなく、Azure、AWSなどのクラウド上でのシステムの導入、開発、維持管理のご相談もお待ちしております。

移行サービスはこちら