【ITニュース解説】Setting up incremental backups with PostgreSql - Recovery - Part 3

データベースの運用において、データのバックアップは極めて重要である。しかし、バックアップがあるだけでなく、いざという時にそのデータを確実に復元できる能力はさらに重要になる。PostgreSQLが提供するPITR（Point-In-Time Recovery）という機能は、この復元能力を大幅に高めるもので、Barmanというツールによって完全に管理できる。

PITRは、例えば人為的なミスでデータが誤って削除されたり、システム展開後に問題が発生したり、あるいは特定の時点でのデータベースの状態を分析したい場合などに非常に役立つ。Barmanを使うことで、PostgreSQLのデータベースを過去の任意の時点まで戻し、指定した時点までの変更のみを適用して復元することが可能になる。

PITRとは、データベースを過去の特定の日時に正確に戻すことができるPostgreSQLの強力な機能である。データベースに何らかの問題が発生した場合、例えば午前10時30分にデータが破損したと仮定すると、PITRを利用すれば問題発生直前の午前9時29分の状態にデータベースを復元できる。この機能を実現するために、PostgreSQLはデータベースへの書き込み操作の全てをWAL（Write Ahead Logs）というファイルに記録する。これらのファイルには、データベースに対して行われた全ての変更履歴が含まれている。Barmanは、このWALファイルと既存のフルバックアップを組み合わせて、選択された時点までデータベースの履歴を再実行することで、データベースを特定の時点に巻き戻す。

事業継続性や災害復旧を考える上で、バックアップやBarmanのようなツールを導入する前に、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）という二つの重要な概念を理解しておく必要がある。

RPOは、インシデント発生時に許容できる最大のデータ損失量を指す。例えば、5分間のデータ損失を許容できる場合、RPOは5分となる。これは、バックアップやWALの記録が少なくとも5分ごとに行われるべきであることを意味する。

RTOは、インシデント発生後にサービスを復旧させるまでに許容できる最大の停止時間を指す。例えば、30分間のサービス停止を許容できる場合、RTOは30分となる。これは、Barmanや自動化された復元メカニズムが、この時間枠内でサービスを復旧できる必要があることを意味する。

理想的にはデータ損失ゼロ（RPO=0）とダウンタイムゼロ（RTO=0）が望ましいが、現実にはコストとサービスの重要性との間でバランスを取る必要がある。例えば、単なる情報提供ウェブサイトであれば数時間のRPO/RTOが許容されるかもしれないが、金融系のアプリケーションではRPO/RTOはほぼゼロに近づける必要がある。PostgreSQLとBarmanを適切に設定することで、PostgreSQLの同期ストリーミングレプリケーションを利用しデータ損失なしのRPO=0を達成し、Barmanによるバックアップとrepmgrによる高可用性を組み合わせることで、最小限のRTOでほぼ瞬時の復旧が可能となる。

PITRによる復元を行うには、いくつかの前提条件を満たしている必要がある。第一に、Barman内に有効なフルバックアップが少なくとも一つ存在していなければならない。これは復元の開始点となる。第二に、PITRはWALのリプレイに依存するため、WALのアーカイブが正しく機能しており、BarmanのWALディレクトリにファイルが存在することを確認する必要がある。第三に、復元処理はデータベースの新しいコピーを作成するため、ターゲットサーバーに十分な空きディスク容量があることを確認する。第四に、復元時点を正確に指定するため、日付と時刻、トランザクションID（XID）、または単にバックアップの終了時刻のいずれかを指定する必要がある。最後に、本番環境で復元する前に、隔離されたテスト環境で復元プロセスを試すことが強く推奨される。

Barmanを用いたデータ復元の具体的な手順について説明する。まず、テストデータベースにテーブルを作成し、複数のデータを挿入するスクリプトを実行する。その後、Barman上でbarman backup pgコマンドを実行して増分バックアップを取得する。このバックアップ取得の終了時刻は、復元時のターゲット時刻として重要なので控えておく。

次に、偶数IDを持つレコードを削除することで、データ損失をシミュレートする。この操作により、テーブル内のレコード数は半分になる。この状態がPITRを使って元の状態に戻す絶好の機会となる。データ損失後、再度barman backup pgコマンドで新しいバックアップを取得し、PostgreSQLサーバーを停止する。

これで、データ損失を挟む二つのバックアップ、つまりインシデント発生前のバックアップと発生後のバックアップが存在する状態になる。PITRでは、このインシデント発生前のバックアップを基点として利用する。

Barmanサーバー上で、barman recoverコマンドを実行して復元を開始する。このコマンドには、PostgreSQLサーバーへのSSH接続情報、復元したい正確な時刻、対象サーバー名、使用するバックアップID、および復元先のディレクトリを指定する。例えば、--target-time="2025-04-15 20:17:58.270833+00:00"のように時間を指定する。復元先のディレクトリは、PostgreSQLのメインデータディレクトリ以外の任意の場所を指定することも可能で、その場合はPostgreSQLの設定を変更して新しいディレクトリを指し示すようにする。復元が完了すると、PostgreSQLサーバーが復旧準備完了の状態になる。最後に、データベースを起動し、レコード数を再度確認すると、削除されたはずの偶数IDのレコードも全て復元され、元の20件のレコードに戻っていることが確認できる。

人為的なミス、ソフトウェアの破損、ハードウェアの故障は、いつ発生するかの問題であり、発生しないという保証はない。このような状況において、PostgreSQLを過去の正確な状態に戻せる能力は、事業継続性にとって不可欠である。BarmanとPITRを組み合わせることで、フルバックアップとアーカイブされたWALファイルを活用し、インシデント発生の正確な秒単位までデータベースを復元できる、信頼性が高く堅牢なツールを手に入れることができる。このプロセスは自動化、テスト、そして実用化が可能であり、PostgreSQLアーキテクチャの回復力を高める上で多大な利点を提供する。