メインコンテンツへスキップ

S3バケットのバージョニング有効化手順（BookStackバックアップ向け）

🧭 はじめに

本記事は、BookStackバックアップを保存する S3バケットでバージョニングを有効化する具体手順と運用上の注意点をまとめたものです。 親マニュアルの 1-2「バージョニングを有効化」 を、実際の運用を想定した解像度で補足します。

目的は以下の通りです。

  • aws s3 sync 等による 上書き・削除事故からの復旧余地を確保
  • バックアップ運用における 人為ミス耐性の向上
  • 後続のライフサイクル設定（1-3）への安全な布石

🧠 バージョニングとは何か（重要な前提理解）

S3のバージョニングを有効にすると、同一キー（同一パス・同一ファイル名）への上書きが「履歴として保存」 されます。

  • backup.tar.gz を毎日アップロード → 日付違いで複数バージョンが保持される
  • aws s3 sync --delete → 即時完全消滅せず、削除マーカーが付く

バージョニングは「バックアップの保険」であり、バックアップそのものの代替ではない。

🪣 対象バケットの確認

作業対象は、すでに作成済みのバックアップ用バケットです。

例：

  • バケット名: bookstack-backup-xxxx
  • リージョン: ap-northeast-1（Lightsailと同一）

リージョンは後から変更できない。 Lightsailと異なるリージョンだと通信遅延・転送料の面で不利。

⚙️ バージョニング有効化手順（AWSコンソール）

① S3コンソールへ移動

AWS管理コンソール → S3 → 対象バケットを選択

② 「プロパティ」タブを開く

バケット画面上部の 「プロパティ」 タブを選択

③ バージョニング設定を編集

  • セクション: バケットのバージョニング
  • 状態: 「無効」 → 「有効」 に変更
  • 「変更を保存」を押下

この操作は即時反映され、以後のアップロードから履歴管理が有効になる。

⚠️ハマリポイント

親マニュアル1-2でバージョンリストの取得を許可していない場合、ポリシーに追加する必要がある。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketVersioning",  //追加
        "s3:ListBucketVersions"    //追加
      ],
      "Resource": "arn:aws:s3:::bookstack-backup-xxxx"
    },
    {
      "Sid": "AllowPutGetObjects",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::bookstack-backup-xxxx/*"
    }
  ]
}

🔍 有効化後の挙動確認（理解しておくべき点）

同名ファイルの扱い

操作 結果
同名で再アップロード 新しいバージョンとして追加
rm / sync --delete 削除マーカーが付く
コンソール表示 最新版のみ（既定）

過去バージョンは「非表示」なだけで消えていない。 必要時に手動で復元可能。

チェック手順

① テスト用の小さなファイルを作る

echo "s3 upload test $(date)" > /tmp/s3-test.txt
  • サイズは数十バイト
  • 削除しても困らない内容

② S3へアップロード（put）

aws s3 cp /tmp/s3-test.txt s3://bookstack-backup-xxxx/test/s3-test.txt

ここで エラーが出なければ第一関門クリア。

この時点で PutObject 権限は問題なし。

③ S3上に存在することを確認

aws s3 ls s3://bookstack-backup-xxxx/test/

出力例：

2025-xx-xx xx:xx:xx         42 s3-test.txt

これで、

  • 認証
  • 書き込み
  • 読み取り

の最低限がすべて確認できています。

④ バージョンの追加の確認

②をもう一度実行した後、下記のコマンドを実行。JSON形式でバージョンが出てきたらOK

aws s3api list-object-versions \
  --bucket bookstack-backup-xxxx \
  --prefix test/s3-test.txt

出力例：

{
    "Versions": [
        {
            "ETag": "\"xxxxxx\"",
            "Size": 44,
            "StorageClass": "STANDARD",
            "Key": "test/s3-test.txt",
            "VersionId": "xxxxxxxxxxxxxxxxxxxxxxxx",
            "IsLatest": true,
            "LastModified": "2025-12-27T06:38:49.000Z",
            "Owner": {
                "ID": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
            }
        },
        {
            "ETag": "\"xxxxxx\"",
            "Size": 44,
            "StorageClass": "STANDARD",
            "Key": "test/s3-test.txt",
            "VersionId": "xxxxxxxxxxxxxxxxxxxxxxxy",
            "IsLatest": false,
            "LastModified": "2025-12-27T06:36:23.000Z",
            "Owner": {
                "ID": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
            }
        }
    ]
}

⑤ 後始末（任意だが推奨）

aws s3 rm s3://bookstack-backup-xxxx/test/s3-test.txt
rm -f /tmp/s3-test.txt

s3://bookstack-backup-xxxx/test/が今回初めて作るもので削除してよければ、

aws s3 rm s3://bookstack-backup-xxxx/test/ --recursive

で消してもよい。

テスト痕跡を残さない癖をつけると、後で混乱しない。

ストレージ容量について

  • バージョン数に比例して 使用量は増える
  • バックアップ用途では 想定通りの挙動

「容量が増える＝失敗」ではない。 履歴保持は意図したコスト。

🚨 やってはいけないこと

バージョニング有効化後に「一括完全削除」を安易に行わない。
CLIやコンソールでの完全削除は、復旧不能になる可能性がある。

特に注意：

  • aws s3 rm s3://bucket --recursive
  • バージョンID指定削除
  • バケット自体の削除

🧩 後続ステップとの関係

  • 次工程 1-3 ライフサイクル設定 で、

    • 古いバージョンのみをGlacierへ移行
    • N日経過後に非現行バージョン削除 といった 安全なコスト制御が可能になる。

バージョニング → ライフサイクル の順序は、S3バックアップ運用の定石。

✅ まとめ

  • バージョニングは 事故耐性を劇的に高める
  • 有効化は 数クリックで完了
  • コスト増はあるが、バックアップ用途では 許容かつ合理的
  • 後続の自動化・削減設計の前提条件になる
上に戻る