AWS Backupで継続的バックアップを有効化したときのRDSとAuroraのバックアップの挙動を確認してみる

継続的バックアップを有効化した時の挙動が気になる

こんにちは、のんピ(@non____97)です。

皆さんはAWS Backupで継続的バックアップを有効化した時の挙動が気になると思ったことはありますか? 私はあります。

AWS Backupでは継続的バックアップを有効化することで、RDS側で自動バックアップを有効化しなくともPITRを行うことが可能です。

AWS公式ドキュメントにて、AWS BackupによるRDSの継続的バックアップの説明には「自動バックアップのバックアップウィンドウを調整できない」や「強制的に1日1回スナップショットを作成する」といった文言が記載がありました。

バックアップスケジュール： AWS Backup プランが Amazon RDS スナップショットと継続的バックアップの両方を作成する場合、競合を防ぐために、Amazon RDS メンテナンスウィンドウを調整するバックアップウィンドウを AWS Backup インテリジェントにスケジュールします。競合をさらに防ぐために、Amazon RDS 自動バックアップウィンドウを手動で設定することはできません。RDS は、バックアッププランに 1 日 1 回以外のスナップショットバックアップの頻度が設定されているかどうかに関係なく、1 日に 1 回スナップショットを作成します。

継続的なバックアップと point-in-time 復元 (PITR) - AWS Backup

具体的にどんな挙動をするのでしょうか。実際に操作をしながら挙動を確認していきます。

いきなりまとめ

• AWS Backupで継続的バックアップを有効化すると、RDSに設定した自動バックアップおよびAWS Backupのバックアップウィンドウは無視される
  • AWS側がメンテナンスウィンドウを加味して自動で調整をする
  • 一日一回、メンテナンスウィンドウの2時間前に日次でスナップショットが取得される
  • バックアップ頻度を毎時にしていたとしても、バックアップジョブは動作するが新規のスナップショットは取得されない
• AWS Backupで継続的バックアップを有効化すると、RDSおよびAurora側で自動バックアップの表示および設定変更はできなくなる
  • 設定変更できなくなるタイミングはAWS Backupの初回バックアップ後
  • 設定変更できるようにするためには、AWS Backupのバックアッププランで対象外にした上で、継続的バックアップの復旧ポイントを削除 or 関連付け解除をする必要がある
• AWS Backupのスナップショットバックアップと、RDSおよびとAuroraの自動バックアップは排他的に実行されない
  • それぞれ別で実行される
• 継続的バックアップが有効な場合でも、バックアップコピーの設定をしている場合はスナップショットが指定した間隔で取得される
• 継続的バックアップが有効な状態でバックアップコピーを設定した場合の挙動は以下のとおりで、増分が最新の日次スナップショットからなのか、直近削除されたスナップショットからなのかはドキュメントからは読み取れない
  • スナップショットをコピーした後、送信元スナップショットは削除される
  • 継続的バックアップを有効化することによって日次でスナップショットが取得される
  • 継続的バックアップを有効化することによって取得される日次でスナップショット自体はコピーされない
• 継続的バックアップが有効なRDS DBインスタンスやAurora DBクラスターを削除する際に、削除時に併せて自動バックアップを削除することはできない
• RDSで自動バックアップを有効にして作成をした場合、作成時にスナップショットが取得される
• こんな時はAWS Backupで継続的バックアップを有効化
  • バックアップを一元的に管理したい
  • バックアップボールトや監査ログといったAWS Backupの機能を使用したい
  • RDS DBインスタンスやAurora DBクラスターを削除する際に併せて自動バックアップが削除されないようにしたい
• こんな時はAWS Backupでは継続的バックアップを無効にして、RDSで自動バックアップを有効化
  • バックアップウィンドウを明示的に指定したい
  • 毎時など日次以外の間隔でバックアップを取得したい
  • 確実に増分コピーを行いたい
  • 90日以上スナップショットを保持しておきたい

やってみた

RDS DBインスタンスとAurora DBクラスターの作成

検証用にRDS DBインスタンスとAurora DBクラスターの作成をします。

それぞれ以下のように異なるバックアップ設定を行います。

自動バックアップを有効にしているものは、バックアップウィンドウを以下のように設定しています。

• RDS DBインスタンス : UTC 21:00 - 21:30
• Aurora DBクラスター : 自動割り当て (Aurora DBクラスターをマネジメントコンソールで作成する際はバックアップウィンドウを明示的に指定することはできない)

メンテナンスウィンドウについてはいずれもJST 9:00 - 9:30 で設定をしています。

また、AWS Backupのバックアッププランではいずれも1時間に一度動作するようにしています。

作成したAurora DBクラスターとRDS DBインスタンスは以下のとおりです。

• aurora-1

• aurora-2

• rds-1

• rds-2

• rds-3

• rds-4

• rds-5

RDSで自動バックアップを有効にしていつものについては作成時にスナップショットが取得されるようですね。

AWS Backupのバックアッププランの作成

次に、AWS Backupでバックアッププランの作成をします。バックアップボールトは事前に作成しておきました。

まずは、継続的なバックアップを有効化するnon-97-test-plan-1というバックアッププランを作成します。

リソースの割り当てをします。(rds-3の選択が漏れており、代わりにrds-5を選択してしまっていますが、後述にて後日修正します)

継続的なバックアップを有効化するnon-97-test-plan-2というバックアッププランも作成します。

リソースの割り当ては以下のとおりです。

バックアッププラン作成後、Aurora DBクラスターとRDS DBインスタンスの状態を確認しましたが、いずれもバックアップ設定は変更できそうでした。(特に変化はなかったので画像は省略します)

6/9 6:00前

翌日、少し早起きして各バックアッププランのジョブ実行状態を確認します。

現在の時刻は6/9 6:00前です。

まずは継続的バックアップを有効化しているバックアッププランです。

それぞれのリソースに対して毎時でバックアップが行われているようです。6:00前にも関わらず、3:00のバックアップジョブのステータスが作成済みとなっているのは次の時間以内に開始で8時間を設定していたためだと考えます。次の時間以内に開始で設定した時間内の任意のタイミングでバックアップが行われます。詳細は以下記事をご覧ください。

次に継続的バックアップを無効しているバックアッププランです。

こちらも問題なく毎時でバックアップが行われているようです。

RDSのコンソールから各リソースの状態を確認します。

• aurora-1

• aurora-2

• rds-1

• rds-2

• rds-3

• rds-4

• rds-5 rds-5と全く同じであるため割愛

継続的バックアップが有効なリソースについては、バックアップジョブが動作しているにも関わらず新規にスナップショットが取得されていないことが分かります。

また、このインスタンスには AWS Backup のバックアッププランがあります。これを表示および管理するには、AWS Backup のバックアッププランページ を参照してください。とバックアップウィンドウや保持期間など自動バックアップの設定を表示されなくなっていました。

また、変更することもできなくなっていました。

継続的バックアップが有効でないaurora-1については、問題なくバックアップウィンドウの変更ができました。

ここは先述のドキュメントのとおりですね。

バックアップスケジュール： AWS Backup プランが Amazon RDS スナップショットと継続的バックアップの両方を作成する場合、競合を防ぐために、Amazon RDS メンテナンスウィンドウを調整するバックアップウィンドウを AWS Backup インテリジェントにスケジュールします。競合をさらに防ぐために、Amazon RDS 自動バックアップウィンドウを手動で設定することはできません。RDS は、バックアッププランに 1 日 1 回以外のスナップショットバックアップの頻度が設定されているかどうかに関係なく、1 日に 1 回スナップショットを作成します。

設定： Amazon RDS インスタンスに AWS Backup 継続的バックアップルールを適用した後、Amazon RDS でそのインスタンスに継続的バックアップ設定を作成または変更することはできません。変更は、 AWS Backup コンソールまたは AWS Backup CLI を使用して行う必要があります。

継続的なバックアップと point-in-time 復元 (PITR) - AWS Backup

ちなみにスナップショットが存在しないaurora-2についてもPITRは現時点でもできそうでした。

継続的バックアップが無効なリソースについては、毎時でスナップショットが取得されていることが分かります。また、自動バックアップウィンドウの設定も表示されていますね。

このタイミングで、rds-3が継続的バックアップのバックアッププランの対象から選択し忘れていることに気づいたので追加しました。

6/9 6:00過ぎ

6/9 6:00を過ぎたところです。

継続的バックアップが有効なバックアッププランのジョブを確認します。

rds-3のバックアップジョブが走っていますね。

試しにrds-4に対するバックアップジョブAEE091B4-AAEA-C28F-0584-19FF363453EDを確認します。

復旧ポイントのARNからしてスナップショットではなく、継続的バックアップのようです。

ARNのリンクを辿ると、確かに継続的バックアップのようです。また、継続的バックアップ自体の作成日時は変わりありませんが、有効期限はバックアップジョブの完了日時から保持期間である35日加算したものでした。内部的には正しく処理されていそうです。

aurora-2のバックアップジョブ_481B058A-1415-958D-12C7-2D2CD28AA6C6で取得されたものについても、同様のことが言えました。

しばらくすると、rds-3のバックアップジョブが完了しました。

RDSのコンソールを確認してみるとバックアップの変更ができなくなっていました。設定変更できなくなるタイミングはAWS Backupの初回バックアップ後のようです。

6/9 9:25 ごろ

現在の時刻は6/9 9:25 ごろです。

aurora-2を除く、自動バックアップのバックアップウィンドウを9:00 - 9:30で設定していたので、RDSのコンソールからスナップショットの取得状況を確認します。

• aurora-1

• aurora-2

• rds-1

• rds-2

• rds-3

• rds-4

• rds-5

継続的バックアップが無効で、自動バックアップを設定しているものについては指定したバックアップウィンドウでスナップショットが取得されていることが分かります。排他的ではなく、お互い独立して動作するようです。

rds-5を毎時で継続的バックアップをクロスリージョンコピーするように設定

rds-5を毎時で継続的バックアップをクロスリージョンコピーするように設定します。

継続的バックアップのコピーはどのような挙動をするのでしょうか。AWS公式ドキュメントを確認します。

Amazon RDS の継続的バックアップのコピー：

増分スナップショットコピージョブは、フルスナップショットコピージョブよりも速く処理されます。新しいコピージョブが完了するまで以前のスナップショットコピーを保持しておくと、コピージョブの所要時間の短縮になる可能性があります。RDS データベースインスタンスからスナップショットをコピーする場合、以前のコピーを先に削除すると、(増分スナップショットコピーではなく) フルスナップショットコピーが作成されることに注意してください。コピーの最適化に関する詳細については、「Amazon RDS ユーザーガイド」の「増分スナップショットコピー」を参照してください。

Amazon RDS の継続的バックアップのコピーの作成 — Amazon RDS ではトランザクションログのコピーが許可されないため、 AWS Backup Amazon RDS の継続的バックアップのコピーを作成することはできません。代わりに、 はスナップショット AWS Backup を作成し、バックアッププランで指定された頻度でスナップショットをコピーします。

継続的なバックアップと point-in-time 復元 (PITR) - AWS Backup

直接的に継続的バックアップをコピーすることはできないようですが、代わりに指定した間隔でスナップショットを取得するようです。

rds-5のスナップショットをクロスリージョンコピーするにあたって、一旦non-97-test-plan-1のリソース割り当てを削除します。

保護されたリソースを確認して、リソース割り当てを解除しただけでは保護されたリソース外にならないことを確認します、

non-97-test-plan-1にて、aurora-2とrds-4のみをリソース割り当てをします。

現時刻は13:30です。4時間近く待ちましたが、rds-5のバックアップは現在もAWS Backupで管理されていると判定され、自動バックアップ設定の表示がされていません。

rds-5の継続的バックアップを確認した上で、継続的バックアップを削除します。

復旧ポイントの関連付けを解除します。

復旧ポイントの関連付け解除後、保護されたリソースにrds-5が含まれなくなったことを確認します。

このタイミングでrds-5を確認すると、自動バックアップ設定を確認できるようになっていました。

5分ほど待つと、最も遅い復元可能な時刻が13:34から13:39に変わりました。もともと自動バックアップを有効にしていたので、裏側では継続してトランザクションログを継続的にバックアップしているようです。

それでは継続的バックアップを有効 かつ 毎時スナップショットをクロスリージョコピーするバックアッププランnon-97-test-plan-3を作成します。バックアップボールとは東京リージョンのものを指定しました。

リソースの割り当てはrds-5です。

6/9 16:30 ごろ

設定して3時間ほど経過しました。

継続的バックアップを有効 かつ 毎時スナップショットをクロスリージョンコピーするバックアッププランnon-97-test-plan-3のバックアップジョブを確認します。

問題なく動作していそうですね。

バックアップボールトを確認すると、rds-5の継続的バックアップが行われていることが分かります。

保護されたリソースからrds-5を確認します。復旧ポイントに継続的バックアップとスナップショットが新規に取得されていることが分かります。

東京リージョンのバックアップボールトにもスナップショットがありました。問題なくクロスリージョンコピーできていますね。

RDSコンソールから確認したrds-5は以下のとおりです。また自動バックアップ設定が表示されなくなっていました。

6/9 21:30 ごろ

5時間ほど待ってみました。

東京リージョンのバックアップボールトを確認すると、1時間ごとにスナップショットが転送されていることが分かります。

保護されたリソースからrds-5の状態を確認すると、5時間前に見た復旧ポイントIDのものがなくなり、別のスナップショットが取得されていました。

直近完了したAWS Backupのコピージョブを確認します。

送信元復旧ポイントARNのリンクをクリックすると、Cannnot find recovery pointと復旧ポイントが削除されていました。

送信先復旧ポイントARNのリンクについてはクリックすると、東京リージョンに転送したスナップショットのコピーを確認できました。

もしかすると、コピーが完了したタイミングで送信元のスナップショットを削除しているのでしょうか。

CloudTrailを確認すると、確かにスナップショットのコピーが完了して5分後に送信元スナップショットを削除しています。

• CreateDBSnapshot

  2024-06-09T11:31:30Z CreateDBSnapshot

  {
      "eventVersion": "1.08",
      "userIdentity": {
          "type": "AssumedRole",
          "principalId": "AROA6KUFAVPU5WGEA46WE:AWSBackup-AWSBackupDefaultServiceRole",
          "arn": "arn:aws:sts::<AWSアカウントID>:assumed-role/AWSBackupDefaultServiceRole/AWSBackup-AWSBackupDefaultServiceRole",
          "accountId": "<AWSアカウントID>",
          "accessKeyId": "ASIA6KUFAVPUQGWP5MVU",
          "sessionContext": {
              "sessionIssuer": {
                  "type": "Role",
                  "principalId": "AROA6KUFAVPU5WGEA46WE",
                  "arn": "arn:aws:iam::<AWSアカウントID>:role/service-role/AWSBackupDefaultServiceRole",
                  "accountId": "<AWSアカウントID>",
                  "userName": "AWSBackupDefaultServiceRole"
              },
              "webIdFederationData": {},
              "attributes": {
                  "creationDate": "2024-06-09T11:31:29Z",
                  "mfaAuthenticated": "false"
              }
          },
          "invokedBy": "backup.amazonaws.com"
      },
      "eventTime": "2024-06-09T11:31:30Z",
      "eventSource": "rds.amazonaws.com",
      "eventName": "CreateDBSnapshot",
      "awsRegion": "us-east-1",
      "sourceIPAddress": "backup.amazonaws.com",
      "userAgent": "backup.amazonaws.com",
      "requestParameters": {
          "dBInstanceIdentifier": "rds-5",
          "dBSnapshotIdentifier": "awsbackup:job-4D71132E-1DDF-1BC4-68E8-120E2A98CD36"
      },
      "responseElements": {
          "allocatedStorage": 20,
          "instanceCreateTime": "Jun 8, 2024 11:38:29 AM",
          "dBSnapshotIdentifier": "awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "dbiResourceId": "db-OB3ZY4AEB4S6EHECUCNWA3YW4Y",
          "port": 5432,
          "availabilityZone": "us-east-1a",
          "dBSnapshotArn": "arn:aws:rds:us-east-1:<AWSアカウントID>:snapshot:awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "kmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/4544a543-32d6-4103-a1df-313116669a3e",
          "processorFeatures": [],
          "encrypted": true,
          "percentProgress": 0,
          "optionGroupName": "default:postgres-16",
          "tagList": [],
          "iops": 3000,
          "dBInstanceIdentifier": "rds-5",
          "storageType": "gp3",
          "iAMDatabaseAuthenticationEnabled": false,
          "vpcId": "vpc-0e0796981cea634c1",
          "storageThroughput": 125,
          "dedicatedLogVolume": false,
          "status": "creating",
          "masterUsername": "postgres",
          "engine": "postgres",
          "snapshotType": "awsbackup",
          "engineVersion": "16.2",
          "licenseModel": "postgresql-license",
          "snapshotTarget": "region"
      },
      "requestID": "3c1c8255-3acf-4307-8019-f819dee633bb",
      "eventID": "d3c99f3d-259c-465a-9f08-7671ecfb3864",
      "readOnly": false,
      "eventType": "AwsApiCall",
      "managementEvent": true,
      "recipientAccountId": "<AWSアカウントID>",
      "eventCategory": "Management"
  }

• CopyDBSnapshot

  2024-06-09T11:49:42Z CopyDBSnapshot

  {
      "eventVersion": "1.08",
      "userIdentity": {
          "type": "AssumedRole",
          "principalId": "AROA6KUFAVPU5WGEA46WE:AWSBackup-AWSBackupDefaultServiceRole",
          "arn": "arn:aws:sts::<AWSアカウントID>:assumed-role/AWSBackupDefaultServiceRole/AWSBackup-AWSBackupDefaultServiceRole",
          "accountId": "<AWSアカウントID>",
          "accessKeyId": "ASIA6KUFAVPU72GQYIQB",
          "sessionContext": {
              "sessionIssuer": {
                  "type": "Role",
                  "principalId": "AROA6KUFAVPU5WGEA46WE",
                  "arn": "arn:aws:iam::<AWSアカウントID>:role/service-role/AWSBackupDefaultServiceRole",
                  "accountId": "<AWSアカウントID>",
                  "userName": "AWSBackupDefaultServiceRole"
              },
              "webIdFederationData": {},
              "attributes": {
                  "creationDate": "2024-06-09T11:49:37Z",
                  "mfaAuthenticated": "false"
              }
          },
          "invokedBy": "backup.amazonaws.com"
      },
      "eventTime": "2024-06-09T11:49:42Z",
      "eventSource": "rds.amazonaws.com",
      "eventName": "CopyDBSnapshot",
      "awsRegion": "ap-northeast-1",
      "sourceIPAddress": "backup.amazonaws.com",
      "userAgent": "backup.amazonaws.com",
      "requestParameters": {
          "kmsKeyId": "arn:aws:kms:ap-northeast-1:<AWSアカウントID>:key/3087f441-64c9-4746-9ddc-b3674de77267",
          "preSignedUrl": "HIDDEN_DUE_TO_SECURITY_REASONS",
          "targetDBSnapshotIdentifier": "awsbackup:copyjob-D933160F-1632-9918-3AEC-A7DC2F8C6E56",
          "sourceDBSnapshotIdentifier": "arn:aws:rds:us-east-1:<AWSアカウントID>:snapshot:awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "copyOptionGroup": false
      },
      "responseElements": {
          "allocatedStorage": 20,
          "instanceCreateTime": "Jun 8, 2024 11:38:29 AM",
          "dBSnapshotIdentifier": "awsbackup:copyjob-d933160f-1632-9918-3aec-a7dc2f8c6e56",
          "port": 5432,
          "sourceRegion": "us-east-1",
          "dBSnapshotArn": "arn:aws:rds:ap-northeast-1:<AWSアカウントID>:snapshot:awsbackup:copyjob-d933160f-1632-9918-3aec-a7dc2f8c6e56",
          "kmsKeyId": "arn:aws:kms:ap-northeast-1:<AWSアカウントID>:key/3087f441-64c9-4746-9ddc-b3674de77267",
          "processorFeatures": [],
          "encrypted": true,
          "percentProgress": 0,
          "tagList": [],
          "iops": 3000,
          "dBInstanceIdentifier": "rds-5",
          "storageType": "gp3",
          "iAMDatabaseAuthenticationEnabled": false,
          "storageThroughput": 125,
          "dedicatedLogVolume": false,
          "status": "pending",
          "masterUsername": "postgres",
          "sourceDBSnapshotIdentifier": "arn:aws:rds:us-east-1:<AWSアカウントID>:snapshot:awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "engine": "postgres",
          "snapshotType": "awsbackup",
          "engineVersion": "16.2",
          "licenseModel": "postgresql-license",
          "originalSnapshotCreateTime": "Jun 9, 2024 11:32:04 AM",
          "snapshotTarget": "region"
      },
      "requestID": "e992172b-425a-4ec9-ba87-3ded94889048",
      "eventID": "a16707a9-5efb-4e3f-84af-ebf7c5fdf63d",
      "readOnly": false,
      "eventType": "AwsApiCall",
      "managementEvent": true,
      "recipientAccountId": "<AWSアカウントID>",
      "eventCategory": "Management"
  }

• DeleteDBSnapshot

  2024-06-09T12:09:46Z DeleteDBSnapshot

  {
      "eventVersion": "1.08",
      "userIdentity": {
          "type": "AssumedRole",
          "principalId": "AROA6KUFAVPU5WGEA46WE:AWSBackup-AWSBackupDefaultServiceRole",
          "arn": "arn:aws:sts::<AWSアカウントID>:assumed-role/AWSBackupDefaultServiceRole/AWSBackup-AWSBackupDefaultServiceRole",
          "accountId": "<AWSアカウントID>",
          "accessKeyId": "ASIA6KUFAVPUS6GHAQHO",
          "sessionContext": {
              "sessionIssuer": {
                  "type": "Role",
                  "principalId": "AROA6KUFAVPU5WGEA46WE",
                  "arn": "arn:aws:iam::<AWSアカウントID>:role/service-role/AWSBackupDefaultServiceRole",
                  "accountId": "<AWSアカウントID>",
                  "userName": "AWSBackupDefaultServiceRole"
              },
              "webIdFederationData": {},
              "attributes": {
                  "creationDate": "2024-06-09T12:09:46Z",
                  "mfaAuthenticated": "false"
              }
          },
          "invokedBy": "backup.amazonaws.com"
      },
      "eventTime": "2024-06-09T12:09:46Z",
      "eventSource": "rds.amazonaws.com",
      "eventName": "DeleteDBSnapshot",
      "awsRegion": "us-east-1",
      "sourceIPAddress": "backup.amazonaws.com",
      "userAgent": "backup.amazonaws.com",
      "requestParameters": {
          "dBSnapshotIdentifier": "awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36"
      },
      "responseElements": {
          "dBSnapshotIdentifier": "awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "dBInstanceIdentifier": "rds-5",
          "snapshotCreateTime": "Jun 9, 2024 11:32:04 AM",
          "engine": "postgres",
          "allocatedStorage": 20,
          "status": "deleted",
          "port": 5432,
          "availabilityZone": "us-east-1a",
          "vpcId": "vpc-0e0796981cea634c1",
          "instanceCreateTime": "Jun 8, 2024 11:38:29 AM",
          "masterUsername": "postgres",
          "engineVersion": "16.2",
          "licenseModel": "postgresql-license",
          "snapshotType": "awsbackup",
          "iops": 3000,
          "storageThroughput": 125,
          "optionGroupName": "default:postgres-16",
          "percentProgress": 100,
          "storageType": "gp3",
          "encrypted": true,
          "kmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/4544a543-32d6-4103-a1df-313116669a3e",
          "dBSnapshotArn": "arn:aws:rds:us-east-1:<AWSアカウントID>:snapshot:awsbackup:job-4d71132e-1ddf-1bc4-68e8-120e2a98cd36",
          "iAMDatabaseAuthenticationEnabled": false,
          "processorFeatures": [],
          "dbiResourceId": "db-OB3ZY4AEB4S6EHECUCNWA3YW4Y",
          "tagList": [],
          "snapshotTarget": "region",
          "originalSnapshotCreateTime": "Jun 9, 2024 11:32:04 AM",
          "dedicatedLogVolume": false
      },
      "requestID": "231465c9-f017-40fd-979e-a1abddcfa3e8",
      "eventID": "01596fca-33fd-4987-8958-bdd73dd1a19d",
      "readOnly": false,
      "eventType": "AwsApiCall",
      "managementEvent": true,
      "recipientAccountId": "<AWSアカウントID>",
      "eventCategory": "Management"
  }

ここで気になるのはこのスナップショットのコピーが増分コピーなのかです。

直接コピーされたスナップショットが増分なのかを表すプロパティはありません。(Cost Explorerでリソースあたりの転送量を見ることができれば可能かもしれません)

AWS公式ドキュメントには増分スナップショットコピーとクロスリージョンスナップショットコピーについて以下の記述がありました。

増分スナップショットコピー

差分スナップショットには、同じ DB インスタンスの最新のスナップショット以降に変更されたデータのみが含まれます。差分スナップショットのコピーは高速であり、フルスナップショットコピーよりストレージコストが低くなります。

スナップショットコピーが増分かどうかは、最近完了したスナップショットコピーとソーススナップショットによって決定されます。最近のスナップショットコピーが削除され、次のコピーがフルコピーである場合、増分コピーではありません。スナップショットコピーは、ソーススナップショットと同じタイプになります。ソーススナップショットが差分スナップショットの場合、スナップショットのコピーは差分スナップショットになります。

. . (中略) . .

フルコピーと増分コピー

コピー元スナップショットとは異なる AWS リージョン にスナップショットをコピーする場合、初期のコピーでは、増分スナップショットをコピーした場合でもフルスナップショットコピーになります。フルスナップショットコピーには、DB インスタンスを復元するために必要なデータやメタデータすべてが含まれます。最初のスナップショットコピーの後、同じ DB インスタンスの増分スナップショットを同じ AWS アカウント 内の同じデスティネーションリージョンにコピーできます。増分スナップショットの詳細については、「増分スナップショットコピー」を参照してください。

AWS リージョン 間での増分スナップショットコピーは、暗号化されていないスナップショットと暗号化されたスナップショットの両方がサポートされています。

別の AWS リージョン にスナップショットをコピーする場合、次の条件に合致すればコピーは増分となります。

• スナップショットが以前、コピー先のリージョンにコピーされたことがある。
• 最近のスナップショットコピーがコピー先のリージョンにまだ存在する。
• 送信先リージョンのスナップショットのコピーがすべて、暗号化されていないか、あるいは同じ KMS キーを使って暗号化されていた。

DB スナップショットのコピー - Amazon Relational Database Service

ポイントは「スナップショットコピーは、ソーススナップショットと同じタイプになります」という文言です。

結論、どこからの増分になるかは不明です。

今までの検証から以下のような挙動を確認しています。

• スナップショットをコピーした後、送信元スナップショットは削除される
• 継続的バックアップを有効化することによって日次でスナップショットが取得される
• 継続的バックアップを有効化することによって取得される日次でスナップショット自体はコピーされない

以下の図のとおり、共通のベースラインとなるスナップショットは存在しません。そのため、増分が最新の日次スナップショットからなのか、直近削除されたスナップショットからなのかはドキュメントからは読み取れませんでした。

なお、Auroraは差分スナップショットコピーをサポートしていません。常にフルコピーです。ただし、データ転送料金的には増分のようです。

If you use AWS Backup for cross-Region snapshot copying, while the copies are full copies, the data transfer charges are incremental.

Copying a DB cluster snapshot - Amazon Aurora

6/10 21:45 ごろ

現在の時刻は6/10 21:45 ごろです。

継続的バックアップを有効にしているリソースたちのバックアップ状況を確認してみましょう。

• aurora-2

• rds-3

• rds-4

• rds-5

いずれもAM 7:00ごろに日次のスナップショットが取得されていることが分かります。日次のスナップショットの名前はrds:DBインスタンス識別子-YYYY-MM-DD-HH-MMのようです。バックアップジョブIDではないので目立ちます。

6/11 16:40 ごろ

現在の時刻は6/11 16:40 ごろです。

継続的バックアップを有効にしているリソースたちのバックアップ状況を確認してみましょう。

• aurora-2

• rds-3

• rds-4

• rds-5

本日もいずれもAM 7:00ごろに日次のスナップショットが取得されていることが分かります。

このAM 7:00というのはどういった決まり方をしているのでしょうか。

以下AWS公式ドキュメントから、メンテナンスウィンドウの時間が怪しいです。

バックアップスケジュール： AWS Backup プランが Amazon RDS スナップショットと継続的バックアップの両方を作成する場合、競合を防ぐために、Amazon RDS メンテナンスウィンドウを調整するバックアップウィンドウを AWS Backup インテリジェントにスケジュールします。

継続的なバックアップと point-in-time 復元 (PITR) - AWS Backup

確かにいずれのリソースもメンテナンスウィンドウは日曜日の0:00 - 0:30 UTC(日曜日 9:00 - 9:30 JST)で設定しています。

日本時間でAM 7:00に動作しているので、メンテナンスウィンドウの2時間前にバックアップを開始しているようです。

メンテナンスウィンドウを変更してみて、日次のバックアップ取得時間にどのような影響があるのか確認してみます。

まず、rds-3のメンテナンスウィンドウをsun:00:00-sun:00:30からsat:22:20-sun:22:50と100分早めてみます。

DBインスタンスの変更をクリックするとThe backup window and maintenance window must not overlap.とエラーになってしまいました。メンテナンスウィンドウが現在のバックアップウィンドウと重複しているようですね。

メンテナンスウィンドウをsat:21:30-sat:22:00にしてみると、今度は受け付けられました。2時間以上間隔を開ければ良いのでしょうか。

RDSとAuroraでメンテナンスウィンドウを色々な時間帯で設定してみました。RDSとAuroraにて各パターンごとに実際に設定が受けつけられたかは以下のとおりです。

メンテナンスウィンドウの終了が2時間以上前の場合は受け付けられており、2時間以内前の場合は拒否されていることから、バックアップウィンドウは22:00-00:00で設定されていることが判断できます。

rds-3では、sat:21:30-sat:22:00をメンテナンスウィンドウに設定したため次回の日次バックアップはAM 7:00の2時間半前であるAM 4:30ごろに取得されると予想します。

他のRDS DBインスタンスのメンテナンスウィンドウも変更して、バックアップ取得時刻への影響を確認します。

• rds-4 : sun:00:30-sun:01:00

• rds-5 : sun:21:00-sun:21:30

6/12 6:00 ごろ

現在の時刻は6/12 6:00 ごろです。

メンテナンスウィンドウを変更したリソースの日次スナップショットの取得時刻を確認しましょう。

• rds-3 : 4:37取得 (メンテナンスウィンドウsat:21:30-sat:22:00)

• rds-4 : 6:00時点で未取得 sun:00:30-sun:01:00

• rds-5 : 4:13取得 sun:21:00-sun:21:30

メンテナンスウィンドウの開始2時間前ごろに日次スナップショットが取得されていることが分かります。

Multi-AZのSQL ServerのRDS DBインスタンスおよび、Single-AZのRDS DBインスタンスについてはスナップショット取得時にIOが一部停止されます。「メンテナンスウィンドウの2時間前はまだ処理が走っている」という場合は、注意しましょう。

Amazon RDS は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。Single-AZ DB インスタンスでこの DB スナップショットを作成すると、I/O が短時間中断します。この時間は、DB インスタンスのサイズやクラスによって異なり、数秒から数分になります。MariaDB、MySQL、Oracle、PostgreSQL の場合、バックアップはスタンバイから取得されるため、マルチ AZ 配置のバックアップ中プライマリで I/O アクティビティは中断しません。SQL Server の場合、マルチ AZ 配置のバックアップ中 I/O アクティビティが一時中断します。

シングル AZ DB インスタンスの DB スナップショットの作成 - Amazon Relational Database Service

RDS、Auroraのバックアップ周りは以下資料のP.40 - P.44が分かりやすいです。

ちなみにFSxはメンテナンスウィンドウおよび自動バックアップウィンドウの4時間前以内にバックアップを取得しようとすると失敗するようです。

一般に、 AWS データベースサービスはメンテナンスウィンドウの 1 時間前または期間中にバックアップを開始することはできません。また、Amazon FSx はメンテナンスウィンドウまたは自動バックアップウィンドウの 4 時間前または期間中にバックアップを開始できません (Amazon Aurora はこのメンテナンスウィンドウ制限の対象外です）。その間にスケジュールされたスナップショットバックアップは失敗します。

バックアッププランの作成 - AWS Backup

継続的バックアップが有効なリソースを削除する際に自動バックアップを削除することができるか

継続的バックアップが有効なRDS DBインスタンスやAurora DBクラスターを削除する際に自動バックアップを削除することができるかを確認します。

勢い余って自動バックアップを削除できてしまうのであれば、PITRでリストアすることができなくなってしまいます。実際に削除しようとしてみます。

まずはRDS DBインスタンスです。

自動バックアップを保持のチェックを外して、私は、インスタンスの削除後、システムスナップショットとポイントインタイムの復元を含む自動バックアップが利用不可となることを了承します。をチェックします。

この状態で削除しようとしたところ、Your RDS instance DBインスタンス識別子 is associated with an AWS Backup resource with id 継続的バックアップのARN. NoDeleteAutomatedBackups must be specified. For more details, see the AWS Backup documentation.とAWS Backupで継続的バックアップを管理していると弾かれました。これは安心ですね。

自動バックアップを保持にチェックを入れて、RDS DBインスタンスを削除します。

Aurora DBクラスターも削除します。

まず、Aurora DBインスタンスを削除します。

Aurora DBインスタンス完了後、Aurora DBクラスターを削除します。

自動バックアップを削除しようとしたところ、RDS cluster Aurora DBクラスター識別子 is associated with the following AwsBackupRecoveryPointArn: 継続的バックアップのARN. NoDeleteAutomatedBackups must be specified. For more details, see the AWS Backup documentation.と、こちらもエラーになりました。

自動バックアップを保持にチェックを入れて、Aurora DBクラスターを削除します。

削除が完了すると、自動バックアップの一覧から削除したRDS DBインスタンスとAurora DBクラスターが消えていました。

代わりに保持タブから削除したRDS DBインスタンスとAurora DBクラスターとを確認できました。

Aurora DBクラスターの自動バックアップは以下のとおりです。AWS Backupで管理されていることが分かります。

PITRも問題なくできそうです。

RDS DBインスタンスの自動バックアップは以下のとおりです。こちらはAWS Backupで管理されているこは明記されていないですね。

バックアップウィンドウを完全にコントロールしたい場合や日次以外の間隔でスナップショットを取得したい場合などを除いて、AWS Backupで継続的バックアップを有効化した方が良いかもしれない

AWS Backupで継続的バックアップを有効化したときのRDSとAuroraのバックアップの挙動を確認してみました。

少しクセはありますが、基本的にAWS Backupで継続的バックアップを有効化した方が管理面でメリットがあると感じました。

具体的には以下のシチュエーションに当てはまる場合は、積極的に継続的バックアップを有効化すると良いでしょう。

• バックアップを一元的に管理したい
• バックアップボールトや監査ログといったAWS Backupの機能を使用したい
• RDS DBインスタンスやAurora DBクラスターを削除する際に併せて自動バックアップが削除されないようにしたい

AWS Backupの全体像は以下記事をご覧ください。

一方で、以下に当てはまる場合はAWS Backupでは継続的バックアップを無効にして、RDSで自動バックアップを有効化することによって管理すると良いのではと考えます。

• バックアップウィンドウを明示的に指定したい
• 毎時など日次以外の間隔でスナップショットを取得したい
• 確実に増分コピーを行いたい
• 90日以上スナップショットを保持しておきたい (継続的バックアップが有効な場合の保持期間の最大は35日)

「90日以上スナップショットを保持しておきたい」という要件だけであれば、継続的バックアップを有効にしたものと、無効にしたものの2つのバックアッププランを適用するという形もアリだと考えます。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!