Amazon RDS には Point-in-Time Recovery、つまり特定時点への復元があります。名前だけ見ると、障害後に「この時刻へ戻す」と指定すれば使えそうに見えます。

でも、PITR は魔法の巻き戻しボタンではありません。前提になるのは、自動バックアップを事前に有効化していることです。障害が起きてから慌てて設定しても、過去のバックアップは生成されません。

この記事では、RDS の PITR が使えない典型パターンと、自動バックアップをどう設計に組み込むべきかを整理します。

先に結論

RDS の Point-in-Time Recovery は、自動バックアップが事前に有効になっていないと使えません。

障害後に「PITR を使えば戻せるはず」と考えても、バックアップとログが残っていなければ戻す材料がありません。

| 観点 | 要点 |

|---|---|

| PITR の前提 | 自動バックアップが有効であること |

| 復元範囲 | バックアップ保持期間内 |

| 復元方式 | 多くの場合、新しい DB として復元 |

| よくある失敗 | 障害後に初めて自動バックアップを有効化する |

PITR は事故後の魔法ではなく、事故前に準備する保険です。

なぜ自動バックアップが必要なのか

PITR は、RDS が保持している自動バックアップとトランザクションログを使って復元します。つまり、復元したい時点のデータを再構成する材料が必要です。自動バックアップが無効だった期間については、その材料がありません。

```text

自動バックアップ有効

-> バックアップとログが蓄積される

-> 保持期間内で PITR を検討できる

自動バックアップ無効

-> 復元材料がない

-> 障害後に有効化しても過去には戻れない

```

この仕様は冷たいですが、かなり自然です。記録していない過去は復元できません。

障害後に有効化しても遅い

典型的な失敗パターンは次です。

1. 本番 RDS を作る

2. コストや設定漏れで自動バックアップを無効にする

3. 誤更新や削除が起きる

4. PITR で戻そうとする

5. 自動バックアップがなくて詰む

この状態で後から設定を変えても、過去のバックアップは生えません。クラウドは便利ですが、都合よくタイムマシンにはなりません。

保持期間は業務要件で決める

自動バックアップを有効にするだけでは不十分です。保持期間も設計対象です。短すぎると、問題に気づいた時点で復元可能期間を過ぎている可能性があります。

考えるべき質問は次です。

  • 誤操作に何時間、何日で気づけるか
  • 夜間バッチの失敗はいつ検知されるか
  • リリース後の不具合調査に何日分必要か
  • 本番と検証環境で同じ保持期間が必要か
  • 手動スナップショットとどう使い分けるか

保持期間は「なんとなく 7 日」ではなく、検知と復旧の現実から決めます。雑に決めると、ちょうど必要な日だけ足りない、という最低の負け方をします。

復元先は新しい DB として考える

PITR は、既存 DB をその場で巻き戻すものとして考えない方が安全です。通常は、指定時点の状態を持つ新しい DB インスタンスを作ります。

  • 新しい DB インスタンスを作成する
  • データが期待時点に戻っているか確認する
  • 必要なら差分データを確認する
  • アプリケーションの接続先を切り替える
  • DNS、環境変数、Parameter Store などを更新する
  • 元 DB をいつまで残すか決める

復元ボタンを押せることと、サービスを復旧できることは別です。ここを混ぜると、手順書だけ立派な紙装甲になります。

PITR、スナップショット、Multi-AZ を混同しない

| 仕組み | 主目的 | PITR の代わりになるか |

|---|---|---|

| 自動バックアップ + PITR | 特定時点への復元 | これが本命 |

| 手動スナップショット | 明示的な復元点、長期保管 | 一部補完する |

| Multi-AZ | 障害時の高可用性 | ならない |

| Read Replica | 読み取り負荷分散 | ならない |

Multi-AZ は DB 障害時に止まりにくくするための構成です。Read Replica は読み取りを逃がすための構成です。どちらも、アプリが誤ってデータを壊したときの時点復元とは別問題です。

最低限の設計チェック

  • 自動バックアップが有効か
  • 保持期間は復旧要件に合っているか
  • バックアップウィンドウを把握しているか
  • 復元テストを実施済みか
  • 復元後の接続先切り替え手順があるか
  • リリース前に手動スナップショットを取る運用があるか
  • IaC にバックアップ設定が明示されているか

特に IaC は大事です。コンソールで一度設定しただけだと、再作成や環境追加のときに漏れます。バックアップ設定は「人間の記憶」ではなくコードに寄せた方が安全です。

まとめ

RDS の PITR は強力ですが、使える条件があります。

  • PITR には自動バックアップが必要
  • 自動バックアップは事前に有効化しておく
  • 復元できる範囲は保持期間に依存する
  • 障害後に有効化しても過去分は復元できない
  • 復元後の接続先切り替えまで手順化する
  • Multi-AZ や Read Replica は PITR の代替ではない

PITR は、障害が起きた日に始めるものではありません。本番 DB を作る日に設計しておくものです。自動バックアップ、保持期間、復元テスト。この 3 つがない PITR 前提の運用は、だいたい祈祷です.