AWS BackupによるAmazon RDSのスナップショットは手動スナップショット扱いになる
2025.02.17初めに
AWS BackupはEC2、RDS、FSx等様々なサービスのバックアップの取得や管理を一元的に管理できます。
できることが多い分ある程度の複雑性は伴うものの、サービス毎の設定差異の吸収もある程度でき設定箇所も集約できるため個人的にはAWSでバックアップといえばでとりあえず考えておくサービスになっています。
ふとした際にそういえばAmazon RDSのバックアップを取得しようと思った際、利便性は別としても、そもそも取り扱いにって何か特性ってあるんだっけ？となって改めて確認してみました。
AWS Backupで取得されたバックアップは自動バックアップではない
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/AutomatedBackups.AWSBackup.html
AWS Backup によって管理されるバックアップは手動 DB スナップショットと見なされますが、RDS の DB スナップショットクォータにはカウントされません
結論だけ言えばAmazon RDSのドキュメントに明記されており、Amazon RDS標準バックアップ機能である自動バックアップではなく手動バックアップという扱いになるため、あくまで外部でスケジューリングして手動実行を呼び出すという扱いになります。
ただAmazon RDSのスナップショット機能を利用して取得されていることによることに違いはないため、多くの場合はどちらでも変わらないケースが多いものとなります。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Limits.html
AWS Backup によって管理されるバックアップは手動 DB スナップショットと見なされますが、手動スナップショットクォータにはカウントされません。AWS Backup の詳細については、『AWS Backup デベロッパーガイド』を参照してください。
※ 手動スナップショットだけどクォータとしては別枠なため厳密に追うとさらに別扱いになりそうです
AWS Backupによる柔軟なスケジューリング
AWS Backup側の機能もありますが手動バックアップとなることにより自動バックアップの制約に縛られない柔軟なバックアップスケジューリングが設定可能となります。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html
自動バックアップは、優先されるバックアップウィンドウ中に毎日行われます。
Amazon RDS標準のバックアップによる取得されるスナップショットは連続した日次での取得かつ最大35日という制約があるため、システムの事情によってはこちらを採用できない場合があります。
一方AWS Backupを利用したバックアップはcron式に対応した範囲内で柔軟なバックアップが指定可能なため月次・週次バックアップといったことも可能であり、また最大無期限保持も可能ですのでかなり幅広い実行保持計画を実現可能です。
また、うまく複数のルールを組み合わせることで通常のバックアップは短期間持ちつつ一定期間毎に長期間のバックアップを作成も可能ですので、こういった点を含め保持期間や取得に柔軟な対応が求められるような場合はAWS Backupを採用するのが良さそうです。
10分毎の取得等短期間方面へのバックアップにも仕様上は対応できますが、自動・手動スナップショットいずれの場合でもI/O待機の関係で取得地点のブレは発生するため想定通りのタイミングで取得できない可能性があります。
そういった場合は無理にAWS Backupのスケジューリングによる指定にこだわらず、スナップショットの取得自体は日次で行い、それ未満の復旧はポイントインタイムリカバリに期待することも視野に入れてみてください。これはAmazon RDSで自動バックアップを行った場合、AWS Backupを利用した場合いずれでも行うことは可能です。
自動バックアップならではの機能に気をつけよう
設定に多少の複雑性は伴うものの他のサービスのバックアップも考えるのであれば全てAWS Backupに寄せてしまえば良いのでは？となるところですがこれだけでは対応できないケースも存在します。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html
RDS for SQL Server のトランザクションログのバックアップにアクセスすることで、データベースのトランザクションログのバックアップファイルを一覧表示し、ターゲット Amazon S3 バケットにコピーできます。(中略)DB インスタンスで自動バックアップを有効に設定し、バックアップの保存期間を 1 日以上の値に設定する必要があります。
例としてAmazon RDS for SQL ServerではS3へのトランザクションログのリストアおよびそれを用いた地点復元が可能ですが、この機能はAmazon RDSの自動バックアップに依存しており自動バックアップを無効化してしまうとこの機能を利用できません。
※ 現時点ではAmazon RDSのポイントインタイムリカバリの機能はインスタンス単位での復元になるため、内部のデータベース単位による復元はこちらの機能が必須となります
https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/rds-backup.html
AWS Backup バックアッププランが Amazon RDS インスタンスの複数の日次スナップショットを作成するようにスケジュールされており、それらのスケジュールされた AWS Backup バックアップ開始ウィンドウの 1 つが Amazon RDS バックアップウィンドウと重なると、バックアップのデータ系統が非同一バックアップに分岐して、予期しない競合するバックアップが作成される可能性があります。これを防ぐには、AWS Backup バックアッププランまたは Amazon RDS ウィンドウの期間が重ならないようにします。
一応この機能を有効化する=AWS Backupを利用できないということではなく併用も可能となりますが、それぞれで別のスナップショットが生成される形となります。
多重管理の発生および競合回避のためのバックアップウィンドウの設計をするという形になりますので、要件によってはAWS Backupに寄せすぎることにこだわりすぎず、素直にAmazon RDSの自動バックアップのみの利用も選択肢としてみてください。
終わりに
AWS BackupによるAmazon RDSのバックアップの取り扱いについて改めて確認してみました。
どちらも結果的に生成されるのは同じAmazon RDSのスナップショットですが自動・手動由来の細かな仕様の違いが出てきます。
多くの場合はあまり気にすることがない部分となりますが、DBMS固有の機能、特にバックアップに関連する部分に絡みそうな機能がある場合は、Amazon RDS側固有の部分と結びついている可能性がありますので事前に確認するように心がけましょう。
補足：Amazon FSxも手動バックアップ扱い
https://docs.aws.amazon.com/ja_jp/fsx/latest/WindowsGuide/using-backups.html#aws-backup-and-fsx
AWS Backup によって作成されたバックアップは、ユーザーが開始したバックアップとみなされ、Amazon FSx のユーザーが開始したバックアップのクォータにカウントされます。
本件のついでで確認していたのですがFSxのバックアップもAWS Backupで取得すると手動バックアップ扱いとなるようです。
確認していた件ではこの違いによる機能差は見当たらなかったのですが、他のサービス・今後サービス固有に実装される機能によってはAWS Backupのみではなく各サービス組み込みのバックアップ機能を利用する必要というのがあるかもしれません。
どうなるかわからない部分も多いためそれを見越して...というのは無理な相談ではありますが、サービスによっては取り扱いに差があるという部分は頭の片隅に置いておいても良いでしょう。
![[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
