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

# 🪣 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. BookStackバックアップを作る（ローカル）

ここは「すでに出来ている」前提でも、検証込みで“正”を固定する。

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点セット必須。

☁️ 3. S3へ同期アップロード（aws s3 sync）

3-1. S3の配置ルール（推奨）

S3側のプレフィックス例:

  • s3://<bucket>/bookstack/

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で見える” を確認してから自動化に進む。

3-3. 同期時の削除（慎重に）

--delete を付けると、ローカルに無いファイルがS3から消える（ミラー運用）。 ([AWS ドキュメント][5])

初期は --delete を付けない。 運用が固まってから。

✅ 4. “正しく取れた” を機械的に検証する（最重要）

4-1. 今日の日付のバックアップがローカルにあるか

  • ls -lh /var/backups/bookstack | grep "$(date +%F)"

期待:

  • bookstackdb_YYYY-MM-DD.sql.gz
  • bookstack_uploads_YYYY-MM-DD.tar.gz
  • bookstack.env.YYYY-MM-DD

4-2. 今日の日付のバックアップがS3にあるか

  • aws s3 ls s3://<bucket>/bookstack/ | grep "$(date +%F)"

“コマンドが成功した” ではなく “成果物が存在する” を合否にする。

⏰ 5. cronで自動化（生成→S3同期→検証→通知）

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

アクセスキーを一般ユーザーが読める場所に置かない。

5-2. 実行スクリプト作成

例: /usr/local/bin/bookstack_backup_to_s3.sh（root実行）

実行順:

  1. ローカルバックアップ生成（あなたの既存スクリプトでOK）
  2. aws s3 sync でS3へ
  3. aws s3 ls で今日の成果物があるか検証
  4. 失敗なら通知（まずはlogger）

aws s3 sync の仕様は公式参照（差分条件・同期挙動）。 :contentReference[oaicite:6]{index=6}

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を固定してから設定する。

🔔 6. 通知（最小→発展）

6-1. 最小（まずこれ）

スクリプト内で失敗時に:

  • logger -t bookstack-backup "FAILED: ..."

確認:

  • sudo journalctl -t bookstack-backup -n 50

6-2. 発展（Webhook）

Slack/Discord等へ投げる（curl）方式が扱いやすい。

通知は “失敗時のみ” にするのが運用ノイズを減らす。

🧪 7. 復旧リハーサル（最短の動作確認）

本番を壊さずに確認したい場合は「別DB名」でリストアテストをする。

本番DBに上書きリストアしない。 必ず別DBで試す。

📎 8. コストの要点

S3は保存容量とリクエスト等の従量課金。バックアップ程度の容量では月コストが小さくなりやすい。 (Amazon Web Services, Inc.)

この3点が決まると、スクリプトとcronを“そのままコピペで動く形”に確定できる。

上に戻る