はじめに
財務チームのレポートのキーに下書きをアップロードすると、読者が見る承認済みの内容が置き換わってしまいます。バージョニングを有効にし、その間違いを再現して、承認済みの内容を復元します。復元を確認した後、練習用の履歴を削除します。
最初に キーとメタデータで文書を整理する を完了し、オブジェクトキー、プロパティ、ダウンロード、削除について学んでください。この新しい VM には、CLI 接続と承認済みファイル、下書きファイルが提供されます。バケットは自分で作成します。コマンドには Terminal を使い、隣の AWS View タブで現在のオブジェクトと履歴を比較します。
認定試験との関連
このラボでは、次の試験トピックに関連する実践的な演習を行います。
- Solutions Architect – Associate (SAA-C03) · タスク 1.3: S3 のバージョン履歴、削除マーカー、データ復旧。
- Developer – Associate (DVA-C02) · タスク 1.3: S3 のバージョン履歴、削除マーカー、データ復旧。
- CloudOps Engineer – Associate (SOA-C03) · タスク 2.3: S3 のバージョン履歴、削除マーカー、データ復旧。
- Security – Specialty (SCS-C03) · タスク 5.2: 基礎演習：S3 のバージョン履歴、削除マーカー、データ復旧。
- Data Engineer – Associate (DEA-C01) · タスク 2.3: 基礎演習：S3 のバージョン履歴、削除マーカー、データ復旧。
公開前にバージョニングを有効にする
このステップでは、空のバケットを作成し、レポートをアップロードする前にバージョニングを有効にします。
cd（ディレクトリを変更する）で作業ディレクトリに移動します。
cd /home/labex/project
mb（make bucket）でレポート用バケットを作成します。
aws s3 mb s3://labex-report-history
make_bucket: labex-report-history が表示されるはずです。バージョニングはバケットの設定です。有効にすると、それ以降のキーへの書き込みは、以前の保存内容を破棄する代わりにバージョン ID を作成します。誤った上書きから復元するのに役立ちますが、特定のバージョンを明示的に削除する操作を防ぐものではありません。
aws s3api は個々の S3 API 操作を提供します。put-bucket-versioning はこの設定を更新します。--bucket は格納先を識別し、--versioning-configuration Status=Enabled は有効な状態を指定します。
aws s3api put-bucket-versioning --bucket labex-report-history --versioning-configuration Status=Enabled
更新が成功しても本文は表示されません。出力がないことだけに頼らず、設定を読み取ります。
aws s3api get-bucket-versioning --bucket labex-report-history
{
"Status": "Enabled"
}
AWS View はバケットに Versioning: Enabled を表示します。バケットはまだ空です。バージョニングを有効にしても、レポートのアップロードや過去のバージョンの作成は行われません。保護したいデータを書き込む前に、この設定を有効にしてください。
元のバージョンと上書きされたバージョンを作成する
このステップでは、承認済みレポートを公開した後、現在の内容を下書きで上書きし、元の内容を履歴に残します。
内容を表示する cat で、準備済みのファイルを確認します。
cat report-approved.txt
Monthly revenue: 42000
cat report-draft.txt
Monthly revenue: 00000
承認済みファイルをキー report.txt に公開します。コピー元のファイル名とオブジェクトキーは、異なっていても構いません。
aws s3 cp report-approved.txt s3://labex-report-history/report.txt
AWS View で report.txt を開き、承認済みの売上を確認します。履歴には Current と表示されたバージョンが一つあります。
次に、同じキーに下書きをアップロードして、間違いを再現します。
aws s3 cp report-draft.txt s3://labex-report-history/report.txt
プレビューは Monthly revenue: 00000 に変わります。現在のオブジェクトキーはまだ一つですが、その履歴には二つの保存済みバージョンがあります。両方のファイルのサイズは同じです。バージョニングは、サイズだけから変化を判断するのではなく、書き込みを追跡します。
list-object-versions は、現在のバージョンと過去のレコードを取得します。
aws s3api list-object-versions --bucket labex-report-history
Versions 配列には、キーが report.txt で、VersionId の値が異なる二つの項目があります。IsLatest: true は下書きが現在版であることを示し、以前の承認済みバージョンは IsLatest: false です。ID とタイムスタンプは異なります。通常のオブジェクト一覧は現在のキーを表示するため、上書きを調べるときはバージョン一覧を使います。
公式 S3 Console では、Show versions によって、これらの履歴項目がオブジェクト一覧に表示されます。この例は異なるオブジェクトと、より多くの書き込みを示しています。Version ID 列の見方を知るために使ってください。この実験では Console へのログインは不要です。
出典：AWS Storage Blog。
承認済みバージョンを取得して公開する
このステップでは、以前の承認済みバージョンをダウンロードしてバイト列を確認し、履歴を削除せずに、その内容を再び現在版にします。
この時点では、report.txt のバージョンはちょうど二つあります。前の一覧で IsLatest: false の項目を見つけてください。これが承認済みの元のバージョンです。その VersionId をコピーします。
再利用できるよう、その ID をシェル変数に保存します。次の PASTE_APPROVED_VERSION_ID をコピーした値に置き換え、引用符は残してください。変数の代入では、= の前後にスペースを入れません。
OLD_VERSION='PASTE_APPROVED_VERSION_ID'
使う前に値を確認します。
echo "$OLD_VERSION"
プレースホルダーではなく、以前のバージョンの ID が表示されるはずです。$OLD_VERSION は変数を読み取り、二重引用符は値を一つのコマンド引数として保持します。
get-object は、オブジェクトの本文を最後に指定したローカルパスにダウンロードします。--version-id は、現在の下書きではなく、過去のコピーを選びます。
aws s3api get-object --bucket labex-report-history --key report.txt --version-id "$OLD_VERSION" recovered-report.txt
JSON 出力は、取得したコピーについて説明します。内容を読み取ります。
cat recovered-report.txt
Monthly revenue: 42000
cmp はファイルのバイト列を比較します。&& は、比較が成功した場合だけ後続のメッセージを実行します。
cmp report-approved.txt recovered-report.txt && echo 'Approved historical content verified'
過去のバージョンを取得しても、それが現在版になるわけではありません。バージョンを指定せずにキーを読む利用者は、まだ下書きを受け取ります。復元したバイト列をそのキーに公開します。
aws s3 cp recovered-report.txt s3://labex-report-history/report.txt
これにより、承認済みレポートを含む三つ目のバージョンが作成されます。古い承認済みバージョンと下書きの両方が、調査用に残ります。AWS View は承認済みの内容を現在版として表示し、三つのバージョンレコードを表示します。履歴を一覧表示して確認します。
aws s3api list-object-versions --bucket labex-report-history
新しい項目は IsLatest: true です。間違いの証拠を消すのではなく、新しい現在版を書き込むことでデータを復元しました。
この例は、現在版として復元されたレポートと、三つの異なる履歴項目を示しています。表示されたバージョン ID は、そのセッションの例です。
削除マーカーの後でアクセスを回復する
このステップでは、削除マーカーがバージョン付きオブジェクトを隠す様子を観察し、マーカーを除去して、直前の現在版を再び表示します。
模式図：削除によって現在のマーカーが追加されても、保存済みの三つのレポートバージョンは残ります。v1～v3 のラベルは書き込み順序を表し、実際のバージョン ID ではありません。
バージョニングが有効なバケットでは、バージョン ID を指定しない削除リクエストは削除マーカーを作成します。これは、キーが削除されたことを示す現在の履歴項目です。ファイルのバイト列は含まず、過去のバージョンも消去しません。通常のファイルコマンドで現在のキーを削除します。
aws s3 rm s3://labex-report-history/report.txt
通常の一覧には、現在のオブジェクトが表示されなくなります。
aws s3 ls s3://labex-report-history/
AWS View では現在のオブジェクトがなくなりますが、履歴には三つの Version 行と、現在の Delete marker が残ります。
バージョンを選ばずにキーのダウンロードを試します。
aws s3 cp s3://labex-report-history/report.txt unavailable-report.txt
このコマンドは、見つからないことを示すエラーで失敗する想定です。現在の削除マーカーによって、通常の読み取りはオブジェクトが存在しないように動作します。これは、過去のバイト列が消去されたことを証明するものではありません。
完全な履歴を読み取ります。
aws s3api list-object-versions --bucket labex-report-history
応答には、Versions とともに DeleteMarkers が含まれます。DeleteMarkers 内の一つの項目を見つけ、VersionId をコピーしてください。この ID が識別するのはマーカーであり、保存されたレポートではありません。
次のプレースホルダーを、そのマーカー ID に置き換えます。
MARKER_VERSION='PASTE_DELETE_MARKER_ID'
delete-object で、その正確なマーカーを削除します。--version-id を指定すると、新しいマーカーを作成する代わりに、選択した履歴項目を削除します。
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id "$MARKER_VERSION"
応答は削除したマーカーを示します。直前の承認済みバージョンが再び現在版になります。この操作は新しいレポートバージョンをアップロードしません。キーをダウンロードし、通常のアクセスを確認します。
aws s3 cp s3://labex-report-history/report.txt accessible-report.txt
cmp report-approved.txt accessible-report.txt && echo 'Current report accessible again'
比較が成功します。AWS View は、承認済みの内容と三つのバージョンを持つ report.txt を再び表示します。マーカーを除去するとアクセスが回復します。一方、データバージョンを永久に削除すると、その特定のコピーが消去されます。
過去のバージョンとバケットを削除する
このステップでは、空のバケットを削除する前に、すべての実験用データバージョンを削除します。
通常のオブジェクト一覧が空でも、バージョン履歴はストレージを使います。単純な aws s3 rm は別の削除マーカーを作成するため、バージョン付きバケットを空にするには不十分です。前のステップのマーカーは既に除去されましたが、三つのデータバージョンは残っています。
永久に削除する前に、履歴を一覧表示します。
aws s3api list-object-versions --bucket labex-report-history
Versions に三つの項目があり、DeleteMarkers はないはずです。すべての項目は、この使い捨てのレポート演習のものです。
三つの項目はすべて report.txt に属します。既に delete-object --version-id でマーカーを除去しました。同じ操作で、データバージョンを永久に削除できます。
一覧から一つの VersionId をコピーし、次のプレースホルダーを置き換えてください。三つの異なる ID それぞれに対して、このコマンドを一度ずつ実行します。永久削除は元に戻せないため、毎回バケット、キー、ID を確認してください。
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id 'PASTE_VERSION_ID'
成功した応答は、削除したバージョンを示します。バージョン ID が選ぶのは一つの過去のコピーであり、キーのすべてのバージョンを削除するわけではありません。三つすべてを削除した後、バージョンもマーカーも残っていないことを確認します。
aws s3api list-object-versions --bucket labex-report-history
成功した応答には、Versions や DeleteMarkers の項目がありません。次に、rb で空のバケットを削除します。
aws s3 rb s3://labex-report-history
出力は remove_bucket: labex-report-history です。ストレージが引き続き応答することを確認します。
aws s3 ls
バケットは残っておらず、AWS View は No buckets を表示します。ローカルのレポートファイルは引き続き利用できます。削除したのは、実験用の S3 リソースとその履歴だけです。
まとめ
公開前にバケットのバージョニングを有効にし、現在のキーと過去のバージョン ID を区別しました。過去のバージョンを取得し、確認済みのバイト列を公開することで、上書きされたレポートを復元しました。その後、削除マーカーを作成して除去し、別のバージョンをアップロードせずに通常のアクセスを回復しました。
バージョニングは履歴を保持しますが、明示的なバージョン削除を元に戻せるようにはしません。最後に、すべての実験用バージョンを確認して永久に削除し、マーカーが残っていないことを確認して、空のバケットを削除しました。
