Database > RDS for MySQL > バックアップおよび復元

バックアップ概要

障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備することができます。必要な時にコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。バックアップが実行されている間は当該DBインスタンスのストレージのパフォーマンス低下が発生する可能性があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによるパフォーマンス低下を望まない場合は、高可用性構成を使用したり、以前のバックアップ以降のデータの増分のみをバックアップすることができ、リードレプリカでバックアップを実行することもできます。

[参考] 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのストレージパフォーマンス低下が発生しません。 ただし、以下の場合、高可用性DBインスタンスであっても、マスターでバックアップが実行されることがあります。 * 予備マスターの障害により、バックアップ実行が不可能な状態である場合。 * 予備マスターの再構築のため、予備マスターではない他のDBインスタンスで行ったバックアップが必要な状況で、リードレプリカがない場合

RDS for MySQLでは、Percona XtraBackupを利用してデータベースをバックアップします。外部MySQLのバックアップで復元したり、RDS for MySQLのバックアップで復元するにはRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。 DBエンジンバージョン別のPercona XtraBackupバージョンは次のとおりです。

MySQLバージョン	XtraBackupバージョン
5.7.15	2.4.28
5.7.19	2.4.28
5.7.26	2.4.28
5.7.33	2.4.28
5.7.37	2.4.28
8.0.18	8.0.32
8.0.23	8.0.32
8.0.28	8.0.32
8.0.32	8.0.32
8.0.33	8.0.33
8.0.34	8.0.34
8.0.35	8.0.35
8.0.36	8.0.35

• XtraBackupのインストールに関する詳しい説明はPercona Webサイトを参照します。
• https://www.percona.com/doc/percona-xtrabackup/2.4/index.html
• https://www.percona.com/doc/percona-xtrabackup/8.0/index.html

[参考] 2023年8月17日XtraBackupユーティリティのバージョンがアップグレードされました。以前バックアップに使用されたXtraBackupバージョンはWebコンソールで確認できます。

バックアップの種類

バックアップは手動バックアップと自動バックアップに分けられます。

手動バックアップ

コンソールで手動バックアップを実行して、特定の時点のデータベースを永久に保存できます。手動バックアップは、自動バックアップとは異なり、明示的にバックアップを削除しない限り、DBインスタンスが削除されるときに一緒に削除されません。 手動バックアップ作成時には、バックアップ名を指定する必要があり、次のような制約があります。 * バックアップ名は、リージョンごとに一意でなければなりません。 * バックアップ名は1～100文字の英字、数字、一部の記号(-, _, .)のみ入力することができ、最初の文字は英字のみ使用できます。

手動で全体バックアップを作成する

❶ DBインスタンスリストからバックアップするDBインスタンスを選択した後、バックアップをクリックして手動で全体バックアップを作成できます。 ❷バックアップリストで全体バックアップ作成をクリックし、バックアップするDBインスタンスを指定して手動で全体バックアップを作成できます。

手動全体バックアップを作成する

❸バックアップリストから基準バックアップを選択した後、増分バックアップ作成をクリックして増分バックアップを作成できます。一部バックアップは基準バックアップとして選択できません。基準バックアップの詳細については基準バックアップを参照してください。

自動バックアップ

手動でバックアップを実行する場合以外にも、復元作業のために必要な場合、または自動バックアップスケジュールの設定により、自動バックアップが実行されることがあります。 自動バックアップ時に適用される設定項目は、自動バックアップ設定を参照してください。

バックアップ方式

全体バックアップ方式と増分バックアップ方式が提供されます。

全体バックアップ

DBインスタンスの全てのデータをバックアップします。

増分バックアップ

基準バックアップが実行された後のデータ変更分だけを増分方式でバックアップします。変更があまり発生しないデータが大部分である場合におすすめです。 増分バックアップは常に基準バックアップを実行したDBインスタンスで実行されます。 増分バックアップで復元する場合、最初に作成された全体バックアップの復元を行い、選択した増分バックアップに到達するまでの全ての増分が順次反映されます。

[注意] 増分バックアップで復元する場合は、全体バックアップで復元する時より多くの時間がかかる場合があり、これは復元に必要な増分バックアップの容量の合計に比例します。

基準バックアップ

増分バックアップには、データ変更の基準となるバックアップが必要です。増分バックアップも新しい増分バックアップの基準バックアップになることができます。

増分バックアップの基準となるバックアップには、次の制約が存在します。手動及び自動で増分バックアップ時に共通で適用されます。 * エラー状態のバックアップは基準バックアップにすることはできません。 * 最後のフェイルオーバー前に作成されたバックアップは、基準バックアップにすることができません。 * 最後のDBエンジンのバージョンアップグレード前に作成されたバックアップは、基準バックアップにすることはできません。 * すでにそのバックアップを基準にした増分バックアップが存在する場合、基準バックアップにすることはできません。ただし、以前の増分が失敗した場合は、同じバックアップを基準に増分が可能です。 * 該当バックアップを実行したDBインスタンスが削除されたり、障害によりバックアップを実行できない状態であれば、基準バックアップにすることはできません。 * 2024年9月の定期配布前に作成されたバックアップは、基準バックアップにすることができません。

自動バックアップスケジュール戦略に基づいて増分バックアップがスケジュールされる場合、上記の制約事項と一緒に次の追加制約事項を満たす基準バックアップが自動的に選択されます。制約事項を満たす基準バックアップがない場合、自動バックアップスケジュール戦略に関係なく、全体バックアップを実行します。 * 複製中断状態の予備マスター、リードレプリカで実行されたバックアップは、基準バックアップにすることはできません。 * テーブルロックを使用しない状態で行われたバックアップは、基準バックアップにすることはできません。 * 当該バックアップの作成後に新しい全体バックアップが作成された場合、基準バックアップにすることはできません。

バックアップ設定

DBインスタンスの作成及び修正時、バックアップに適用される設定項目を指定できます。

共通設定

次の項目は、自動バックアップ及び手動バックアップ時に共通で適用されます。

テーブルロックの使用

• FLUSH TABLES WITH READ LOCK構文を実行するかどうかを設定します。
• テーブルロックを使用すると、バックアップデータの一貫性を保証するために、バックアップ時に定期的にFLUSH TABLES WITH READ LOCK構文を実行します。FLUSH TABLES WITH READ LOCK`構文の実行に失敗した場合、バックアップに失敗します。
• バックアップが実行されている間、DMLクエリの負荷が多い場合、テーブルロックを無効にできます。テーブルロックを使用しない場合、FLUSH TABLES WITH READ LOCK構文を実行しないため、DML負荷が多くてもバックアップが失敗しません。しかし、テーブルロックを使用しないバックアップは、バックアップデータの一貫性が保証されない可能性があり、これにより、テーブルロックを使用せずに作成されたバックアップ及びテーブルロックを使用しないように設定されたDBインスタンスに対して、復元及び複製プロセスを含む一部の作業をサポートしません。

クエリ遅延待機時間(秒)

• テーブルロックを使用する場合、FLUSH TABLES WITH READ LOCK構文の待ち時間を設定します。クエリ遅延待機時間だけFLUSH TABLES WITH READ LOCK構文が待機します。0～21,600秒まで設定可能です。長く設定するほど、DMLクエリの負荷によるバックアップ失敗の可能性を減らすことができますが、全体のバックアップ時間が長くなる可能性があります。

自動バックアップ設定

次の項目は、自動バックアップ時のみ適用されます。

自動バックアップを許可

• 自動バックアップを許可しない場合、すべての自動バックアップの実行がブロックされ、必要に応じてバックアップが実行される可能性がある復元、複製過程を含む一部の作業をサポートしません。 また、以下の自動バックアップ関連項目については設定ができません。

自動バックアップの保管期間

• 自動バックアップをバックアップストレージに保存する期間を設定します。最大730日まで保管することができ、自動バックアップの保管期間が変更されると、保管期間が過ぎた自動バックアップファイルはすぐに削除されます。

[注意] 増分方式で作成されたバックアップは、自動バックアップの保管期間が経過していなくても、基準バックアップが削除されると一緒に削除されます。

自動バックアップ複製リージョン

• 自動バックアップファイルを他のリージョンのバックアップストレージに複製するように設定します。自動バックアップ複製リージョンは、災害復旧(disaster recovery)のための機能で、ソースリージョンの自動バックアップファイルをターゲットリージョンに同じように複製して管理します。複製はバックグラウンドで一定周期ごとに行われます。自動バックアップ複製リージョンを設定すると、リージョン間の複製トラフィック費用が請求され、対象リージョンにバックアップストレージ使用量に対する費用が追加で請求されます。

自動バックアップの再試行回数

• DMLクエリの負荷または様々な理由で自動バックアップが失敗した場合、再試行するように設定できます。最大10回まで再試行できます。再試行回数が残っていても、自動バックアップの実行時間設定によって再試行しない場合があります。

**自動バックアップスケジュールの使用

• 自動バックアップスケジュールを使用すると、設定した自動バックアップ実行時間に自動的にバックアップが実行されます。

自動バックアップスケジュール戦略

• 自動バックアップを実行する戦略を指定できます。
• 毎日全体バックアップ：毎日、全データをバックアップします。
• 毎日全体及び増分バックアップ：毎日全データを1回バックアップし、数回増分バックアップを行います。
• 毎週の全体バックアップと毎日の増分バックアップ：特定の曜日に全体データを1回バックアップし、残りの曜日には増分バックアップを1回行います。

全体データバックアップ曜日

• 毎週の全体バックアップと毎日の増分バックアップ戦略使用時のみ指定可能です。最小1つ～最大6つの曜日を選択する必要があり、選択した曜日には全体バックアップが行われ、選択しない曜日には増分バックアップが行われます。

バックアップ実行時間

• バックアップが自動的に実行される時間を設定できます。バックアップ開始時刻とバックアップウィンドウで構成されます。バックアップ実行時間は重複しないように複数回設定できます。バックアップ開始時刻を基準に、バックアップウィンドウ内のある時点でバックアップを実行します。バックアップウィンドウはバックアップの総実行時間とは関係ありません。バックアップにかかる時間はデータベースのサイズに比例し、サービス負荷によって異なります。バックアップが失敗した場合、バックアップウィンドウを超えなければ、バックアップ再試行回数に基づいてバックアップを再試行します。

[注意] 前のバックアップが終了しないなどの状況では、バックアップが実行されない場合があります。 スケジュール上、増分バックアップを実行する順番であっても、増分が可能な基準バックアップが存在しない場合、全体バックアップが実行されることがあります。 増分可能な基準バックアップの詳細については、基準バックアップの項目を参照してください。

バックアップストレージおよび課金

すべてのバックアップファイルは、内部バックアップストレージにアップロードして保存します。手動バックアップの場合、別途削除するまで永続的に保存され、バックアップ容量に応じてバックアップストレージの料金が発生します。自動バックアップの場合、設定した保管期間だけ保存され、自動バックアップファイルの全体サイズのうち、DBインスタンスのストレージサイズを超過した容量に対して課金されます。バックアップファイルが保存されている内部バックアップストレージに直接アクセスすることはできず、バックアップファイルが必要な場合は、NHN Cloudのオブジェクトストレージにバックアップファイルをエクスポートできます。

バックアップのエクスポート

バックアップを実行しながらファイルをエクスポート

バックアップ後、バックアップファイルをユーザーオブジェクトストレージにエクスポートできます。増分バックアップについてはサポートされません。

❶バックアップするDBインスタンスを選択した後、ドロップダウンメニューからバックアップ後オブジェクトストレージにバックアップファイルをエクスポートをクリックすると、設定ポップアップ画面が表示されます。 ❷バックアップが保存されるオブジェクトストレージのテナントIDを入力します。テナントIDはAPIエンドポイント設定で確認できます。 ❸バックアップが保存されるオブジェクトストレージのNHN CloudメンバーまたはIAMメンバーを入力します。 ❹バックアップが保存されるオブジェクトストレージのAPIパスワードを入力します。 ❺バックアップが保存されるオブジェクトストレージのコンテナを入力します。 ❻コンテナに保存されるバックアップのパスを入力します。フォルダ名は最大255バイトで、全体のパスは最大1024バイトです。特定の形(. または ..)は使用できず、特殊文字(' " < > ;)とスペースは入力できません。

バックアップファイルのエクスポート

内部バックアップストレージに保存されたバックアップファイルをユーザーオブジェクトストレージにエクスポートできます。増分バックアップについてはサポートされません。

❶バックアップを実行した原本DBインスタンスの詳細タブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックすると、バックアップをエクスポートするためのポップアップ画面が表示されます。

❷またはバックアップタブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックします。

[参考] 手動バックアップの場合、バックアップを実行した元DBインスタンスが削除されると、バックアップをエクスポートできません。

復元

バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。バックアップを実行した元のDBインスタンスと同じDBエンジンのバージョンにのみ復元できます。バックアップが作成された時点に復元するスナップショット復元、希望する特定の時点に復元する時点復元をサポートします。RDS for MySQLで作成したバックアップだけでなく、外部MySQLのバックアップにも復元できます。

[注意] 復元するDBインスタンスのデータストレージサイズがバックアップを実行した元のDBインスタンスのストレージサイズより小さい場合や、元のDBインスタンスのパラメータグループと異なるパラメータグループを使用する場合、復元に失敗することがあります。

スナップショット復元

バックアップファイルだけで復元を行うため、バックアップを実行した原本DBインスタンスが必要ありません。 コンソールでスナップショットを復元するには

❶ DBインスタンスの詳細タブで復元するバックアップファイルを選択した後、スナップショット復元をクリックすると、DBインスタンスの復元画面に移動します。

または

❶バックアップタブで復元するバックアップファイルを選択した後、スナップショット復元をクリックします。

時点復元

時点復元を利用して、希望する特定の時点またはバイナリログ(binary log)の特定の位置に復元できます。時点復元をするためには、バックアップファイルとバックアップを実行した時点から復元を希望する時点までのバイナリログ(binary log)が必要です。バイナリログ(binary log)は、バックアップが行われる元DBインスタンスのストレージに保存されます。バイナリログ(binary log)の保管期間が短い場合、ストレージ容量をより多く使うことがありますが、希望する時点への復元が難しい場合があります。下記の場合、時点復元に必要なバイナリログ(binary log)がないため、希望の時点に復元できない場合があります。

• 容量確保のために元DBインスタンスのバイナリログ(binary log)を削除した場合。
• バイナリログ(binary log)保管期間に基づいてMySQLによって自動的にバイナリログ(binary log)が削除された場合
• 高可用性DBインスタンスのフェイルオーバーによりバイナリログ(binary log)が削除された場合。
• その他様々な理由でバイナリログ(binary log)が破損したり、削除されている場合。

コンソールで時点復元を行うには

❶時点復元するDBインスタンスを選択した後、+時点復元をクリックすると、時点復元を設定できるページに移動します。

Timestampを利用した復元

Timestampを使用した復元の場合は、選択した時点と最も近いバックアップファイルを基準に復元を行い、希望する時点までのバイナリログ(binary log)を適用します。

❶復元方法を選択します。

❷復元時刻を選択します。直近の時点に復元するか、希望する特定の時点を直接入力できます。

❸ 復元される最後のクエリを確認をクリックすると、最後に復元されるクエリを確認できるポップアップ画面が表示されます。

バイナリログ(binary log)を利用した復元

バイナリログ(binary log)を活用した復元過程では、選択したバックアップファイルで先に復元を行った後、希望する位置までのバイナリログ(binary log)を適用します。

❹バイナリログ(binary log)で復元するためには、まず、バックアップファイルを選択する必要があります。 ❺バイナリログ(binary log)ファイルを選択します。 ❻バイナリログ(binary log)の特定位置を入力します。

外部MySQLバックアップを利用した復元

外部MySQLバックアップファイルを利用してDBインスタンスを作成できます。外部MySQLバックアップファイルを作成する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。

[注意] innodb_data_file_pathの設定値がibdata1:12M:autoextendでない場合、RDS for MySQLのDBインスタンスに復元できません。

(1) MySQLがインストールされたサーバーで下記のコマンドを利用してバックアップを実行します。

XtraBackup 2.4.xx例

innobackupex --defaults-file={my.cnfパス} --user {ユーザー} --password '{パスワード}' --socket {MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}

XtraBackup 8.0.xx例

xtrabackup --defaults-file={my.cnfパス} --user={ユーザー} --password='{パスワード}' --socket={MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream --backup {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}

(2)バックアップログファイルの最後の行にcompleted OK!があるか確認します。completed OK!`がない場合は、バックアップが正常に終了していないため、ログファイルにあるエラーメッセージを参照してバックアップを再度行います。

(3)完了したバックアップファイルをオブジェクトストレージにアップロードします。

• 一度にアップロードできる最大ファイルサイズは5GBです。
• バックアップファイルのサイズが5GBより大きい場合、splitのようなユーティリティを利用してバックアップファイルを5GB以下に分割した後、マルチパートでアップロードする必要があります。
• 詳細については、 マルチパートアップロードを参照してください。

(4)復元するプロジェクトのコンソールに接続した後、DBインスタンスタブでオブジェクトストレージにあるバックアップで復元ボタンをクリックします。

[注意] 現在5.7.33バージョンでは、オブジェクトストレージのバックアップファイルを利用したDBインスタンスの復元は制限されます。 推奨するXtraBackup以外のバージョンを使用すると、正常に動作しない場合があります。 オブジェクトストレージのバックアップファイルと復元しようとするMySQLのバージョンは同じでなければなりません。

RDS for MySQLのバックアップを利用した復元

RDS for MySQLのバックアップファイルを利用して直接MySQLのデータベースを復元することができますが、全体バックアップに対してのみ復元が可能で、増分バックアップの反映はサポートされません。RDS for MySQLのバックアップファイルを復元する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。

(1) バックアップのエクスポートの項目を参照して、RDS for MySQLのバックアップをオブジェクトストレージにエクスポートします。

(2)オブジェクトストレージのバックアップを復元したいサーバーにダウンロードします。

(3) MySQLサービスを停止します。

(4) MySQLデータ保存パスのすべてのファイルを削除します。

rm -rf {MySQLデータ保存パス}/*

(5)ダウンロードしたバックアップファイルを解凍して復元します。

XtraBackup 2.4.xxの例

cat {バックアップファイル保存パス} | xbstream -x -C {MySQLデータ保存パス}
innobackupex --decompress {MySQLデータ保存パス}
innobackupex --defaults-file={my.cnfパス} --apply-log {MySQLデータ保存パス}

XtraBackup 8.0.xxの例

cat {バックアップファイルの保存パス} | xbstream -x -C {MySQLデータ保存パス}
xtrabackup --decompress --target-dir={MySQLデータの保存パス}
xtrabackup --prepare --target-dir={MySQLデータ保存パス}
xtrabackup --defaults-file={my.cnfパス} --copy-back --target-dir={MySQLデータ保存パス}

(6)解凍後、不要なファイルを削除します。

find {MySQLデータ保存パス} -name "*.qp" -print0 | xargs -0 rm

(7) MySQLサービスを起動します。