Auroraの自動バックアップ機能とAWS Backupの継続的バックアップを同時に有効にしてみた

はじめに

2023年の8月、AWS BackupでAuroraの継続的なバックアップとポイントインタイムリカバリ（以下、PITRと記載）が利用できるようになるアップデートがありました
https://aws.amazon.com/jp/about-aws/whats-new/2023/09/aws-backup-amazon-aurora-continuous-backup/

これまでAuroraのPITRを使用するには、Aurora自体の自動バックアップを使用するしかありませんでした
何が困るかというと、「EC2やEFSのバックアップはAWS Backupでとっているのに、AuroraのバックアップはAWS Backupで取れない」という面倒な管理方法になってしまいます

しかし、今回のアップデートによってAuroraのバックアップもAWS Backupで管理できるようになりました！

一方で、Auroraの自動バックアップ機能は無効化ができない仕様になっています

Aurora の自動バックアップを無効にすることはできません。Aurora のバックアップ保持期間は、DB クラスターによって管理されます。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html

となると、「AWS Backupを有効化したら、Auroraの自動バックアップとAWS Backupで二重にバックアップを取ってしまうのでは？」という疑問が生じました

なので実際に検証を行い、どのような挙動を示すのかを確認してみました！

いきなりまとめ

早速ですがいきなり検証結果をザクっとまとめます

結論、バックアップが二重に取られることはなくAWS Backupの設定が優先される
AWS Backupのバックアップスケジュールが動き出すと、Auroraの自動バックアップが勝手に無効化される
AWS Backupのバックアップスケジュールが動き出した後、Auroraの自動バックアップの設定は変更ができなくなる
- コンソール上では、設定を触ることすらできないような表示に変わる
- AWS CLIやTerraformなど、APIで変更しようとしてもエラーになる

前提知識を軽くおさらい

ここで一旦、継続的なバックアップとPITRについて軽く復習します
（あくまでざっくりとした解説ですので、詳細を知りたい方は別途調べてみてください）

継続的なバックアップとは

公式ドキュメントの文言を一部借りて説明すると
「事前に作成されたフルバックアップと、継続的に取得するトランザクションログにより、回復させたい時刻に巻き戻せるようにするバックアップ機能」です
https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/point-in-time-recovery.html

このバックアップの取得期間によって、後述のPITRで巻き戻せる期間が決まってきます

※AWS以外の文脈で使われることがある言葉ですが、ここでは「AWSのバックアップ取得方法としての継続的なバックアップ」について記載しています

PITRとは

公式ドキュメントの文言を一部借り、一言で説明すると
「DBクラスターの状態をある特定の時点に戻って復元し、新しいDBクラスターを作成する」ことができる機能です
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-pitr.html

普通のバックアップと比較して嬉しいのは、こまめにDBのスナップショットを取得しておける点です
ちゃんとしたバックアップを取るには、データの静止点を設けるためにDBを停止したりする必要があります
ただし、DBを頻繁に停止することができない場合がほとんどだと思いますので、その時は継続的なバックアップで取得したスナップショットを基にPITRをすることで、いざという時にデータの復元が可能です

なお、PITRはAWS特有の機能ではなく、DBの機能として一般的に提供されているものです
https://lets.postgresql.jp/documents/technical/backup/4

元々DBエンジンが持っていたPITRの機能を、AWSのサービスの一部としてマネジメントコンソールやAWS CLIで設定できるようにした、というのが正しい理解だと思います

バックアップ方法の呼称

また前述の通り、Aurora(RDS)のバックアップ方法には大きく分けて2つあります

Aurora(RDS)の機能として提供されている継続的なバックアップ取得方法
AWS Backupの機能として提供さている、Aurora(RDS)の継続的なバックアップ取得方法

これらの呼称ですが、公式ドキュメントの記載に従い、以下のように呼びます

Aurora(RDS)の機能として提供されている継続的なバックアップ取得方法：自動バックアップ
AWS Backupの機能として提供さている、Aurora(RDS)の継続的なバックアップ取得方法：継続的なバックアップ

なお、後者は公式ドキュメント上でも「継続的なバックアップ」と「継続的バックアップ」で若干表記揺れがありそうですが、本記事では「継続的なバックアップ」と記載しておきます

実際に検証してみた

それではここから、実際に検証した結果を記載していきます

前提条件

使用するAuroraの基本パラメータは以下の通りです

Aurora Serverless v2
エンジンはPostgreSQL 15.2
マルチAZ構成、リードレプリカは無し
タイムゾーンを日本に変更

Auroraを準備する

まずは普通にAuroraを構築します

AWS Backupの設定

次に、継続的なバックアップを有効にしたAWS Backupを設定します
設定したバックアップルールは以下の画像の通りです

※今回は、先にAuroraの自動バックアップが作動し、その後にAWS Backupが作動するようにスケジュールを設定しています

ここでAuroraの自動バックアップを確認してみましたが、AWS Backupを有効にしただけでは変化はありません

AWS CLIで確認してみても、Auroraの自動バックアップとAWS Backupの継続的なバックアップ、どちらも設定通り有効になっていることがわかります

$ aws rds describe-db-clusters --db-cluster-identifier xxxxxxxxxxxxxx
{
    "DBClusters": [
        {
            "AllocatedStorage": 1,
            "AvailabilityZones": [
                "ap-northeast-1c",
                "ap-northeast-1a",
                "ap-northeast-1d"
            ],
            "BackupRetentionPeriod": 2,
            "DatabaseName": "test",
            "DBClusterIdentifier": "xxxxxxxxxxxxxx",
            "DBClusterParameterGroup": "xxxxxxxxxxxxxx",
            "DBSubnetGroup": "xxxxxxxxxxxxxx",
            "Status": "available",
            "EarliestRestorableTime": "2023-10-04T02:22:35.667000+00:00",
            "Endpoint": "xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "ReaderEndpoint": "xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "MultiAZ": true,
            "Engine": "aurora-postgresql",
            "EngineVersion": "15.2",
            "LatestRestorableTime": "2023-10-05T05:38:25.344000+00:00",
            "Port": 5432,
            "MasterUsername": "postgres",
            "PreferredBackupWindow": "06:00-07:00",
            "PreferredMaintenanceWindow": "sun:13:18-sun:13:48",
            "ReadReplicaIdentifiers": [],
            "DBClusterMembers": [
                {
                    "DBInstanceIdentifier": "xxxxxxxxxxxxxx",
                    "IsClusterWriter": true,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "PromotionTier": 0
                },
                {
                    "DBInstanceIdentifier": "xxxxxxxxxxxxxx",
                    "IsClusterWriter": false,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "PromotionTier": 0
                }
            ],
            "VpcSecurityGroups": [
                {
                    "VpcSecurityGroupId": "sg-xxxxxxxxxxxxxx",
                    "Status": "active"
                }
            ],
            "HostedZoneId": "xxxxxxxxxxxxxx",
            "StorageEncrypted": true,
            "KmsKeyId": "xxxxxxxxxxxxxx",
            "DbClusterResourceId": "cluster-xxxxxxxxxxxxxx",
            "DBClusterArn": "xxxxxxxxxxxxxx",
            "AssociatedRoles": [],
            "IAMDatabaseAuthenticationEnabled": false,
            "ClusterCreateTime": "2023-08-07T05:34:25.664000+00:00",
            "EnabledCloudwatchLogsExports": [
                "postgresql"
            ],
            "EngineMode": "provisioned",
            "DeletionProtection": true,
            "HttpEndpointEnabled": false,
            "ActivityStreamStatus": "stopped",
            "CopyTagsToSnapshot": false,
            "CrossAccountClone": false,
            "DomainMemberships": [],
            "TagList": [
                {
                    "Key": "env",
                    "Value": "dev"
                }
            ],
            "AutoMinorVersionUpgrade": false,
            "ServerlessV2ScalingConfiguration": {
                "MinCapacity": 0.5,
                "MaxCapacity": 16.0
            },
            "NetworkType": "IPV4"
        }
    ]
}
$ 
$ aws backup get-backup-plan --backup-plan-id xxxxxxxxxxxxxx
{
    "BackupPlan": {
        "BackupPlanName": "xxxxxxxxxxxxxx",
        "Rules": [
            {
                "RuleName": "xxxxxxxxxxxxxx",
                "TargetBackupVaultName": "xxxxxxxxxxxxxx",
                "ScheduleExpression": "cron(0 8 * * ? *)",
                "StartWindowMinutes": 60,
                "CompletionWindowMinutes": 120,
                "Lifecycle": {
                    "DeleteAfterDays": 2
                },
                "RuleId": "xxxxxxxxxxxxxx",
                "EnableContinuousBackup": true
            }
        ]
    },
    "BackupPlanId": "xxxxxxxxxxxxxx",
    "BackupPlanArn": "xxxxxxxxxxxxxx",
    "VersionId": "xxxxxxxxxxxxxx",
    "CreationDate": "2023-10-05T14:39:46.237000+09:00"
}

バックアップを取得する

ではここから、実際にバックアップを取得していきます
（といっても、すでに設定済みなので設定した時間が来るのを待ちました）

まずは設定通り、Auroraの自動バックアップが動き始めます

この時点でも、まだAuroraの自動バックアップ設定に変化はない

しばらくしてから、AWS Backupのバックアップスケジュールが動き出してリカバリーポイントが作成されます

この後再度、Auroraの設定を確認しに行くと「AWS Backupの設定を見に行ってね」という表示に変わっていました

このクラスタはAWS Backupにバックアッププランがあります。これを表示および管理するには、AWS BackupのBackup plansページに移動します。

また、AWS CLIでAuroraのバックアップ設定を確認してみると、PreferredBackupWindowの設定だけが変わっていることが分かります

$ aws rds describe-db-clusters --db-cluster-identifier xxxxxxxxxxxxxx
{
    "DBClusters": [
        {
            "AllocatedStorage": 1,
            "AvailabilityZones": [
                "ap-northeast-1c",
                "ap-northeast-1a",
                "ap-northeast-1d"
            ],
            "BackupRetentionPeriod": 2,
            "DatabaseName": "test",
            "DBClusterIdentifier": "xxxxxxxxxxxxxx",
            "DBClusterParameterGroup": "xxxxxxxxxxxxxx",
            "DBSubnetGroup": "xxxxxxxxxxxxxx",
            "Status": "available",
            "EarliestRestorableTime": "2023-10-04T02:22:35.667000+00:00",
            "Endpoint": "xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "ReaderEndpoint": "xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "MultiAZ": true,
            "Engine": "aurora-postgresql",
            "EngineVersion": "15.2",
            "LatestRestorableTime": "2023-10-05T08:30:46.069000+00:00",
            "Port": 5432,
            "MasterUsername": "postgres",
            "PreferredBackupWindow": "11:18-13:18",
            "PreferredMaintenanceWindow": "sun:13:18-sun:13:48",
            "ReadReplicaIdentifiers": [],
            "DBClusterMembers": [
                {
                    "DBInstanceIdentifier": "xxxxxxxxxxxxxx",
                    "IsClusterWriter": true,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "PromotionTier": 0
                },
                {
                    "DBInstanceIdentifier": "xxxxxxxxxxxxxx",
                    "IsClusterWriter": false,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "PromotionTier": 0
                }
            ],
            "VpcSecurityGroups": [
                {
                    "VpcSecurityGroupId": "sg-xxxxxxxxxxxxxx",
                    "Status": "active"
                }
            ],
            "HostedZoneId": "xxxxxxxxxxxxxx",
            "StorageEncrypted": true,
            "KmsKeyId": "xxxxxxxxxxxxxx",
            "DbClusterResourceId": "cluster-xxxxxxxxxxxxxx",
            "DBClusterArn": "xxxxxxxxxxxxxx",
            "AssociatedRoles": [],
            "IAMDatabaseAuthenticationEnabled": false,
            "ClusterCreateTime": "2023-08-07T05:34:25.664000+00:00",
            "EnabledCloudwatchLogsExports": [
                "postgresql"
            ],
            "EngineMode": "provisioned",
            "DeletionProtection": true,
            "HttpEndpointEnabled": false,
            "ActivityStreamStatus": "stopped",
            "CopyTagsToSnapshot": false,
            "CrossAccountClone": false,
            "DomainMemberships": [],
            "TagList": [
                {
                    "Key": "env",
                    "Value": "dev"
                }
            ],
            "AutoMinorVersionUpgrade": false,
            "ServerlessV2ScalingConfiguration": {
                "MinCapacity": 0.5,
                "MaxCapacity": 16.0
            },
            "NetworkType": "IPV4"
        }
    ]
}
$

ただ、これだけ見ると裏で有効化されているようにも思えます

なので試しに、AWS CLIを使ってAuroraの自動バックアップ設定を変更しようとしてみました
その結果、「AWS Backupで既に設定されてるから無理だよ」というニュアンスのエラーが発生しました

$ aws rds modify-db-cluster --db-cluster-identifier xxxxxxxxxxxxxx --preferred-backup-window 08:00-09:00

An error occurred (InvalidParameterValue) when calling the ModifyDBCluster operation: RDS cluster xxxxxxxxxxxxxx is associated with the following AwsBackupRecoveryPointArn: xxxxxxxxxxxxxx. The PreferredBackupWindow can be blank, or you can use the current value, 11:18-13:18. For more details, see the AWS Backup documentation.
$

ゆえに、自動バックアップの設定は残っているものの実質無効化されていると思われます

Auroraの自動バックアップ機能とAWS Backupの継続的バックアップを同時に有効にしてみた

はじめに

いきなりまとめ

前提知識を軽くおさらい

継続的なバックアップとは

PITRとは

バックアップ方法の呼称

実際に検証してみた

前提条件

Auroraを準備する

AWS Backupの設定

バックアップを取得する

Figma AI ほぼ全機能使ってみた

MFA許可ポリシーを付与したらIAMユーザでコンソールログインできなかった話

NotebookLM Enterprise で API 経由での操作が可能になりました！

毎朝30分かかってたタスク整理、3分になっちゃった話 - Claude Code × MCP × Obsidian による究極の自動化術 -

Figma MCPサーバーのVSCodeでの導入

Auroraの自動バックアップ機能とAWS Backupの継続的バックアップを同時に有効にしてみた

はじめに

いきなりまとめ

前提知識を軽くおさらい

継続的なバックアップとは

PITRとは

バックアップ方法の呼称

実際に検証してみた

前提条件

Auroraを準備する

AWS Backupの設定

バックアップを取得する

関連記事Related Articles

【RDS for MySQL】クロスリージョン自動バックアップによる新しい災害復旧(DR) 機能の検証

Amazon Aurora と Amazon RDS が MySQL と PostgreSQL データベースの延長サポートを発表

AWS re:Invent 2014 現地リポート 第2弾 〜 Amazon Aurora 発表

Oracle のロックされているテーブルのセッションを知りたい [cloudpack OSAKA blog]

やさしいEC2からRDS疎通確認（TCPレイヤー接続）

AWS re:Invent 2014 現地リポート第2弾〜 Amazon Aurora 発表