// シス担のミカタ
データベース

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

PITRポイントインタイムリカバリバックアップデータ復元RDSWAL
ポイントインタイムリカバリについて教えて

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

「あの日の午後2時のDB状態に戻したい！」ができる機能だよ。誤ってデータを削除したり、バグで大量データが壊れたりしたとき、任意の時点まで時計を巻き戻せる「DBの時間旅行」みたいな仕組みなんだ！

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

PITR（Point-in-Time Recovery：ポイントインタイムリカバリ）は、データベースを過去の任意の時点の状態に復元できる機能です。「昨日の14:30分時点のデータに戻す」のような細かい時刻指定が可能です。

PITRの仕組みは定期バックアップ + トランザクションログの組み合わせです。たとえば毎日0時にフルバックアップを取り、それ以降のすべての変更操作（WAL: Write-Ahead Log）を記録しておきます。「昨日の14:30に戻したい」場合は昨日0時のバックアップを復元してから、14:30までのWALを順番に再適用することで目的の状態に到達します。

Amazon RDSでは最大35日間のPITRが可能です。Cloud SQL（Google Cloud）は最大365日間まで設定できます。なおPITRで復元したDBは、元のDBとは別の新しいDBインスタンスとして作成されます（既存DBが上書きされるわけではない）。

PITRの仕組み

ステップ内容
①自動バックアップ設定した保持期間内で自動的にスナップショットを取得
②WAL/binlogの連続記録すべての変更操作をトランザクションログとして記録
③復元時点の指定秒単位で復元したい日時を指定
④バックアップ適用指定時点直前のバックアップから新DBを作成
⑤ログ再適用指定時点までのトランザクションログを順次適用
⑥新インスタンス完成指定時点の状態のDBが別インスタンスとして起動

想定される利用シナリオ

  • 誤ったDELETE/DROP — オペレーターが誤って重要データを削除
  • バグによるデータ破損 — リリース直後のバグで大量データが更新された
  • 不正アクセスによる改ざん — サイバー攻撃でデータが書き換えられた
  • テスト/検証目的 — 特定時点のデータを取り出してデバッグ

歴史と背景

  • 1980年代 — Oracle DBのRedo Log + Archive Logによるリカバリが商用DB標準に
  • PostgreSQL 8.x〜 — WALアーカイブを使ったPITRが標準機能として追加
  • 2009年 — Amazon RDSがマネージドPITRをクラウドサービスとして提供開始
  • 現在 — クラウドのマネージドDBではPITRはほぼ標準機能として提供

バックアップとPITRの関係

PITRの仕組み（タイムライン） Day1 バックアップ Day2 バックアップ Day3 バックアップ 誤削除！ Day3 14:30 ← この時点に戻したい Day3 12:00 連続トランザクションログ（WAL/binlog）を常時記録

関連する規格・RFC

規格内容
WAL（Write-Ahead Logging）トランザクションをコミット前にログに書く標準手法
ISO/IEC 9075 (SQL標準)SQLのトランザクション管理仕様

関連用語