RDS バックアップ・PITR・スナップショット【誤削除復旧シナリオ】
RDS 自動バックアップ＋PITR（ポイントインタイムリカバリ）の仕組み。DROP TABLE からの復旧、スナップショット vs PITR の使い分け、クロスリージョン複製。
自動バックアップ
自動バックアップを有効にすると、指定したバックアップ保持期間の範囲で、データのスナップショットとトランザクションログが取得されます。これにより PITR（Point-in-Time Recovery） が可能になり、障害や誤った DROP TABLE のような操作のあと、保持期間内の任意の時刻に近い状態へ新しいインスタンスを復元できます。
試験で効くポイントは次のとおりです。
- RPO … 自動バックアップの取得間隔とログ保持で、どれだけ過去に戻せるかが決まる（「最新に近い」ほど RPO は小さい）。
- バックアップウィンドウ … 負荷の少ない時間帯に設定するのが一般的。スナップショット取得時の I/O スパイクに注意。
- 保持期間を過ぎた時点の PITR はできない … 長期保管は手動スナップショットや別リージョンコピーの論点に繋がる。
保持日数の上限・既定値はエンジンと時期で変わるため、Amazon RDS のバックアップで確認してください。
手動スナップショット
手動スナップショットは、運用者がタイミングを決めて取得するDB ボリュームのコピーです。用途は次のとおりです。
- 本番からステージング環境を複製する。
- 自動バックアップの保持期間より長く保管する。
- メジャーアップグレード前のセーフティとして取る。
スナップショットは S3 に格納されるイメージで、耐久性の高いバックエンドに載る、という説明がよく使われます。
リストアとコピー
スナップショットまたは PITR からは、新しい DB インスタンスをプロビジョニングして復旧します（既存インスタンスをその場で巻き戻すわけではない）。エンドポイントが変わるため、アプリは接続先の更新や Route 53 の切り替えが必要になる場合があります。
DR の文脈では、スナップショットを別リージョンにコピーし、災害時にそこからリストアするパターンが定番です。コピー時の暗号化キーとKMS のクロスリージョンの扱いが選択肢になります。
暗号化との関係
保管時暗号化を有効にした DB のスナップショットは、同じ KMS キーで保護されます。別アカウントや別リージョンへ共有する場合は、スナップショットのコピーとキーポリシーが論点になります。
非暗号化 DB を後から暗号化にしたい場合は、スナップショットを取ってコピー時に暗号化を有効にし、そこからリストアする、という移行パターンが試験に出ます。
削除時の注意
DB インスタンスを削除するとき、コンソールでは次のような選択が出ます。
- 最終スナップショットを作成するか … 誤削除や将来の復旧余地のため推奨される文脈が多い。
- 自動バックアップ … インスタンス削除とともに消えるイメージ（手動スナップショットは残る）。
コスト削減で即削除する問題では、「スナップショットなしで消す」がリスクになる、という読み取りが必要です。
🚨 復旧シナリオ別ガイド
シナリオ 1：誤った DELETE * FROM users を実行した（5分前）
条件: 保持期間 7 日、バックアップウィンドウ毎日 02:00
-
PITR で復旧（保持期間内 ✓）
- AWS マネジメントコンソール → RDS → 「スナップショットから復元」ではなく「時刻を指定した復元」
- 復旧時刻: 誤実行の 1 分前を指定
- 新しい DB インスタンスが起動（エンドポイント変更）
- アプリの接続先を新インスタンスに変更 or Route 53 切り替え
-
復旧後、旧インスタンスのデータは残る？
- 旧インスタンスはそのまま（削除してよい or 念のため保持）
-
ダウンタイム
- DB 復旧: 5～15 分
- アプリ接続先切り替え: 1～2 分
シナリオ 2：3 ヶ月前のスナップショットから復旧したい
条件: 保持期間 7 日、手動スナップショット有
- PITR では保持期間外 ✗
- 手動スナップショットから復旧 ✓
- 3 ヶ月前に取得した手動スナップショットを選択
- 「スナップショットから復元」
- 新しい DB インスタンス起動
コスト:
- PITR (7 日保持): $0（自動バックアップに含まれる）
- 手動スナップショット (3 ヶ月保管): ストレージサイズに応じて月額課金
シナリオ 3：DB インスタンスが完全に破損した（ハードウェア障害）
条件: マルチ AZ 有効
- マルチ AZ フェイルオーバー → スタンバイへ自動切り替え（1～2 分、ダウンタイム最小）
- その後、PITR で追加復旧したければ、新しいインスタンスを別途起動
ポイント:
- マルチ AZ = 物理的障害への対応（自動フェイルオーバー）
- PITR = 論理破損・誤削除への対応（手動復旧）
- 両立必須
シナリオ 4：クロスリージョン DR のため東京から大阪へスナップショット複製
前提:
- 東京リージョン DB（保持期間 7 日）
- 大阪リージョンへの複製戦略
手順:
- 東京で手動スナップショット取得
- 「スナップショットをコピー」→ 大阪リージョン指定
- コピー完了後、大阪から復旧（テスト）
コスト & 暗号化考慮:
- クロスリージョン複製の転送料が発生
- 両リージョンで暗号化が有効な場合、KMS キーポリシーを確認
📊 復旧手段の比較表
| 手段 | 復旧対象 | 復旧時間 | 対象期間 | コスト |
|---|---|---|---|---|
| PITR | 誤削除、アプリバグ | 5～15 分 | 保持期間内 | 自動 B/U に含む |
| 手動スナップショット | 長期保管、DR | 5～15 分 | 無制限 | スナップショット容量分 |
| マルチ AZ 自動 FO | ハードウェア障害 | 1～2 分 | リアルタイム | 追加料金（マルチ AZ 構成） |
| リードレプリカ昇格 | 本インスタンス障害 | 5 分 | リアルタイム | レプリカ実行コスト |
試験出題パターン:
- 「急な削除から 30 分以内に復旧したい」→ 保持期間 7 日なら PITR で充分
- 「1 年前のデータに戻したい」→ 手動スナップショット必須
- 「RTO 1 分、フェイルオーバー自動化」→ マルチ AZ + リードレプリカ昇格
マルチ AZ・レプリカとの位置づけ
| 手段 | 主な目的 |
|---|---|
| マルチ AZ | AZ 障害からの自動フェイルオーバー（運用継続） |
| リードレプリカ | 読み取りスケール、昇格による DR |
| バックアップ／スナップショット | 誤操作・論理破損、規定保持を超える長期保管 |
「マルチ AZ があればバックアップは不要」は誤りになりやすいです（論理削除やアプリバグにはバックアップ／PITRが効く）。
公式ドキュメント（深掘り）
重要ポイント
- ▸自動バックアップ + トランザクションログ = PITR（保持期間内なら秒単位で復旧）
- ▸PITR 復旧 = 新しい DB インスタンス生成（元インスタンスの上書きではない）
- ▸DROP TABLE / 誤削除 → 保持期間内なら復旧可能、超過時は手動スナップショット必須
- ▸手動スナップショット = 長期保管、クロスリージョンコピー向け
- ▸マルチ AZ フェイルオーバーと PITR は別（両立必須）
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。