AWS RDSのバックアップとリストア手順：自動バックアップ・スナップショット・ポイントインタイム復元

Amazon RDS のバックアップは、毎日の自動バックアップ（ポイントインタイム復元が可能）と、手動で取る DB スナップショットの2本立てです。どちらから復元しても「既存のインスタンスが巻き戻る」のではなく「新しい DB インスタンスが作られる」点が、最初に押さえるべき要点です。この記事では、バックアップ設定の確認、作業前のスナップショット取得、ポイントインタイム復元とスナップショットからの復元、復元後に WordPress を新しいインスタンスへ切り替える手順までを、AWS CLI のコマンド例とともに説明します。

内容は RDS for MySQL / MariaDB を想定しています。Aurora はクラスタ単位でバックアップを管理するなど仕組みが異なるので、Aurora を使っている場合は該当するドキュメントを参照してください。

RDSのバックアップの種類

自動バックアップ

RDS は指定したバックアップウィンドウ（時間帯）に毎日スナップショットを取り、あわせてトランザクションログを保存します。この2つを組み合わせることで、保持期間内の任意の時刻に戻す「ポイントインタイム復元（PITR）」ができます。戻せる最新時刻は通常、現在から数分前までです。

保持期間は日数で設定し、最大 35 日です。0 にすると自動バックアップが無効になり、PITR もできなくなります。

重要な注意点として、自動バックアップは DB インスタンスを削除すると原則として一緒に消えます。削除時に「自動バックアップを保持する」選択肢がありますが、それも保持期間が過ぎれば消えます。

手動スナップショット（DB スナップショット）

任意のタイミングで取るスナップショットです。自分で削除するまで残り、インスタンスを削除しても消えません。バージョンアップやスキーマ変更の前に取っておく、長期保管用に月1回取る、といった使い方をします。

AWS Backup

複数のサービスのバックアップをまとめて管理したい場合は、AWS Backup でバックアッププランを作り、RDS も対象に含める方法があります。別アカウントや別リージョンへのコピー、削除を防ぐロック機能など、組織的な管理に向いた機能があります。機能の詳細は変わることがあるため、導入時に AWS Backup のドキュメントを確認してください（2026年10月現在）。

Multi-AZ はバックアップではない

Multi-AZ 構成は、障害時に待機系へ切り替えるための仕組みです。誤って DELETE を実行した、プラグインがデータを壊した、という場合は待機系にも同じ変更が反映されるため、復旧の手段にはなりません。

手順1：現在のバックアップ設定を確認する

まず保持期間とバックアップウィンドウ、戻せる最新時刻を確認します。

aws rds describe-db-instances \
  --db-instance-identifier wp-db \
  --query 'DBInstances[0].[BackupRetentionPeriod,PreferredBackupWindow,LatestRestorableTime]'

保持期間が短すぎる場合や、アクセスが多い時間帯にウィンドウが重なっている場合は変更します。ウィンドウは UTC で指定する点に注意してください。日本時間の深夜 3 時台にしたいなら、UTC では 18 時台になります。

aws rds modify-db-instance \
  --db-instance-identifier wp-db \
  --backup-retention-period 14 \
  --preferred-backup-window 18:00-18:30 \
  --apply-immediately

保持期間を 0 から 1 以上へ、またはその逆へ変更すると、インスタンスの停止を伴う場合があります。本番では影響を確認してから、メンテナンス時間帯に実施してください。

手順2：作業前に手動スナップショットを取る

大きな変更の前には手動スナップショットを取ります。名前に日付と目的を入れておくと、後で迷いません。

aws rds create-db-snapshot \
  --db-instance-identifier wp-db \
  --db-snapshot-identifier wp-db-before-upgrade-20261028

aws rds wait db-snapshot-available \
  --db-snapshot-identifier wp-db-before-upgrade-20261028

wait コマンドは、スナップショットが使える状態になるまで待ちます。完了を確認してから本番作業に入ると安心です。

手順3：ポイントインタイム復元を行う

「今日の 12 時（日本時間）にプラグインを更新したらデータが壊れた。その直前に戻したい」という場面では PITR を使います。時刻は UTC で指定します。

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier wp-db \
  --target-db-instance-identifier wp-db-restore-1155 \
  --restore-time 2026-10-28T02:55:00Z \
  --db-subnet-group-name wp-db-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name wp-mysql-params

aws rds wait db-instance-available \
  --db-instance-identifier wp-db-restore-1155

最新の状態に近いところまで戻したい場合は、--restore-time の代わりに --use-latest-restorable-time を指定します。

ここでつまずきやすいのは、元のインスタンスの設定がすべて引き継がれるわけではないことです。サブネットグループ、セキュリティグループ、パラメータグループなどは、指定しないと既定値で作られることがあります。既定のセキュリティグループのままだと、WordPress のサーバーから接続できません。上の例のように明示的に指定し、復元後に describe-db-instances で設定を見比べてください。

手順4：スナップショットから復元する

手動スナップショットや自動バックアップのスナップショットから復元する場合のコマンドです。

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier wp-db-restore-snap \
  --db-snapshot-identifier wp-db-before-upgrade-20261028 \
  --db-subnet-group-name wp-db-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name wp-mysql-params

スナップショットから作ったインスタンスは、データがストレージに読み込まれるまで最初のアクセスが遅くなることがあります。復元直後に性能が出ないのはこのためで、時間とともに解消します。切り替えの前に、主要なページを一通り開いてデータを温めておく方法もあります。

手順5：復元したデータを確認する

切り替える前に、復元したインスタンスに接続して中身を確認します。

mysql -h wp-db-restore-1155.xxxxxxxx.ap-northeast-1.rds.amazonaws.com -u admin -p \
  -e "SELECT ID, post_title, post_modified FROM wordpress.wp_posts ORDER BY post_modified DESC LIMIT 5;"

最新の投稿の更新日時が、戻したい時刻の直前になっているかを見ます。テーブル接頭辞やデータベース名は環境に合わせて読み替えてください。

手順6：WordPressを新しいインスタンスへ切り替える

切り替え方は2通りあります。

方法A：wp-config.php の接続先を変える。 DB_HOST を新しいエンドポイントに書き換えます。手順は単純ですが、複数のサーバーやコンテナで動かしている場合は、すべての設定を変更する必要があります。

define( 'DB_HOST', 'wp-db-restore-1155.xxxxxxxx.ap-northeast-1.rds.amazonaws.com' );

方法B：インスタンス名を入れ替える。 RDS のエンドポイントはインスタンス識別子から作られるため、元のインスタンスを別名に変更し、復元したインスタンスを元の名前に変更すれば、アプリ側の設定を変えずに済みます。名前の変更中は接続できない時間が生じるため、メンテナンスモードにしてから行います。

aws rds modify-db-instance --db-instance-identifier wp-db \
  --new-db-instance-identifier wp-db-old --apply-immediately
# 変更の完了を確認してから
aws rds modify-db-instance --db-instance-identifier wp-db-restore-1155 \
  --new-db-instance-identifier wp-db --apply-immediately

いずれの方法でも、切り替え後にログイン、投稿の表示、フォーム送信などの動作を確認します。元のインスタンスはすぐに削除せず、問題がないと判断できるまで残しておきます。削除する際は最終スナップショットを取っておくと安全です。

論理バックアップも併用する

RDS のスナップショットはインスタンス単位の復元しかできません。「特定のテーブルだけ戻したい」「別の環境に移したい」場合は、mysqldump や WP-CLI の wp db export による論理バックアップが役立ちます。InnoDB なら --single-transaction を付けると、書き込みを止めずに整合性のあるダンプを取れます。スナップショットと論理バックアップの両方を持っておくと、復旧の選択肢が増えます。

復元テストを定期的に行う

バックアップは、実際に復元できて初めて意味を持ちます。ステージング環境で定期的にスナップショットから復元し、WordPress が起動するか、復元に何分かかるかを記録しておくと、障害時に落ち着いて対応できます。復元テストで作ったインスタンスは、終わったら削除するのを忘れないようにしてください。

まとめ

• 自動バックアップは PITR が可能で最大 35 日保持、インスタンス削除で原則消える。手動スナップショットは削除するまで残る
• 復元は常に新しいインスタンスとして作られる。セキュリティグループやパラメータグループを明示的に指定する
• 時刻やバックアップウィンドウは UTC で指定する
• 切り替えは DB_HOST の変更か、インスタンス名の入れ替えで行い、元のインスタンスはしばらく残す
• Multi-AZ はバックアップの代わりにならない。論理バックアップと定期的な復元テストを併用する

• AWS RDSのリードレプリカ設定
• MySQLバックアップの自動化