Amazon Auroraのバックアップと復旧

データベースの保護では、「どの時点のデータを残すか」と「障害や誤操作の後にどのような形で戻すか」を分けて考えます。Amazon Auroraには、継続的な自動バックアップ、手動スナップショット、ポイントインタイムリカバリ（PITR）、高速クローン、バックトラックがあります。それぞれ、保護する時間範囲、復元先、停止時間、用途が異なります。

自動バックアップで継続的に保護する

Auroraはクラスターボリュームのデータを継続的にAmazon S3へバックアップします。DBインスタンスのローカルディスクへ定期的に全量コピーを作る方式ではなく、変更データを含むバックアップを保持し、設定したバックアップ保持期間内の時点へ戻せるようにします。保持期間はクラスターごとに設定し、1日から35日の範囲で選べます。

保持期間内の任意の時点を指定して復旧できますが、現在進行中の変更が即座にすべて復元可能になるわけではありません。最新復元可能時刻（Latest restorable time） は通常、現在より数分前です。運用では、管理コンソールやAPIに表示される最新復元可能時刻を確認し、許容できるデータ損失範囲（RPO）と照らし合わせます。「PITRは5分以内の時刻を指定する機能」と覚えるのではなく、「保持期間内の任意時点へ復元でき、最新の復元可能時刻には数分程度の遅れがある」と理解します。

自動バックアップを使った復旧では、指定した時刻のデータを持つ新しいDBクラスターが作成されます。元のクラスターを上書きするわけではありません。復旧後は新クラスターの状態を確認し、必要な接続先変更やデータ検証を行ってからアプリケーションを切り替えます。自動バックアップの保持期間を超える長期保管には、手動スナップショットやAWS Backupなど別の仕組みを検討します。

Amazon RDSの一般的なDBインスタンスでも、自動バックアップとトランザクションログを使ったPITRを利用できます。「RDSは日次バックアップだけ、AuroraだけがPITR対応」とは言えません。Auroraではストレージ層の継続的なバックアップが特長ですが、どちらもエンジンや配置モード、保持設定などを確認して復旧要件を満たす必要があります。

手動スナップショットを保存する

手動DBクラスター・スナップショットは、必要な時点で明示的に作成する復元用の保存点です。定期的な自動バックアップの範囲を超えて残したい節目や、変更作業の前に戻り先を確保したい場合に使います。スナップショットは、バックアップ保持期間の終了や元クラスターの削除によって自動では消えず、利用者が削除するまで保持されます。

Auroraの手動スナップショットは増分方式で保存されます。最初のスナップショットが基準となり、同じクラスターから追加で作るスナップショットは前回以降の変更分を含みます。コンソール上では各スナップショットからクラスター全体を復元できるように見えますが、保存容量と料金は実際に保持するバックアップデータに基づきます。保持が不要になったスナップショットを整理し、長期間保管する場合はリージョン間コピーやAWS Backupのポリシーも含めて管理します。

スナップショットからの復元でも、新しいDBクラスターが作成されます。既存クラスターのエンドポイントが自動的に置き換わるわけではないため、復元後のデータを確認し、接続先を切り替える手順を用意します。手動スナップショットは、選択した時点の状態を保存する方法であり、スナップショット作成時点の間に行われた更新を任意の時刻まで細かく巻き戻す機能ではありません。

ポイントインタイムリカバリで新しいクラスターを作る

**ポイントインタイムリカバリ（PITR）**は、自動バックアップの保持期間内から復旧したい日時を指定し、その時点のデータを新しいDBクラスターとして復元する方法です。たとえば、運用担当者が一括更新を誤って実行した場合、実行直前の時刻を指定して別クラスターを作成し、正常なデータを取り出したり、アプリケーションの接続先を切り替えたりできます。

PITRは過去の状態を別のクラスターに再現する操作です。現行クラスターをその場で後戻りさせる機能ではなく、元クラスターは残ります。復元後のクラスターには別のエンドポイントが割り当てられるので、アプリケーション切り替えの段取り、検証、不要になったクラスターの削除までを復旧手順に含めます。

自動バックアップが無効または保持期間外の時点は、PITRの対象にできません。さらに、復旧できる時刻の上限には最新復元可能時刻があるため、障害を認識した直後に必ず直前の状態へ戻せるとは限りません。復旧演習では、指定時刻だけでなく復元の所要時間、接続切り替え、データ整合性の確認も計測します。

高速クローンで独立した環境を用意する

Auroraの高速データベースクローンは、既存のクラスターから別のDBクラスターを短時間で作る機能です。コピーオンライト（copy-on-write）方式を使い、クローン作成時にクラスターボリューム全体をすべて複製するのではなく、元クラスターのデータを共有した状態から開始します。クローン側でデータが変更されると、その変更に必要な領域が別に確保され、元クラスターのデータには影響しません。

このため、クローンは単に「ストレージ以外のインスタンス部分だけをコピーする」機能ではありません。データを含む別クラスターを用意しつつ、作成直後の不要な全量コピーを避ける方式です。性能試験やスキーマ変更の検証など、実データに近い状態を使いたい作業環境を迅速に用意する用途があります。

クローンは論理的に独立したデータベースですが、元クラスターのバックアップ保管や災害復旧の代わりにはなりません。元のクラスターや共有元データに依存して始まり、作成後に双方のデータが分岐します。クローンで追加・変更されたデータ量に応じてストレージ使用量や料金が増える点も考慮し、検証後のクラスターを放置しないようライフサイクルを管理します。利用可能なエンジン、リージョン、クラスター条件はAWSの現行ガイドで確認してください。

バックトラックで対応クラスターを巻き戻す

バックトラックは、対応するAurora MySQL DBクラスターを、過去の時点の状態へ戻す機能です。PITRのように復元先の新しいクラスターを作るのではなく、既存クラスターを指定した過去の状態へ巻き戻します。誤ったデータ更新や削除など、最近の論理的な誤操作から素早く戻りたい場合に候補になります。

バックトラックを使うには、事前に機能を有効化し、巻き戻し可能な時間幅（バックトラックウィンドウ）を設定しておきます。設定できる範囲は最大72時間です。問題が発生してから有効化して過去へ戻ることはできません。また、すべてのAuroraエンジンや構成で利用できるわけではなく、対応するAurora MySQLのバージョンやクラスター構成などの条件を満たす必要があります。新しいエンジン世代や特殊な構成では利用可否を公式ガイドで確認します。

バックトラック中はデータベース処理が一時的に利用できなくなるため、アプリケーションの要求を停止または退避し、接続を再確立する時間を見込みます。復旧後は巻き戻し先以降の変更が失われていないか確認します。バックトラックウィンドウを長くするほど変更履歴の保持が必要になり、追加のストレージ使用量や料金にも影響します。

バックトラックは、長期保管やクラスター消失に備えるバックアップではありません。誤操作からの素早い復旧に向く一方、災害やクラスター全体の喪失に備えるには、自動バックアップや手動スナップショットなど独立した復旧手段を維持します。

復旧方法を要件から選ぶ

要件・操作	選択肢	復旧後の形	主な注意点
バックアップ保持期間内の任意の時点へ戻したい	PITR	新しいクラスター	最新復元可能時刻を確認し、接続先を切り替える
保存しておいた特定時点の状態を使いたい	手動スナップショット	新しいクラスター	明示的な削除まで保管され、保管コストが続く
開発・検証用のデータ環境をすばやく用意したい	高速クローン	独立した新しいクラスター	コピーオンライトで始まり、変更に伴い追加ストレージを使う
対応クラスターを最近の誤操作前の状態に戻したい	バックトラック	既存クラスターを巻き戻す	事前設定が必要で、巻き戻し中は利用停止を見込む

災害復旧では、保存期間、別リージョンへの保管、復旧時間（RTO）、許容できるデータ損失（RPO）を確認します。データをある時刻の状態で戻す必要があるのか、同じクラスターを過去へ戻したいのか、テスト用の別環境を作りたいのかを見極めると、PITR、スナップショット、バックトラック、クローンの選択を誤りにくくなります。

試験での見分け方

• 保持期間内の時刻を指定し、その時点のデータを新しいクラスターとして取り出すなら、PITRです。復元時刻は最新復元可能時刻より過去でなければなりません。
• クラスター削除後にも残す保存点や、明示した時点の復元基準が必要なら、手動スナップショットを考えます。スナップショットからの復元先は新しいクラスターです。
• 実データを使った試験環境をすばやく作りたいなら、高速クローンです。コピーオンライト方式であり、クローンを作ること自体がバックアップ保管を意味するわけではありません。
• Aurora MySQLを同じクラスターのまま過去へ戻し、誤操作から短時間で復旧したいなら、事前に有効化しておくバックトラックを検討します。バックトラックウィンドウは最大72時間で、対象構成に制約があります。
• 元の環境を残して復旧データを検証したい場合はPITRまたはスナップショットから別クラスターを作ります。既存クラスターを直接巻き戻すバックトラックと混同しないようにします。

公式ドキュメント

• Auroraの自動バックアップとスナップショット
• Aurora DBクラスターのポイントインタイムリカバリ
• Auroraの高速データベースクローン
• Aurora MySQLのバックトラック
• Amazon Auroraの料金