Amazon RDS には Point-in-Time Recovery、つまり特定時点への復元があります。名前だけ見ると、障害後に「この時刻へ戻す」と指定すれば使えそうに見えます。
でも、PITR は魔法の巻き戻しボタンではありません。前提になるのは、自動バックアップを事前に有効化していることです。障害が起きてから慌てて設定しても、過去のバックアップは生成されません。
この記事では、RDS の PITR が使えない典型パターンと、自動バックアップをどう設計に組み込むべきかを整理します。
まず結論
RDS の Point-in-Time Recovery を使うには、対象 DB インスタンスで自動バックアップが事前に有効化されている必要があります。
| やりたいこと | 必要な前提 | 注意点 |
|---|---|---|
| 昨日の状態に戻したい | 自動バックアップが有効 | 保持期間内であること |
| 障害直前の時点に近づけたい | 自動バックアップとトランザクションログ | 完全に任意の秒へ戻せるとは限らない |
| 障害後に初めて PITR を使いたい | 事前設定が必要 | 後から過去分は作れない |
| 既存 DB を直接巻き戻したい | 復元先 DB を作成 | 元 DB がその場で戻るわけではない |
雑に言うと、PITR は事後対応ではなく、事前に掛けておく保険です。ここを間違えると、復旧手順書がただの願望になります。
PITR は何をしているのか
RDS の PITR は、自動バックアップとトランザクションログを使って、保持期間内の特定時点に近い状態へ DB を復元する機能です。
たとえば、誤ってテーブルを更新した、アプリのバグでデータを壊した、深夜バッチが想定外の DELETE を走らせた、というケースで使います。
ただし、PITR は「今ある DB をそのまま過去へ戻す」機能ではありません。通常は、指定した時点の状態を持つ新しい DB インスタンスとして復元します。その後、アプリケーションの接続先切り替えや差分確認を行います。
自動バックアップを後から有効にしても過去には戻れない
一番多い勘違いはこれです。
「障害が起きた。PITR したい。では自動バックアップを今から有効化しよう」
これは遅いです。自動バックアップは、有効化された後のバックアップとログをもとに復元可能な期間を作ります。昨日の時点で無効だったなら、昨日に戻す材料はありません。
2026-05-10 自動バックアップ無効
2026-05-11 誤更新が発生
2026-05-12 自動バックアップを有効化
=> 2026-05-11 の状態へ PITR する材料がない
保険証を事故後に作っても、昨日の事故は補償されません。インフラも同じです。
保持期間を設計する
PITR を使える範囲は、自動バックアップの保持期間に依存します。保持期間は長ければ正義、というほど単純ではありません。コスト、運用、復旧要件を見て決めます。
検討すべき観点は次の通りです。
- 誤操作に気づくまでの最大時間
- バッチ処理やリリース失敗を検知するまでの時間
- 監査や調査で必要になる復元期間
- コスト許容度
- スナップショット運用との分担
たとえば、誤更新に数日気づけない業務なら、保持期間 1 日では短すぎます。
PITR は既存 DB を直接戻すわけではない
PITR で復元すると、基本的には新しい DB インスタンスが作られます。そのため、復旧計画には次の作業が含まれます。
- 復元先 DB の作成
- 復元時点の確認
- 壊れたデータとの差分確認
- アプリケーション接続先の切り替え
- DNS や Parameter Store など設定値の更新
- 元 DB を残すか削除するかの判断
「PITR があるから安心」で止めるのは危険です。復元後にどうサービスへ戻すかまで決めて、初めて復旧設計になります。
スナップショットとの違い
| 機能 | 向いている用途 | 特徴 |
|---|---|---|
| 自動バックアップ + PITR | 誤操作や障害直前への復元 | 保持期間内の時点復元に向く |
| 手動スナップショット | リリース前、移行前、長期保管 | 明示的に残せる |
| Multi-AZ | DB 障害時の可用性 | PITR の代替ではない |
| Read Replica | 読み取り負荷分散 | バックアップ設計の代替ではない |
リリース前に確実な復元点を残したいなら手動スナップショット。日常的な誤更新や障害に備えるなら自動バックアップと PITR。可用性を上げたいなら Multi-AZ。目的を混ぜると、だいたい事故ります。
本番投入前のチェックリスト
- 自動バックアップが有効か
- バックアップ保持期間は要件に合っているか
- バックアップウィンドウは業務影響を考慮しているか
- 復元テストを一度でも実施したか
- 復元後の接続先切り替え手順があるか
- 手動スナップショットを取るタイミングが決まっているか
- Terraform や CloudFormation など IaC に設定が残っているか
特に復元テストは重要です。バックアップは「取れているはず」ではなく、「戻せることを確認済み」で初めて意味があります。
まとめ
RDS の Point-in-Time Recovery は便利ですが、障害後に都合よく過去を作る機能ではありません。
- PITR の前提は自動バックアップが事前に有効であること
- 復元できるのは保持期間内
- 後から自動バックアップを有効にしても過去分は作れない
- PITR は通常、新しい DB インスタンスとして復元する
- 復元後の接続先切り替えまで設計する必要がある
- 手動スナップショット、Multi-AZ、Read Replica とは役割が違う
バックアップ設計は、障害が起きる前にしかできません。PITR を使いたいなら、まず自動バックアップを有効化し、保持期間と復旧手順を決めておく。地味ですが、ここをサボると本番障害で本当に笑えません.