【AWS】RDS（MySQL）のバックアップとリストア戦略｜スナップショット・自動バックアップの実務設計

2026-07-12

はじめに

RDS for MySQL を本番で動かしていると、「バックアップは取っているつもり」でも、いざ障害や誤削除が起きたときに次の判断で止まりがちです。

自動バックアップと手動スナップショット、どちらを使うべきか
いつ時点まで戻せるのか（ポイントインタイムリカバリの範囲）
リストアすると既存の DB インスタンスはどうなるのか
アプリの接続先を新しいインスタンスへ切り替えるまでの手順は何か

この記事では、RDS for MySQL を前提に、自動バックアップと手動スナップショットの役割分担を整理します。あわせて、ポイントインタイムリカバリ（PITR）、スナップショットからのリストア、接続先切替までの実務ポイントも扱います。Aurora や AWS Backup の詳細な運用設計は扱いません。

PITR とは、日次のスナップショットを土台にし、その後のトランザクションログで保持期間内の時刻指定復旧ができる仕組みです。

前提: RDS コンソールまたは AWS CLI で DB インスタンス（以降、インスタンス）を操作できること。検証は、単一の Availability Zone（可用性ゾーン）配置（シングル AZ）と、複数 AZ 配置（Multi-AZ）の一般的な RDS for MySQL インスタンスを想定しています。本記事の Multi-AZ は主に DB インスタンス構成を指し、Multi-AZ DB クラスター固有の話は必要箇所のみ触れます。保持日数や料金の単価はリージョン・時期で変わるため、最終確認は Amazon RDS pricing と公式ドキュメントを参照してください。

背景：2種類のバックアップをどう使い分けるか

RDS のバックアップは大きく次の 2 系統です（Introduction to backups）。

種類	概要	主な用途
自動バックアップ	バックアップウィンドウで日次スナップショット＋トランザクションログ	保持期間内の任意時点への復旧（PITR）
手動スナップショット	ユーザーが任意のタイミングで取得	リリース前の固定点、長期保管、別環境への複製

いずれも DB インスタンス全体（ストレージボリューム）のバックアップであり、特定データベースだけを選んで取る仕組みではありません。

自動バックアップを「日次スナップショットだけ」と捉えると、復旧粒度が 1 日単位に見えます。実際は、日次の土台（スナップショット）に、その後の変更履歴（トランザクションログ）が乗るため、保持期間内の任意時刻へ寄せられます。

自動バックアップと保持期間

自動バックアップは、指定したバックアップウィンドウ中に取得されます。保持期間は DB インスタンスで 0〜35 日です。0 にすると自動バックアップは無効になります。コンソール作成時のデフォルトは 7 日、CLI / API で保持期間を指定しない場合のデフォルトは 1 日です（Backup retention period）。

重要な制約:

インスタンスが available 以外（例: storage_full）のあいだは自動バックアップが走らない
保持期間を 0 と非ゼロのあいだで変更すると サービス停止を伴う変更（アウトージ） になる
Multi-AZ DB クラスターでは保持期間の下限は 1 日（0 不可）。通常の Multi-AZ DB インスタンスとは構成が異なる

PITR では、保持期間内の任意の時点へ新しいインスタンスを作れます。RDS はトランザクションログを定期的に Amazon S3 へ送り、最新の復元可能時刻（LatestRestorableTime）を更新します。ドキュメント上、アップロード間隔の目安は約 5 分です（Restoring to a specified time）。

手動スナップショット

手動スナップショットは保持期間の対象外で、明示的に削除するまで残ります。リージョンあたり最大 100 個まで、という上限があります（Introduction to backups）。

シングル AZ では、スナップショット作成時に短い I/O 停止が起き得ます。MySQL / MariaDB / Oracle / PostgreSQL の Multi-AZ では、バックアップはスタンバイ側から取られます。そのためプライマリの I/O は停止しない、とドキュメントにあります（Creating a DB snapshot）。

長期間の保管では、手動スナップショットのコピーも選択肢です。エンジンのメジャーバージョンサポート終了後の復元可否を避ける用途では、スナップショットデータの S3 エクスポートもあります。本記事の主対象はスナップショット／自動バックアップ本体の設計です。

実務での役割分担（例）

シナリオ	推奨の考え方
誤 DELETE / 壊れたデプロイ	自動バックアップ＋PITR（保持期間内）
スキーマ変更・メジャーリリース直前	手動スナップショットを明示的に取得
コンプライアンスで 35 日超の保管	手動スナップショットのコピー／S3 エクスポート等を検討
インスタンス削除後も戻したい	削除前に最終スナップショット、または自動バックアップの保持を指定

実装と検証

以下は AWS CLI 中心の例です。コンソールでも同名のメニューから実行できます。識別子は自分の環境に置き換えてください。エンジンは RDS for MySQL を想定しています。

1. 自動バックアップの保持期間とウィンドウを確認・変更する

現状を確認します。

aws rds describe-db-instances \
  --db-instance-identifier my-mysql-prod \
  --query 'DBInstances[0].{Retention:BackupRetentionPeriod,Window:PreferredBackupWindow,LatestRestorableTime:LatestRestorableTime}'

コンソールでは対象インスタンスの Maintenance & backups（または同等のバックアップ設定）から保持期間とウィンドウを確認できます。

保持期間を 7 日に変更する例です。メンテナンスウィンドウや即時適用の扱いには注意してください。

aws rds modify-db-instance \
  --db-instance-identifier my-mysql-prod \
  --backup-retention-period 7 \
  --preferred-backup-window "18:00-19:00" \
  --apply-immediately

PreferredBackupWindow は UTC です。日本時間（JST）なら UTC+9 なので、たとえば JST 3:00〜4:00 は UTC 18:00〜19:00 です。アプリのピークと重ならない時間帯を選びます。時間を半分にしても「バックアップが半分の時間で終わる」わけではなく、負荷の低い時間に寄せるのが目的です。

実装時の注意点:

本番で保持期間を 0 にしてしまうと PITR ができなくなる
0 ↔ 非ゼロの切り替えはサービス停止を伴うため、計画停止として扱う
停止中（stopped）の時間は保持期間の計算に含まれない、とドキュメントにある

2. 手動スナップショットを取る

リリース前や危険なマイグレーション前に固定点を作ります。コンソールでは Snapshots → Take snapshot です。

aws rds create-db-snapshot \
  --db-instance-identifier my-mysql-prod \
  --db-snapshot-identifier my-mysql-prod-before-release-20260712

状態が available になるまで待ちます。

aws rds describe-db-snapshots \
  --db-snapshot-identifier my-mysql-prod-before-release-20260712 \
  --query 'DBSnapshots[0].Status'

名前に日時や用途を入れると、後から「何のための固定点か」が追いやすくなります。手動スナップショットは残し続けるとバックアップストレージ料金が増えるため、不要になったら削除する運用ルールもセットで決めてください。

3. ポイントインタイムリカバリ（PITR）

自動バックアップが有効なとき、保持期間内の任意時点へ 新しい DB インスタンスを作成できます。ソースインスタンスはそのまま残ります。

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier my-mysql-prod \
  --target-db-instance-identifier my-mysql-prod-pitr \
  --restore-time 2026-07-12T04:30:00.000Z

最新の復元可能時刻へ戻す場合は、次のとおりです。

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier my-mysql-prod \
  --target-db-instance-identifier my-mysql-prod-pitr-latest \
  --use-latest-restorable-time

コンソールでは Automated backups から対象を選び、Actions → Restore to point in time でも実行できます。

4. スナップショットからリストアする

手動／自動のスナップショットから、指定時点（スナップショット取得時）の状態で新しいインスタンスを作ります。既存インスタンスへの上書きはできません（Restoring from a DB snapshot）。コンソールでは Snapshots → 対象選択 → Actions → Restore snapshot です。

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-mysql-prod-restored \
  --db-snapshot-identifier my-mysql-prod-before-release-20260712

リストア後に必ず確認すること:

項目	なぜ重要か
パラメータグループ	指定しないとデフォルトが付く。カスタム設定が消えたように見える
VPC / サブネット / セキュリティグループ	指定しないとデフォルト側に寄ることがある
インスタンスクラス・ストレージ	ソースと同程度を推奨。リストア時に容量を変える場合、縮小は不可で、増加は原則 10% 以上
エンドポイント	新インスタンスになるため、アプリの接続先切り替えが必要

復元直後は available でも、全データがすぐ手元にあるわけではありません。未ロードのページへアクセスしたタイミングで Amazon S3 から読み込むため、初回アクセスは遅くなることがあります（lazy loading）。重要なテーブルは SELECT * などでフルスキャン相当の読み込みを行い、ウォームアップする手法がドキュメントで紹介されています。

5. 本番の接続先を切り替えるまでの流れ

リストアは「新しいインスタンスができた」ところで終わりません。接続先切替までの骨子は次のとおりです。

PITR またはスナップショットで新インスタンスを作成する
パラメータグループ・セキュリティグループ・サブネットを本番相当に合わせる
事前にメモした特定行の有無や更新時刻で、データ状態を検証する
アプリ設定または DNS の接続先を新エンドポイントへ切り替える
旧インスタンスは即削除せず、確認が終わるまで残す（問題があれば切り戻す）

実務設計で決めておくこと

コマンドを叩く前と後に決めておく方針です。

目標復旧時点（RPO）と目標復旧時間（RTO）

目標復旧時点（RPO）: どれだけデータを失ってよいか。自動バックアップ＋約 5 分間隔のログ転送を前提にすると、「直近数分」までの損失を許容する設計になりやすい。それより厳しい要件なら、アプリ側の二重書き込みや別レプリケーションを検討する
目標復旧時間（RTO）: どれだけで戻したいか。リストアは新インスタンス起動＋lazy loading＋DNS / 接続先切替を含む。スナップショット取得時刻への復帰と PITR では所要時間が変わり得る

数値の保証はワークロード次第なので、検証環境で一度リストア演習をしておくのが確実です。

バックアップウィンドウとメンテナンスの分離

バックアップウィンドウとメンテナンスウィンドウをピーク時間から外します。バッチやレポートが集中する時間帯と重なると、バックアップやパッチの影響が見えにくくなります。

インスタンス削除時の扱い

DB インスタンスを削除すると、既定では自動バックアップも削除されます。削除時に自動バックアップの保持を選ぶか、最終スナップショットを取るかを運用手順に書いておきます。手動スナップショットはインスタンス削除の影響を受けません。

Multi-AZ との関係

Multi-AZ は可用性（フェイルオーバー）のための仕組みです。バックアップ／PITR の代替ではありません。MySQL の Multi-AZ ではバックアップ時のプライマリ I/O 停止を避けやすい、という運用上の利点があります。バックアップ戦略と高可用性はセットで設計してください。

よくある失敗例：リストア後にアプリが繋がらない／時刻がずれる

本番はカスタムパラメータグループ（例: time_zone=Asia/Tokyo）とアプリ用セキュリティグループを使っていました。スナップショットリストア時にどちらも指定しなかった結果、次の症状が出ました。

アプリから新インスタンスへ接続できない（セキュリティグループがデフォルト側）
接続できてもタイムスタンプの解釈がずれる（パラメータがデフォルト）

# 失敗しやすい例: パラメータグループ・SG 未指定
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-mysql-prod-restored \
  --db-snapshot-identifier my-mysql-prod-before-release-20260712

対処:

リストア時に --db-parameter-group-name と --vpc-security-group-ids を明示する
スナップショット取得時に使っていたパラメータグループを削除せず残す（ドキュメントでも推奨）
復旧手順書に、パラメータ・SG・エンドポイント切替・データ検証のチェックリストを書く

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-mysql-prod-restored \
  --db-snapshot-identifier my-mysql-prod-before-release-20260712 \
  --db-parameter-group-name my-mysql-prod-params \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-subnet-group-name my-db-subnet-group

（サブネットグループや SG の指定可否は CLI オプションとリージョン設定に合わせて調整してください。）

まとめ

自動バックアップは保持期間内の PITR 向け。手動スナップショットは固定点・長期保管向け
リストアは常に 新しいインスタンス を作る。パラメータグループとネットワーク設定の明示が復旧品質を左右する
保持期間 0 への変更や削除時のバックアップ破棄は、復旧不能に直結しやすい

次に試すこと

検証用 RDS for MySQL で describe-db-instances から BackupRetentionPeriod と LatestRestorableTime を確認する
手動スナップショットを 1 つ取り、別名インスタンスへリストアする。接続確認に加え、事前にメモした行の有無を照合する
PITR で「数十分前」へ戻し、意図した更新時刻のデータ状態になるかを検証する
復旧手順書に、パラメータグループ・SG・エンドポイント切替・データ検証・旧インスタンス縮退のチェックリストを追記する
本番の保持期間（例: 7 日）とバックアップウィンドウがピークと重なっていないかを見直す

Source

AWSAWS,MySQL

Posted by 千原耕司