障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備することができます。必要な時にコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。バックアップが実行されている間は当該DBインスタンスのストレージのパフォーマンス低下が発生する可能性があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによるパフォーマンス低下を望まない場合は、高可用性構成を使用したり、以前のバックアップ以降のデータの増分のみをバックアップすることができ、リードレプリカでバックアップを実行することもできます。
[参考] 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのストレージパフォーマンス低下が発生しません。 ただし、以下の場合、高可用性DBインスタンスであっても、マスターでバックアップが実行されることがあります。 * 予備マスターの障害により、バックアップ実行が不可能な状態である場合。 * 予備マスターの再構築のため、予備マスターではない他のDBインスタンスで行ったバックアップが必要な状況で、リードレプリカがない場合
バックアップは手動バックアップと自動バックアップに分けられます。
コンソールで手動バックアップを実行して、特定の時点のデータベースを永久に保存できます。手動バックアップは、自動バックアップとは異なり、明示的にバックアップを削除しない限り、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`構文の実行に失敗した場合、バックアップに失敗します。FLUSH TABLES WITH READ LOCK
構文を実行しないため、DML負荷が多くてもバックアップが失敗しません。しかし、テーブルロックを使用しないバックアップは、バックアップデータの一貫性が保証されない可能性があり、これにより、テーブルロックを使用せずに作成されたバックアップ及びテーブルロックを使用しないように設定されたDBインスタンスに対して、復元及び複製プロセスを含む一部の作業をサポートしません。クエリ遅延待機時間(秒)
FLUSH TABLES WITH READ LOCK
構文の待ち時間を設定します。クエリ遅延待機時間だけFLUSH TABLES WITH READ LOCK
構文が待機します。0~21,600秒まで設定可能です。長く設定するほど、DMLクエリの負荷によるバックアップ失敗の可能性を減らすことができますが、全体のバックアップ時間が長くなる可能性があります。次の項目は、自動バックアップ時のみ適用されます。
自動バックアップを許可
自動バックアップの保管期間
[注意] 増分方式で作成されたバックアップは、自動バックアップの保管期間が経過していなくても、基準バックアップが削除されると一緒に削除されます。
自動バックアップ複製リージョン
自動バックアップの再試行回数
**自動バックアップスケジュールの使用
自動バックアップスケジュール戦略
全体データバックアップ曜日
バックアップ実行時間
[注意] 前のバックアップが終了しないなどの状況では、バックアップが実行されない場合があります。 スケジュール上、増分バックアップを実行する順番であっても、増分が可能な基準バックアップが存在しない場合、全体バックアップが実行されることがあります。 増分可能な基準バックアップの詳細については、基準バックアップの項目を参照してください。
すべてのバックアップファイルは、内部バックアップストレージにアップロードして保存します。手動バックアップの場合、別途削除するまで永続的に保存され、バックアップ容量に応じてバックアップストレージの料金が発生します。自動バックアップの場合、設定した保管期間だけ保存され、自動バックアップファイルの全体サイズのうち、DBインスタンスのストレージサイズを超過した容量に対して課金されます。バックアップファイルが保存されている内部バックアップストレージに直接アクセスすることはできず、バックアップファイルが必要な場合は、NHN Cloudのオブジェクトストレージにバックアップファイルをエクスポートできます。
バックアップ後、バックアップファイルをユーザーオブジェクトストレージにエクスポートできます。増分バックアップについてはサポートされません。
❶バックアップするDBインスタンスを選択した後、ドロップダウンメニューからバックアップ後オブジェクトストレージにバックアップファイルをエクスポートをクリックすると、設定ポップアップ画面が表示されます。 ❷バックアップが保存されるオブジェクトストレージのテナントIDを入力します。テナントIDはAPIエンドポイント設定で確認できます。 ❸バックアップが保存されるオブジェクトストレージのNHN CloudメンバーまたはIAMメンバーを入力します。 ❹バックアップが保存されるオブジェクトストレージのAPIパスワードを入力します。 ❺バックアップが保存されるオブジェクトストレージのコンテナを入力します。 ❻コンテナに保存されるバックアップのパスを入力します。フォルダ名は最大255バイトで、全体のパスは最大1024バイトです。特定の形(. または ..)は使用できず、特殊文字(' " < > ;)とスペースは入力できません。
内部バックアップストレージに保存されたバックアップファイルをユーザーオブジェクトストレージにエクスポートできます。増分バックアップについてはサポートされません。
❶バックアップを実行した原本DBインスタンスの詳細タブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックすると、バックアップをエクスポートするためのポップアップ画面が表示されます。
❷またはバックアップタブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックします。
[参考] 手動バックアップの場合、バックアップを実行した元DBインスタンスが削除されると、バックアップをエクスポートできません。
バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。バックアップを実行した元のDBインスタンスと同じDBエンジンのバージョンにのみ復元できます。バックアップが作成された時点に復元するスナップショット復元、希望する特定の時点に復元する時点復元をサポートします。RDS for MariaDBで作成したバックアップだけでなく、外部MariaDBのバックアップにも復元できます。
[注意] 復元するDBインスタンスのデータストレージサイズがバックアップを実行した元のDBインスタンスのストレージサイズより小さい場合や、元のDBインスタンスのパラメータグループと異なるパラメータグループを使用する場合、復元に失敗することがあります。
バックアップファイルだけで復元を行うため、バックアップを実行した原本DBインスタンスが必要ありません。 コンソールでスナップショットを復元するには
❶ DBインスタンスの詳細タブで復元するバックアップファイルを選択した後、スナップショット復元をクリックすると、DBインスタンスの復元画面に移動します。
または
❶バックアップタブで復元するバックアップファイルを選択した後、スナップショット復元をクリックします。
時点復元を利用して、希望する特定の時点またはバイナリログ(binary log)の特定の位置に復元できます。時点復元をするためには、バックアップファイルとバックアップを実行した時点から復元を希望する時点までのバイナリログ(binary log)が必要です。バイナリログ(binary log)は、バックアップが行われる元DBインスタンスのストレージに保存されます。バイナリログ(binary log)の保管期間が短い場合、ストレージ容量をより多く使うことがありますが、希望する時点への復元が難しい場合があります。下記の場合、時点復元に必要なバイナリログ(binary log)がないため、希望の時点に復元できない場合があります。
コンソールで時点復元を行うには
❶時点復元するDBインスタンスを選択した後、+時点復元をクリックすると、時点復元を設定できるページに移動します。
Timestampを使用した復元の場合は、選択した時点と最も近いバックアップファイルを基準に復元を行い、希望する時点までのバイナリログ(binary log)を適用します。
❶復元方法を選択します。
❷復元時刻を選択します。直近の時点に復元するか、希望する特定の時点を直接入力できます。
❸ 復元される最後のクエリを確認をクリックすると、最後に復元されるクエリを確認できるポップアップ画面が表示されます。
バイナリログ(binary log)を活用した復元過程では、選択したバックアップファイルで先に復元を行った後、希望する位置までのバイナリログ(binary log)を適用します。
❹バイナリログ(binary log)で復元するためには、まず、バックアップファイルを選択する必要があります。 ❺バイナリログ(binary log)ファイルを選択します。 ❻バイナリログ(binary log)の特定位置を入力します。
外部MariaDBバックアップファイルを利用してDBインスタンスを作成できます。外部MariaDBバックアップファイルを作成する時、バックアップ項目を参照してRDS for MariaDBで使用するPercona XtraBackupと同じバージョンを使用する必要があります。
[注意] innodb_data_file_pathの設定値がibdata1:12M:autoextendでない場合、RDS for MariaDBのDBインスタンスに復元できません。
(1) MariaDBがインストールされたサーバーで下記のコマンドを利用してバックアップを実行します。
mariabackup --defaults-file={my.cnfパス} --user {ユーザー} --password '{パスワード}' --socket {MariaDBソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}
(2)バックアップログファイルの最後の行にcompleted OK!があるか確認します。
completed OK!`がない場合は、バックアップが正常に終了していないため、ログファイルにあるエラーメッセージを参照してバックアップを再度行います。
(3)完了したバックアップファイルをオブジェクトストレージにアップロードします。
(4)復元するプロジェクトのコンソールに接続した後、DBインスタンスタブでオブジェクトストレージにあるバックアップで復元ボタンをクリックします。
RDS for MariaDBのバックアップファイルを利用して直接MariaDBのデータベースを復元することができますが、全体バックアップに対してのみ復元が可能で、増分バックアップの反映はサポートされません。RDS for MariaDBのバックアップファイルを復元する時、バックアップ項目を参照してRDS for MariaDBで使用するPercona XtraBackupと同じバージョンを使用する必要があります。
(1) バックアップのエクスポートの項目を参照して、RDS for MariaDBのバックアップをオブジェクトストレージにエクスポートします。
(2)オブジェクトストレージのバックアップを復元したいサーバーにダウンロードします。
(3) MariaDBサービスを停止します。
(4) MariaDBデータ保存パスのすべてのファイルを削除します。
rm -rf {MariaDBデータ保存パス}/*
(5)ダウンロードしたバックアップファイルを解凍して復元します。
cat {バックアップファイルの保存パス} | xbstream -x -C {MariaDBデータ保存パス}
mariabackup --decompress {MariaDBデータ保存パス}
mariabackup --defaults-file={my.cnfパス} --apply-log {MariaDBデータ保存パス}
(6)解凍後、不要なファイルを削除します。
find {MariaDBデータ保存パス} -name "*.qp" -print0 | xargs -0 rm
(7) MariaDBサービスを起動します。