// シス担のミカタ
データベース管理・運用

ポイントインタイムリカバリ ぽいんといんたいむりかばりー

PITRWALバックアップ障害復旧RPOPostgreSQL
ポイントインタイムリカバリについて教えて

簡単に言うとこんな感じ！

ポイントインタイムリカバリ（PITR）は「DB版タイムマシン」だよ！ 昨日の夜10時に誰かがテーブルを誤って全削除しちゃったとき、「夜9時59分の状態」まで巻き戻せる。フルバックアップとWALログを組み合わせることで、どの時点にも戻れる魔法みたいな機能なんだ！

ポイントインタイムリカバリとは

ポイントインタイムリカバリ（PITR：Point-in-Time Recovery）とは、フルバックアップに加えてその後の変更ログ（WAL：Write-Ahead Log / バイナリログ）を継続的に保存しておくことで、障害発生前の任意の時点にデータベースを復元できる技術です。

通常のバックアップ・リストアでは「最後にバックアップした時点」にしか戻れません。バックアップが毎日深夜0時に行われているとすると、夕方6時に発生した誤操作でデータが消えた場合、0時以降6時間分のデータは復元できません（RPO = 最大24時間）。PITRを使えば変更ログを継続アーカイブしているため、「夕方5時59分の状態」まで復元でき、RPOを数分〜数秒レベルに縮小できます。

最も利用頻度が高い場面はヒューマンエラーです。開発者が本番DBで誤ってDELETE FROM orders;やDROP TABLE customers;を実行してしまった際に、直前の時点へ復元するために使います。

PITRの仕組み

PITRの動作フロー フルバックアップ 深夜0時（毎日） WALアーカイブ 変更を継続的にS3等へ保存 障害発生 夕方18:00 誤操作 ↓ リカバリ実行 ①フルバックアップを 復元（0時の状態） ②WALを17:59まで再適用 （再生する時間を指定） 17:59の状態に 復元完了！ 障害発生1分前の状態を復元。1日分ではなくわずか1分分のデータ損失で済む restore_command と recovery_target_time を postgresql.conf に設定

PostgreSQLでのPITR設定例

# postgresql.conf（バックアップ側）
archive_mode = on
archive_command = 'aws s3 cp %p s3://my-bucket/wal/%f'

# recovery.conf または recovery_target_time 指定（リストア側）
restore_command = 'aws s3 cp s3://my-bucket/wal/%f %p'
recovery_target_time = '2026-04-11 17:59:00'

歴史と背景

  • 1990年代：OracleがRedo Logを活用したアーカイブログモードでPITRに相当する機能を提供
  • 2001年：PostgreSQL 7.1 でWALが実装。PITRの基盤が整う
  • 2005年：PostgreSQL 8.0 でPITR（ポイントインタイムリカバリ）が正式サポートされる
  • 2010年代：Amazon RDS・Google Cloud SQLなどクラウドマネージドDBがPITRをデフォルト機能として提供
  • 現在：RDS for PostgreSQL/MySQLは最長35日間のPITRを提供。ボタン1つで指定時刻に復元できるUIが整備されている

関連する規格・RFC

規格内容
PostgreSQL WAL仕様Write-Ahead Log によるリカバリの実装仕様
Oracle Archive Log ModePITRの先行実装として参照される業界標準

関連用語