S3で削除したファイルを復元する方法 — バージョニングが有効な場合の完全ガイド

S3バケットのファイルを誤って削除してしまった — 本番環境でこれが起きると、まず確認するのは「バージョニングを有効にしていたか」という一点だ。バージョニングが有効であれば、S3上の削除は実際にはデータを消去しておらず、削除マーカーと呼ばれるオブジェクトを追加する操作に過ぎない。この仕組みを理解していれば、復元は数分で完了する。

TL;DR — S3削除ファイルの復元手順

ステップ操作目的
1バージョニング有効化を確認復元可能かを判断する
2削除マーカーを特定どのバージョンIDが削除操作かを確認
3削除マーカーを削除直前バージョンを最新として復元
4特定バージョンを直接コピー任意の過去バージョンに戻す場合

S3バージョニングの仕組み — 削除とは何か

バージョニングが有効なバケットでは、オブジェクトに対するすべての書き込みと削除が履歴として保持される。通常のDELETEリクエスト（バージョンIDを指定しない削除）は、オブジェクト本体を消去するのではなく、削除マーカー（Delete Marker）という特殊なバージョンを最新として追加する。GETリクエストはこの削除マーカーを参照して404を返すが、以前のバージョンはストレージ上にそのまま残っている。

一方、バージョンIDを明示したDELETEリクエストは、そのバージョンを完全に消去する。この2つを混同すると復元操作を誤る。削除マーカー自体もバージョンIDを持つオブジェクトであり、これを削除することで直前バージョンが最新に昇格する、というのが復元の基本原理だ。

sequenceDiagram participant Client as クライアント participant S3 as S3 バケット Note over S3: v1 (古いバージョン) Note over S3: v2 (削除前の最新) Client->>S3: DELETE key.txt (バージョンID指定なし) S3-->>S3: 削除マーカー追加 (IsLatest=true) Client->>S3: GET key.txt S3-->>Client: 404 Not Found (削除マーカーが最新) Note over Client: 復元操作 Client->>S3: DELETE key.txt --version-id [削除マーカーID] S3-->>S3: 削除マーカーを除去 Note over S3: v2 が IsLatest=true に復帰 Client->>S3: GET key.txt S3-->>Client: 200 OK (v2 を返す)
  1. バージョニング有効時の通常DELETE: 削除マーカーが最新バージョンとして追加される。過去のバージョンv1、v2はストレージに残存する。
  2. GETリクエスト: 削除マーカーが最新のため、S3は404を返す。
  3. 削除マーカーをDELETE: マーカーが除去され、v2が最新バージョンとして復活する。
  4. バージョンID指定のDELETE: 対象バージョンを完全消去する。この操作は取り消せない。

前提確認 — バージョニングが有効かどうかをチェックする

復元を試みる前に、対象バケットのバージョニング状態を確認する。バージョニングが無効だった場合、削除されたオブジェクトは復元できない。

aws s3api get-bucket-versioning \
  --bucket your-bucket-name

レスポンスに"Status": "Enabled"が含まれていれば復元可能だ。MFADeleteがEnabledになっている場合は、削除マーカーの削除にMFAデバイスが必要になる点に注意する。

S3削除ファイルの復元 — ステップバイステップ

ステップ1: 削除マーカーのバージョンIDを特定する

復元対象のオブジェクトキーに対して、すべてのバージョンと削除マーカーを一覧表示する。削除マーカーはIsDeleteMarker: trueとして返される。

aws s3api list-object-versions \
  --bucket your-bucket-name \
  --prefix your/object/key.txt

出力例（抜粋）:

{
  "DeleteMarkers": [
    {
      "Key": "your/object/key.txt",
      "VersionId": "abc123XYZ",
      "IsLatest": true,
      "LastModified": "2024-05-10T08:30:00.000Z"
    }
  ],
  "Versions": [
    {
      "Key": "your/object/key.txt",
      "VersionId": "def456ABC",
      "IsLatest": false,
      "LastModified": "2024-05-09T14:00:00.000Z"
    }
  ]
}

IsLatest: trueかつDeleteMarkers配列に含まれているバージョンIDが、削除操作によって追加されたマーカーだ。このIDをメモしておく。

ステップ2: 削除マーカーを削除して直前バージョンを復元する

削除マーカーのバージョンIDを明示してDELETEすることで、マーカーが除去され、直前のバージョンが最新として復活する。これが最も一般的な復元パターンだ。

aws s3api delete-object \
  --bucket your-bucket-name \
  --key your/object/key.txt \
  --version-id abc123XYZ

成功すると、レスポンスにDeleteMarker: trueと削除されたバージョンIDが返される。その後、通常のGETリクエストでオブジェクトにアクセスできることを確認する。

aws s3api head-object \
  --bucket your-bucket-name \
  --key your/object/key.txt

404が返らなければ復元成功だ。

ステップ3（任意）: 特定の過去バージョンを復元する

削除マーカーを除去するだけでは不十分な場合、つまり「削除前のバージョンではなく、さらに古いバージョンに戻したい」ときは、対象バージョンを現在のキーにコピーする。これにより、そのバージョンの内容が新しい最新バージョンとして書き込まれる。

aws s3api copy-object \
  --bucket your-bucket-name \
  --copy-source your-bucket-name/your/object/key.txt?versionId=def456ABC \
  --key your/object/key.txt

このコピー操作は新しいバージョンIDを生成する。元のバージョンdef456ABCはそのまま履歴に残る。

複数ファイルを一括復元する場合

特定のプレフィックス配下のすべての削除マーカーを除去したい場合、AWS CLIのみでは一括操作のネイティブサポートがないため、スクリプトで対応する必要がある。以下はBashでの実装例だ。

🔽 一括削除マーカー除去スクリプト（クリックして展開） 
#!/bin/bash
BUCKET="your-bucket-name"
PREFIX="your/prefix/"

# 削除マーカーのバージョンIDをすべて取得して削除する
aws s3api list-object-versions \
  --bucket "$BUCKET" \
  --prefix "$PREFIX" \
  --query 'DeleteMarkers[?IsLatest==`true`].[Key, VersionId]' \
  --output text | while read KEY VERSION_ID; do
    echo "削除マーカーを除去: $KEY ($VERSION_ID)"
    aws s3api delete-object \
      --bucket "$BUCKET" \
      --key "$KEY" \
      --version-id "$VERSION_ID"
done

このスクリプトはIsLatestがtrueの削除マーカーのみを対象にする。削除マーカーが最新でない（その後に別バージョンが書き込まれた）オブジェクトは対象外になるため、意図しない上書きを防げる。

実際の障害パターン — 誤診断から正しい原因特定へ

あるケースで、バージョニング有効なバケットからファイルが消えたと報告を受けた。list-object-versionsを実行すると削除マーカーが存在し、復元手順を試みた。しかし削除マーカーを除去しても、アプリケーションは依然として404を返し続けた。

最初の誤診断は「削除マーカーの除去が失敗している」というものだった。head-objectでオブジェクト自体は確認できるのに、アプリケーション側だけ404が続く。

実際の原因はCloudFrontのキャッシュだった。CloudFrontが404レスポンスをキャッシュしており、オリジンのS3が復元済みであってもエッジキャッシュが古い404を返し続けていた。aws cloudfront create-invalidationでキャッシュを無効化して初めて正常に解決した。S3側の復元操作は最初から正しく機能していた。

S3の復元確認は必ずS3 APIに直接アクセスして行う。CDNやアプリケーションレイヤーを経由した確認は、キャッシュの影響を受ける。

IAM権限 — 復元操作に必要な最小権限

削除マーカーの除去とバージョン一覧取得には、以下の権限が必要だ。

🔽 最小権限IAMポリシー（クリックして展開） 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucketVersions",
        "s3:GetBucketVersioning"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:DeleteObjectVersion",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

s3:DeleteObjectVersionは削除マーカーの除去に必要な権限だ。通常のs3:DeleteObjectとは別アクションである点に注意する。バケットポリシーでExplicit Denyが設定されている場合、IAMポリシーでAllowを付与してもアクセスは拒否される。

S3削除ファイルの復元 — 注意すべき動作の詳細

バージョニングを有効にしたタイミングより前にアップロードされたオブジェクトには、バージョンIDとしてnullが割り当てられる。このnullバージョンを誤って削除すると、そのバージョンは完全に消去される。list-object-versionsの出力でVersionIdが"null"と表示されているオブジェクトは、この状態にある。

また、S3 Intelligent-TieringやS3 Glacierなどのストレージクラスに移行されたバージョンを復元する場合、Glacier/Glacier Deep Archiveからの取り出しには別途復元リクエストが必要で、即時アクセスはできない。バージョン一覧のStorageClassフィールドで事前に確認しておくこと。

graph TD A["バージョニング確認
get-bucket-versioning"] --> B{"Status: Enabled?"}; B -- "No" --> C["復元不可
バックアップを確認"]; B -- "Yes" --> D["削除マーカー特定
list-object-versions"]; D --> E{"直前バージョンに
戻せばよい?"}; E -- "Yes" --> F["削除マーカーを削除
delete-object --version-id"]; E -- "No" --> G["特定バージョンをコピー
copy-object --copy-source ...?versionId="]; F --> H["復元確認
head-object"]; G --> H; H --> I{"200 OK?"}; I -- "No" --> J["CDN/アプリキャッシュを確認"]; I -- "Yes" --> K["復元完了"];
  1. バージョニング確認: まずget-bucket-versioningでEnabled状態を確認する。
  2. 削除マーカー特定: list-object-versionsでIsLatestな削除マーカーのVersionIdを取得する。
  3. 直前バージョン復元: 削除マーカーのVersionIdを指定してdelete-objectを実行する。
  4. 任意バージョン復元: 特定の過去バージョンに戻す場合はcopy-objectでVersionIdを指定してコピーする。
  5. 復元確認: head-objectでS3 APIに直接アクセスして確認する。

まとめと次のステップ — S3削除ファイルの復元を確実にするために

バージョニングが有効であれば、通常の削除操作からの復元は削除マーカーの除去という単純な操作で完結する。重要なのは、削除マーカーの除去とバージョンの完全削除を混同しないことだ。前者はデータを保持したまま最新バージョンを変更するが、後者は取り消せない。

今後の対策として検討すべき設定:

  • MFA Delete: バージョンの完全削除と、バージョニングの無効化にMFAを要求する。誤操作や不正アクセスによる完全削除を防ぐ最も強力な保護だ。
  • S3 Object Lock: コンプライアンス要件がある場合、WORM（Write Once Read Many）モデルでオブジェクトを保護できる。
  • S3バケットのレプリケーション: 別リージョンへのクロスリージョンレプリケーション（CRR）を設定することで、リージョン障害や誤削除に対する追加の保護層になる。

公式ドキュメント: Amazon S3 — 以前のバージョンの復元

用語集

用語説明
削除マーカー（Delete Marker）バージョニング有効バケットで通常のDELETE操作を行った際に追加される特殊なバージョン。オブジェクト本体は削除されない。
バージョンID（Version ID）バージョニング有効バケットの各オブジェクトバージョンに割り当てられる一意の識別子。
MFA Deleteバージョンの完全削除やバージョニング設定変更にMFA認証を要求するS3の機能。
nullバージョンバージョニング有効化前にアップロードされたオブジェクトに割り当てられるバージョンID。
S3 Object Lock指定期間中のオブジェクト削除・上書きを防止するWORMモデルの保護機能。

コメント

コメントを投稿

このブログの人気の投稿

SQS Visibility Timeoutの完全解説：メッセージ二重処理の原因と対策

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...
続きを読む

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む