RDSのバックアップ・スナップショット・リストア

自動バックアップと手動スナップショット、ポイントインタイムリカバリ、保持期間、削除時の挙動を整理します。

学習順Step 54 / 61サービスDB試験ドメイン弾力性

自動バックアップ

自動バックアップを有効にすると、指定したバックアップ保持期間の範囲で、データのスナップショットトランザクションログが取得されます。これにより 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 インスタンスを削除するとき、コンソールでは次のような選択が出ます。

  • 最終スナップショットを作成するか … 誤削除や将来の復旧余地のため推奨される文脈が多い。
  • 自動バックアップ … インスタンス削除とともに消えるイメージ(手動スナップショットは残る)。

コスト削減で即削除する問題では、「スナップショットなしで消す」がリスクになる、という読み取りが必要です。

マルチ AZ・レプリカとの位置づけ

手段 主な目的
マルチ AZ AZ 障害からの自動フェイルオーバー(運用継続)
リードレプリカ 読み取りスケール昇格による DR
バックアップ/スナップショット 誤操作・論理破損規定保持を超える長期保管

「マルチ AZ があればバックアップは不要」は誤りになりやすいです(論理削除やアプリバグにはバックアップ/PITRが効く)。

公式ドキュメント(深掘り)

重要ポイント

  • 自動バックアップ+トランザクションログで保持期間内のPITRが可能
  • 手動スナップショットは明示取得。長期保管・クロスリージョンコピーに使う
  • スナップショットからは新しいDBインスタンスを復元(同一インスタンスの上書きではない)
  • 暗号化キーとKMS権限はリストア・コピー時の前提条件になりやすい
  • 削除時の最終スナップショット有無は運用事故とコストのトレードオフ

このトピックの学習を完了しますか?

完了状態はいつでも切り替えられます