AWS BackupはS3のバージョニング構造ごと復元するか

目次
こんにちは、酒井です。この記事では AWS BackupでS3オブジェクトを復元する際の振る舞いを細かく検証します。
突然ですが、AWSサービスをプロダクトに利用する前に、自分の意図通りに動作するか検証することは大事ですよね。思い込みに基づいて設計してしまうと、後で手戻りが起こりかねません。
私の場合、AWS Backupに対してとある疑問があり、検証して確認したところ、自分の意図(というか思い込み?)と異なる仕様に気づくことができました。この記事では、その際に気付いたAWS Backupの仕様を紹介します。
疑問:AWS BackupはS3オブジェクトのバージョニング構造ごと復元するのか
以前、AWS Backupの動作を色々試していたのですが、その際にふと「AWS BackupはS3オブジェクトのバージョニング構造ごと復元するのか」という疑問が浮かびました。
たとえば、次の画像を例に挙げます。この画像では、testfile.txt
のバージョニングの構造は、最終更新時刻が「2023/03/17 05:51:59 PM JST」、「2023/03/17 02:52:01 PM JST」、「2023/03/17 01:49:09 PM JST」の3つのバージョンから成り立っています。今回の疑問は、このS3バケットをAWS Backupでバックアップした際に「このバージョニングの構造ごと復元できるか」を問うものです。

結論:しません。最新バージョンだけを復元します。
結論から述べますと、AWS Backupは、指定した時点の最新バージョンのオブジェクトだけを復元し、バージョニング構造ごと復元することはありません。
上の画像の例で説明しますと、復元時刻「2023/03/17 06:00:00 PM JST」を指定して、3バージョンをすべて含んだバージョニング構造を復元しようと試みると、AWS Backupは「2023/03/17 05:51:59 PM JST」のバージョンだけを復元します。

実は、この仕様はドキュメントに書いてあるものなので、隠れ仕様でもなんでもないのですが、どうも私の意図と異なっており、納得がいかなかったので、実際に動作を確認してみました。
AWS Backup はすべてのバージョンをバックアップしますが、復元する時点の最新のバージョンのみをバージョンスタックから復元します。(翻訳)
https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-s3.html
検証:AWS Backupの復元を動作確認
構成

- Vault:AWS BackupがS3オブジェクトをバックアップする論理的な保管庫。
- ソースS3バケット:今回バックアップしたい目的のS3バケット。
- ターゲットS3バケット:復元先のS3バケット。
検証方法
S3やAWS Backupを準備した後、復元の動作を検証していきます。 S3やAWS Backupの準備について説明すると、ソースS3バケットを作成して、AWS BackupでソースS3バケットのバックアップを設定し、下図のようにオブジェクトへの変更を加えます。この際に、ソースS3バケットのバージョニングを有効化するので、バージョニング構造が積みあがっていきます。

本題とずれますが、削除マーカーは「オブジェクトを削除しました」という目印で、ユーザがS3のバージョニングを有効化して、オブジェクトを削除すると、S3はオブジェクトを物理的に削除する代わりに、削除マーカーをPUTして、論理的に削除を表現します。
本題に戻りますが、検証のパターンは4通りです。具体的には、復元時に時点t1~t4をそれぞれ指定して復元し、復元した後のターゲットS3バケットの状態を確認します。
AWS Backupの設定方法
AWS Backupの設定方法については、ここでは割愛します。こちらの記事がわかりやすく、参考にさせていただきました。
ただし、今回は任意の時点に復元したかったので、ポイントインタイムリカバリ(PITR)を有効にしました。こうすることで、 復元時に時点t1~t4をそれぞれ指定して復元することができます。

検証結果
復元時に時点t1~t4をそれぞれ指定して復元していきました。時点t1~t4について、それぞれ結果を示します。結論を述べると、いずれの場合も、最新のバージョンを1つだけ復元します。(そもそも1つもバージョンが無いt1は例外)
t1(初期状態)に復元した場合
意図通りの動作です。指定した時点t1には何もオブジェクトはありませんから、当然、AWS Backupは何も復元しませんね。

t2(Version 1が最新)に復元した場合
これも意図通りの動作です。指定した時点t2には、ソースS3バケットはVersion1だけを保持していたため、当然、AWS BackupはVersion 1を復元しました。

t3(Version 2が最新)に復元した場合
これが意図と異なる動作です!指定した時点には、ソースS3バケットは最新のVersion1と、古いVersion2を保持していますが、AWS BackupはVersion 2だけを復元しました。
今回のポイントである「最新バージョンだけを復元する」仕様が表れていますね。私の感覚では、Version 1も2も復元してほしいのですが、皆さんの感覚ではこの動作はどう思われますでしょうか。

t4(削除マーカーが最新)に復元した場合
これも意図と異なる動作です。 指定した時点には、ソースS3バケットは最新の削除マーカーと、古いVersion1とVersion2を保持していますが、AWS Backupは削除マーカーだけを復元しました。
ここでも、今回のポイントである「最新バージョンだけを復元する」仕様が表れていますね。ただ、私の感覚では削除マーカーだけ復元するのは奇妙に思えます。

まとめ
Q. AWS BackupはS3オブジェクトのバージョニング構造ごと復元するのか。
A. 指定した時点の最新バージョンだけを復元し、過去のバージョンを含んだバージョニング構造は復元しません。(削除マーカーでも例外ではない)
勘違いしたままプロダクトに利用しなくてよかったです。