SW BBANG J

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: 削除マーカー追加 (IsLa...

本番環境でデータ破損が発生し、RDSスナップショットから急いで復元しようとしたとき、多くのエンジニアが同じ疑問にぶつかる。「既存のインスタンスが上書きされるのか、それとも別のエンドポイントを持つ新しいインスタンスが作られるのか」——この挙動を誤解したまま復元操作を実行すると、アプリケーションの接続先が変わらず、復元したはずのデータに誰もアクセスできないという状況が生まれる。RDSスナップショット復元の動作原理を正確に理解しておくことは、障害対応の成否を左右する。 TL;DR：RDSスナップショット復元の要点 項目 挙動 既存インスタンスの上書き 行われない。常に新しいインスタンスが作成される エンドポイント 新しいインスタンス固有のエンドポイントが割り当てられる 元のインスタンス 復元操作後も変更されずそのまま稼働し続ける パラメータグループ / セキュリティグループ デフォルト設定が適用される。元の設定は引き継がれない アプリケーション切り替え エンドポイントの手動変更またはRoute 53 CNAMEの更新が必要 マルチAZ / リードレプリカ 復元時に再設定が必要。スナップショットには含まれない RDSスナップショット復元の仕組み RDSのスナップショット復元は、既存インスタンスへの変更操作ではなく、スナップショットを元にした 新規インスタンスのプロビジョニング として実装されている。これはAWSの設計上の意図であり、復元操作が元のデータを誤って破壊するリスクを排除するための安全機構でもある。 スナップショット自体はS3上に保存されたストレージボリュームのポイントインタイムコピーであり、インスタンスの設定情報（パラメータグループ、セキュリティグループ、マルチAZ設定など）は含まれない。復元時にAWSは新しいDBインスタンス識別子を要求し、そのIDに基づいた新しいエンドポイントを生成する。 graph TD A["稼働中のRDSインスタンス prod-db"] -->|"スナップショット取得"| B[...