# 🪣 BookStackバックアップをS3へ自動退避する手順書（cron・検証・通知つき）
🧭 はじめに
本手順書は、BookStack（Linux上）で作成したバックアップ（DB / uploads / .env）を 日次で生成し、S3へ自動転送し、成功/失敗を検証して通知するまでを、運用向けにまとめたもの。 S3は容量課金＋リクエスト課金の従量制で、バックアップ用途ではコストが小さくなりやすい。 (Amazon Web Services, Inc.)
🧱 全体構成
✅ 目的の状態
- Lightsail（BookStack）側で毎日バックアップを作る
- その成果物をS3へ同期（アップロード）
- 「今日のバックアップがS3に存在する」ことを確認して成否判定
- 失敗したら通知（最小はログ、発展でWebhook/メール）
Windowsのサスペンド/デュアルブート問題を避けるため、サーバ側（常時稼働）を主系にする。
📌 前提
- BookStackのパス:
/var/www/BookStack - バックアップ保存先（ローカル）:
/var/backups/bookstack - DB名:
bookstackdb - DBユーザー:
bookstackuser
🧰 0. LightsailにAWS CLIを入れる
0-1. AWS CLIの存在確認
aws --version
無ければ導入（Ubuntu想定）:
sudo apt update
sudo apt install -y awscli
aws s3 sync の挙動は公式ドキュメントに準拠。 :contentReference[oaicite:3]{index=3}
🔐 1. S3側の準備（バケット作成・安全設定）
🪣 1-1. バケットを作成
S3コンソールで、Lightsailと同じリージョン(例：ap-northeast-1=東京)にバケットを作成（例: my-bookstack-backup-<unique>）。
バケット名はグローバルで固有。 被ると作れない。
参考記事： # Lightsail（BookStack）バックアップ用 S3 + IAM 設定手順
🧩 1-2. バージョニングを有効化（強く推奨）
S3のバージョニングを有効にすると、上書きや削除に対して復元余地が増える。 (AWS ドキュメント)
- コンソール: バケット → プロパティ → バージョニング → 有効化
“同期で上書きした” を戻せる可能性が上がる。
参考記事：🧩 S3バケットのバージョニング有効化手順（BookStackバックアップ向け）
🧊 1-3. ライフサイクル（任意・後でOK）
バックアップはアクセス頻度が低いので、一定日数後にGlacier系へ移行するとコストを下げやすい（ただし復元に時間がかかる場合がある）。 (AWS ドキュメント)
最初はライフサイクル無しで運用を安定させ、後から追加するのが安全。
🔑🗃 2. サーバ側の認証（AWS CLI用）
LightsailでS3にアップロードするには、AWS API認証が必要。実務上の選択肢は2つ。
✅ 推奨: IAMユーザー（最小権限）＋アクセスキー
（LightsailでIAMロール運用に寄せる方法もあるが、ここでは確実に動く構成を先に作る）
2-1. IAMユーザー作成
IAMで「プログラムによるアクセス（アクセスキー）」を作成し、S3バケットへの最小権限だけを付与。
2-2. 最小権限ポリシー例（バケット限定）
s3:ListBuckets3:PutObjects3:GetObjects3:DeleteObject管理者権限（AdministratorAccess）をバックアップ用IAMユーザーに付与しない。
🧰 3. LightsailにAWS CLIを入れる
3-1. AWS CLIの存在確認
aws --version無ければ導入（Ubuntu想定）:
sudo apt updatesudo apt install -y awscliaws s3 sync の挙動は公式ドキュメントに準拠。 :contentReference[oaicite:3]{index=3}
🗃 4. BookStackバックアップを作る（ローカル）
ここは「すでに出来ている」前提でも、検証込みで“正”を固定する。
4-2-1. ローカルに生成される成果物（3点セット）
- DB:
bookstackdb_YYYY-MM-DD.sql.gz - uploads:
bookstack_uploads_YYYY-MM-DD.tar.gz - env:
bookstack.env.YYYY-MM-DD
.env が無いと復旧できない。 3点セット必須。
☁️ 5.3. S3へ同期アップロード（aws s3 sync）
5-3-1. S3の配置ルール（推奨）
S3側のプレフィックス例:
s3://<bucket>/bookstack/
5-3-2. まずは手動で同期（初回）
以下のように同期する（ローカル→S3）。aws s3 sync は差分同期が基本。 ([AWS ドキュメントドキュメント][4])
コマンド例（実際はバケット名に置換）:
aws s3 sync /var/backups/bookstack s3://<bucket>/bookstack/
✅ 正常確認（S3にあるか）
aws s3 ls s3://<bucket>/bookstack/
初回は “lsで見える” を確認してから自動化に進む。
5-3-3. 同期時の削除（慎重に）
--delete を付けると、ローカルに無いファイルがS3から消える（ミラー運用）。 ([AWS ドキュメントドキュメント][5])
初期は --delete を付けない。 運用が固まってから。
✅ 6.4. “正しく取れた” を機械的に検証する（最重要）
6-4-1. 今日の日付のバックアップがローカルにあるか
ls -lh /var/backups/bookstack | grep "$(date +%F)"
期待:
bookstackdb_YYYY-MM-DD.sql.gzbookstack_uploads_YYYY-MM-DD.tar.gzbookstack.env.YYYY-MM-DD
6-4-2. 今日の日付のバックアップがS3にあるか
aws s3 ls s3://<bucket>/bookstack/ | grep "$(date +%F)"
“コマンドが成功した” ではなく “成果物が存在する” を合否にする。
⏰ 7.5. cronで自動化（生成→S3同期→検証→通知）
7-5-1. 認証情報の置き場所（安全寄り）
方式A（簡単・妥当）: rootのみ読めるファイルに環境変数として保存
例: /root/.aws/bookstack_env
- 所有者root、権限600
中身（例）:
AWS_ACCESS_KEY_ID=...AWS_SECRET_ACCESS_KEY=...AWS_DEFAULT_REGION=ap-northeast-1
権限:
sudo chmod 600 /root/.aws/bookstack_env
アクセスキーを一般ユーザーが読める場所に置かない。
7-5-2. 実行スクリプト作成
例: /usr/local/bin/bookstack_backup_to_s3.sh（root実行）
実行順:
- ローカルバックアップ生成（あなたの既存スクリプトでOK）
aws s3 syncでS3へaws s3 lsで今日の成果物があるか検証- 失敗なら通知（まずはlogger）
aws s3 sync の仕様は公式参照（差分条件・同期挙動）。 :contentReference[oaicite:6]{index=6}
7-5-3. cron登録
sudo crontab -e
例（毎日03:40、ローカル生成が03:30想定）:
40 3 * * * . /root/.aws/bookstack_env && /usr/local/bin/bookstack_backup_to_s3.sh
cronの時刻はOSのタイムゾーン依存。 `date` でJST/UTCを固定してから設定する。
🔔 8.6. 通知（最小→発展）
8-6-1. 最小（まずこれ）
スクリプト内で失敗時に:
logger -t bookstack-backup "FAILED: ..."
確認:
sudo journalctl -t bookstack-backup -n 50
8-6-2. 発展（Webhook）
Slack/Discord等へ投げる（curl）方式が扱いやすい。
通知は “失敗時のみ” にするのが運用ノイズを減らす。
🧪 9.7. 復旧リハーサル（最短の動作確認）
本番を壊さずに確認したい場合は「別DB名」でリストアテストをする。
本番DBに上書きリストアしない。 必ず別DBで試す。
📎 10.8. コストの要点
S3は保存容量とリクエスト等の従量課金。バックアップ程度の容量では月コストが小さくなりやすい。 (Amazon Web Services, Inc.)
✅ ここから先（次のステップ）
この手順書は「骨格」。次の返信で、あなたの現状に合わせて 細部を確定しながら完成させる。
次に、以下3点だけ教えてほしい（値そのものは伏せてOK）:
この3点が決まると、スクリプトとcronを“そのままコピペで動く形”に確定できる。