RDS・Auroraの自動バックアップをAWS Backupに移行するときの勘所

Last updated at 2024-09-21Posted at 2024-09-21

はじめに

お疲れ様です。矢儀 @yuki_ink です。

AWS Backup、使ってますか？

本記事は、RDS・AuroraのバックアップをAWS Backupで取得するようにする際の勘所（注意事項・移行パターン）をまとめたものです。

AWS Backupは、AWSサービスのバックアップを一元管理できるフルマネージドサービスです。
2019年1月にローンチされ、今やAWS認定資格でも常連の古株サービスですが、最近では、ランサムウェア対策の文脈でAWS Backup、特にその中の「Vault Lock」機能について触れられる機会が多くなったように思います。

AWS Backup Vault Lock
AWS Backup は、バックアップの一元管理と自動化を実現するフルマネージドサービスです。手動と自動スケジュールのバックアップを実施することができます。1 つのコンソールで、多岐にわたる AWS リソースのバックアップの設定と実行、復旧を実施することができ、一元管理することができます。暗号化した個別の Vault と呼ばれる単位でデータを格納することができるため、セキュリティを確保することもできます。Vault は、バックアップを保存および整理するためのコンテナです。

AWS Backup Vault Lock は AWS Backup のオプション機能で、対象の Valut を読み込み専用である WORM に設定することができます。この機能により、バックアップデータを変更できなくなるため、バックアップデータの暗号化といった、ランサムウェアによる悪意ある攻撃を防ぐことができます。
また、不注意や誤操作によってバックアップが削除されることも防ぐことができるという利点もあります。
医療機関に限らず、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護することができます。

（出典）ランサムウェア被害から医療データの安全を守る

以降の内容は、「Vault Lock」機能の利用も想定しながら記述していきます。

1. 前提

本記事では基本的に、RDSとAuroraをまとめて「RDS」と記載します。
あえてRDSとAuroraの違いについて触れたいときは、RDSとAuroraを明確に区別する記載を心掛けます。
　
ここでは、AWS Backup・RDSの細かい設定方法については触れません。
AWS Backupの設定に関しては、以前記事にまとめたので、こちらもご参照ください。
（参考）AWS BackupでEBS/RDS/S3のバックアップを取得してみた
　
バックアップ関連用語の定義については以下の通りです。

1.1. RDSのバックアップ関連用語

本記事で使用する用語	説明
自動バックアップ	RDSの機能の1つとして提供される。指定したバックアップウィンドウ中に毎日スナップショットが取得されるほか、あわせてトランザクションログも取得され、Point-in-Time Recovery (PITR)が可能になる。最大35日間保管。（参考）自動バックアップの管理
手動バックアップ	任意のタイミングで、RDSのコンソール画面（またはCLIコマンド`create-db-snapshot`など）での操作を通して取得されるスナップショット。保持期限はなし。（参考）手動バックアップの管理

「自動バックアップ」と「手動バックアップ」の違いは、AWSのFAQページにも記載されています。
（参考）Automatic Backups and Database Snapshots

1.2. AWS Backupのバックアップ関連用語

本記事で使用する用語	説明
継続的なバックアップ	AWS Backupで取得するバックアップのオプションとして提供される。トランザクションログの取得により、Point-in-Time Recovery (PITR)が可能になる。最大35日間保管。（参考）継続的なバックアップと point-in-time 復元 (PITR）
スナップショットバックアップ	「継続的なバックアップ」を有効にしなかった場合に自動的に適用される。最短で1時間に1回の頻度でバックアップを取得できる。最大100年間保管。（参考）継続的なバックアップと point-in-time 復元 (PITR）

AWS Backupのバックアッププランで「継続的なバックアップ」を有効化し、RDSをバックアップ取得対象とした場合、AWS Backupの動作の裏でRDSの「自動バックアップ」が動く（正確には、AWS BackupがRDSの「自動バックアップ」の取得を管理する）ようになります。

一方で、AWS Backupのバックアッププランで「継続的なバックアップ」を有効化せず、つまりスナップショットバックアップを取得する形にした場合、実体としてはRDSの「手動バックアップ」が取得されます。

後ほど詳述します。

ここまで来ると、タイトルの「RDS・Auroraの自動バックアップをAWS Backupに移行する」という表現が、正確ではないことが分かります…(苦笑)
正確には、「RDS・Auroraのバックアップの取得・管理の方式を、自動バックアップからAWS Backupへ移行する」という表現になるような気がします。

1.3. 今回使う環境（バックアップ取得対象のRDS）

項目	値
エンジン	Oracle Standard Edition Two
バージョン	19.0.0.0.ru-2024-07.rur-2024-07.r1
リージョン	オハイオ（us-east-2）
ライセンスモデル	License Included
自動バックアップ	有効
パラメータグループ	※デフォルトのパラメータグループを利用
オプショングループ	Timezoneを設定

▼「自動バックアップ」の設定

自動バックアップを7日間保管
バックアップウィンドウは15:00-16:00(UTC)
取得したバックアップは東京リージョンにレプリケーション

▼オプショングループの設定

Timezone を設定しています。

バックアップのレプリケーションの設定と Timezone の設定が、後述の問題に繋がってきます…

2. 移行するときの勘所

前置きが長くなってしまいましたが、ここから本題です。
今回は以下の状況を想定します。

今までRDSの「自動バックアップ」を利用してバックアップを取得・管理していた
RDSのバックアップの取得・管理の方式を、AWS Backupへ移行する

2.1. 「継続的なバックアップ」の有効 / 無効による違い

AWS Backupのバックアップルールで ポイントインタイムリカバリ (PITR) のために継続的なバックアップを有効化 にチェックを入れると、「継続的なバックアップ」が有効化されます。

チェックを入れると、合計保持期間のMaxが35日となります。
RDSの「自動バックアップ」の合計保持期間もMaxが35日だったので、それと通ずるところがありますね。

2.1.1. 「継続的なバックアップ」を有効にしたとき

「継続的なバックアップ」が有効な場合、AWS Backup バックアップジョブの初回稼働時に、RDSの「自動バックアップ」がAWS Backupに引き継がれます。
そして、RDSの画面からバックアップの設定はできなくなります。

▼バックアップジョブの初回稼働後のRDSの画面

自動バックアップは AWS Backup 内のバックアッププランで管理されています。 と表示されるようになりました。

なお、AWS Backup設定前にRDSの「自動バックアップ」で取得されたバックアップは、「自動バックアップ」の設定で指定されていた保持期間に従い、自動で削除されます。

2.1.2. 「継続的なバックアップ」を無効にしたとき

「継続的なバックアップ」が無効な場合は、RDSの「手動スナップショット」がバックアップルールのスケジュールに従って取得される動作となります。
この場合、RDSの「自動バックアップ」の設定・動作に影響はありません。

▼バックアップジョブの初回稼働後のRDSの画面（当初から変わりなし）

ただし、AWS Backupのバックアップ取得時間帯をRDSの「自動バックアップ」のバックアップウィンドウに被せてしまうと、以下のエラーが発生し、AWS Backup側のバックアップジョブが失敗します。

Backup job XXXXXXXX-XXXX-XXXX-XXXX could not start because it is either inside or too close to the automated backup window configured in RDS instance.

RDSの「自動バックアップ」が有効な状態で、AWS Backup（「継続的なバックアップ」が無効）を動かすときは、時間帯に注意しましょう。

AWSのドキュメントにも、以下のように案内がされています。

AWS Backup バックアッププランが Amazon RDSインスタンスの複数の日次スナップショットを作成するようにスケジュールされていて、それらのスケジュールされたAWS Backup バックアップ開始ウィンドウの 1 つが Amazon RDS Backup ウィンドウと一致すると、バックアップのデータ系統が非同一バックアップに分岐し、計画外の競合するバックアップを作成できます。これを防ぐには、 AWS Backup バックアッププランまたは Amazon RDSウィンドウが時間と一致しないようにしてください。
（参考）Amazon Relational Database Service のバックアップ

2.2. RDS for Oracleのスナップショットをクロスリージョンコピーする必要がある場合の注意事項

RDS for Oracleを利用しかつ、オプショングループで Timezone を設定している場合、AWS Backupによるバックアップのクロスリージョンコピーは失敗します。

こちらの記事で詳しく書かれている件です。

今回は、もともとのRDSの「自動バックアップ」の設定でオハイオ⇒東京へのレプリケーション設定を入れていたので、AWS Backup バックアップルールでも同様の設定を入れました。

コピージョブが失敗。

The snapshot requires a target option group with the following options: [Timezone] と表示されています。

RDSの「自動バックアップ」では実現できていたバックアップのクロスリージョンコピーが、AWS Backupでは実現できない点に注意が必要です。

3. 自動バックアップからAWS Backupへの移行パターン

次のようにまとめてみました。

確認ポイントと、それに紐づく分岐（移行パターン）について、以下に詳述します。

3.1. 確認ポイント

2章でご紹介した勘所を踏まえると、3つの確認ポイントがあると思います。

#1 : AWS Backupを使うかどうか

AWS Backupが、バックアップを取得したいサービスに対応しているか
そもそも本当にAWS Backupを利用する必要があるか
（RDSの「自動バックアップ」では満たせない要件があるか）

AWS Backupが対応しているサービスと、利用できる機能については、AWSのドキュメントを参照してください。

AWS Backupでは、「Vault Lock」機能やコールドストレージへのライフサイクルなど、魅力的な機能が多く提供されています。
ただ、AWS Backupは多機能である分、設計要素も多いです。
使わないという選択肢もアリだと思います。

検討の結果、AWS Backupを使うという選択に至れば、確認ポイント #2 へ！

#2 : RDS for Oracleのスナップショットをクロスリージョンコピーする必要があるか

RDS for Oracleを利用し、
かつ、オプショングループでTimezoneを設定し、
かつ、スナップショットのクロスリージョンコピーの要件があるか?

2.2. RDS for Oracleのスナップショットをクロスリージョンコピーする必要がある場合の注意事項 でご紹介したケースに該当するかどうかです。
このケースに該当すると、現状では、RDSの「自動バックアップ」を継続して使わざるを得ません。
その結果、パターンA : RDSの「自動バックアップ」とAWS Backupを並行稼働 を選択することになります。

このケースに該当しなければ、どのような段取りでAWS Backupに移行したいかを考えます。
確認ポイント #3 へ！

#3 : AWS Backupへの移行前に、試しに並行稼働させたい？

RDS自動バックアップとAWS Backupを一時的に並行稼働させて、
動作（バックアップ取得対象・タイミングなど）に問題がなければ、AWS Backupに移行するという段取りにしたいか?

ブルー/グリーンデプロイ、カナリアリリース…と、私たちは2面を並行で稼働させることが大好きです！
逆に、そうではない "一方通行" の移行には恐怖を感じます。
できるものなら回避したい。

そんなあなたにとって、2.1. 「継続的なバックアップ」の有効 / 無効による違い でご紹介した内容は、非常に残念なお知らせだったのではないでしょうか。
「継続的なバックアップ」を有効にすると、バックアップジョブの初回稼働時にRDSの「自動バックアップ」がAWS Backupに引き継がれ、「自動バックアップ」は閉鎖されます。
そんな "一方通行" の移行は怖くてできない！安心が欲しい！という考えの方は、パターンB : 一時的に並行稼働させて、あとからAWS Backupに一本化 しましょう。

ただ、冷静に考えれば、RDSの「自動バックアップ」がAWS Backupに引き継がれるだけで、バックアップが途切れたりすることもありません。
そのため、"一方通行" の移行でもリスクは限りなく低いでしょう。
ということで、パターンC : 最初から「継続的なバックアップ」を有効にして移行 するというのもアリだと思います。

3.2. 移行パターン

パターンA : RDSの「自動バックアップ」とAWS Backupを並行稼働

先述の通り、このパターンの場合、RDSの「自動バックアップ」は止められません。
したがって、AWS Backupで「継続的なバックアップ」を有効化することはできません。
※2.1. 「継続的なバックアップ」の有効 / 無効による違い でご紹介した仕様のため

例えば、AWS Backupの「Vault Lock」機能でランサムウェア対策を行う場合、AWS BackupとRDSの「自動バックアップ」の使い分けは次のようになります。

AWS Backup
スナップショットバックアップのみ取得。
「Vault Lock」機能により改ざん・削除から保護される。
　
RDSの「自動バックアップ」
従来と変わらず、内部的には「継続的なバックアップ」を取得。
Timezone が指定されたRDSのバックアップのクロスリージョンコピーも行う。

このケースでは、もしランサムウェアの被害を受けてバックアップからの復元を行う場合、ポイントインタイムリカバリでなく、AWS Backupによって取得されたスナップショットバックアップからの切り戻しが望まれます。
※「Vault Lock」機能により改ざん・削除から保護されるのは、あくまでAWS Backupで取得されたバックアップのみ

RPO（目標復旧時点）を踏まえ、適切なバックアップ頻度を設定しましょう。

パターンB : 一時的に並行稼働させて、あとからAWS Backupに一本化

AWS Backupの導入初期、一時的に パターンA を行い、AWS Backupの動作が想定通りであることが確認できれば、AWS Backupの「継続的なバックアップ」を有効化するパターンです。
※「継続的なバックアップ」を有効化したあと、最初のバックアップジョブのタイミングで、RDSの「自動バックアップ」は自動的に閉鎖される

バックアップはシステム運用において重要な役割を果たすものです。
機能検証をしないまま、バックアップ取得方式を変更するのは避けたい…
というときに、こちらのパターンが最適です。

なお、AWS Backup設定前にRDSの「自動バックアップ」で取得されたバックアップは、「自動バックアップ」の設定で指定されていた保持期間に従い、自動で削除されます。
※AWS Backupのバックアッププランで指定した保持期間ではない

先述の通り、AWS Backupのバックアップ取得時間帯をRDSの「自動バックアップ」のバックアップウィンドウに被せてしまうと、AWS Backup側のバックアップジョブが失敗することがあります。
並行稼働期間中はそれぞれのバックアップ取得時間帯が被らないようにするための考慮・計画が必要です。

パターンC : 最初から「継続的なバックアップ」を有効にして移行

AWS Backupの導入時に、「継続的なバックアップ」を有効にしておき、最初のバックアップジョブのタイミングで、RDSの「自動バックアップ」を閉鎖するパターンです。

個人的には、パターンCが一番シンプルで、良いような気がします。
パターンA、パターンBは、並行稼働の間、バックアップが2重で取得されるため、その分追加コストも発生します。

4. FAQ

気になって調べた内容をFAQ形式でまとめます。

4.1. AWS Backupの「継続的なバックアップ」を停止するには？

AWS Backupのバックアッププランで「継続的なバックアップ」を無効にした上で、復旧ポイントを削除 or 関連付けの解除を行う必要があります。

継続的なバックアップを停止する場合は、バックアッププランから継続的なバックアップルールを削除する必要があります。すべてのリソースの継続的バックアップを停止せずに、1 つ以上のリソースの継続的バックアップを停止する場合は、継続的バックアップを行うリソースについて、継続的バックアップルールを設定した新しいバックアッププランを作成します。代わりに、バックアップボールトから継続的バックアップ復旧ポイントを削除するだけであっても、バックアッププランでは継続的バックアップルールが引き続き実行され、新しい復旧ポイントが作成されます。

ただし、継続的バックアップルールを削除した後でも、は削除されたバックアップルールの保持期間を AWS Backup 記憶します。指定した保持期間に基づいて、バックアップ保管庫から継続的なバックアップリカバリポイントが自動的に削除されます。

（参考）継続的バックアップの停止または削除

4.2. AWS Backupによるバックアップ取得のタイミングは？

こちらの記事で非常に詳しく検証されていたので、是非ご一読ください。

4.3. AWS Backupの機能・コンポーネントがありすぎてわからない

こちらの記事が分かりやすかったので、是非ご一読ください。

後から追記するかも

終わりに

最近AWS Backupを触る機会があったのでまとめてみました。
バックアップの取り方を変えたいだけなのに、色々考えること、調べることが多く、苦労しましたw
この記事が何かのお役に立てば幸いです。

2.2. RDS for Oracleのスナップショットをクロスリージョンコピーする必要がある場合の注意事項 の件は、機能改善が待たれます…

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up