2026年9月8日

バックアップ戦略の設計（3-2-1バックアップルール）

バックアップ・監視

はじめに

WordPressサイトのバックアップ戦略が不十分でサーバー障害時に復元できなかった・バックアップは取っているがサーバーと同じ場所に保管しているため被災時に失う・バックアップから正常に復元できるか確認していないといった問題の解決方法を解説します。

症状・原因

バックアップファイルがサーバー上にのみ存在し、サーバー自体が障害になると復元できない
バックアップは取っているが復元テストをしたことがなく、破損に気づかない
バックアッププラグインがPHPタイムアウトで大容量サイトのバックアップを完了できない
バックアップの世代管理がなく直近のものしか残っていない

解決手順

ステップ1：3-2-1バックアップルールを理解する

✅ 3-2-1 バックアップルール
│
├── 3: データのコピーを3つ保持
│   ├── オリジナル（本番サーバー）
│   ├── コピー1（同一サーバー内のバックアップ）
│   └── コピー2（オフサイトバックアップ）
│
├── 2: 2種類の異なるメディアに保存
│   ├── 例：ローカルディスク + クラウドストレージ
│   └── 例：HDD + テープ（企業向け）
│
└── 1: 1つは必ずオフサイト（遠隔地）に保管
    ├── AWS S3 / Google Cloud Storage
    ├── Backblaze B2（低コスト）
    └── リモートサーバー（rsync）

# ✅ WordPress のデータを把握する
# DB サイズ
wp db size --path=/var/www/html/
# → Database Size: 256 MB

# ファイルサイズ
du -sh /var/www/html/wp-content/uploads/
# → 12G  /var/www/html/wp-content/uploads/

# バックアップ頻度の目安
# 投稿頻度：毎日 → DBバックアップ：毎日
# メディア更新：週1回 → ファイルバックアップ：週1回

ステップ2：自動バックアップスクリプトを設定する

# ✅ バックアップスクリプトを作成
sudo tee /usr/local/bin/wp-backup.sh << 'SCRIPT'
#!/bin/bash
set -euo pipefail

DATE=$(date +%Y%m%d-%H%M%S)
SITE_PATH="/var/www/html"
BACKUP_LOCAL="/var/backups/wordpress"
BACKUP_REMOTE="s3://my-wp-backup-bucket"
DAYS_KEEP=30

mkdir -p "$BACKUP_LOCAL/db" "$BACKUP_LOCAL/files"

# ✅ DB バックアップ
wp db export "$BACKUP_LOCAL/db/db-$DATE.sql" \
    --add-drop-table \
    --path="$SITE_PATH"

# ✅ 圧縮
gzip "$BACKUP_LOCAL/db/db-$DATE.sql"

# ✅ ファイルバックアップ（uploads・テーマ・プラグイン）
tar -czf "$BACKUP_LOCAL/files/files-$DATE.tar.gz" \
    -C "$SITE_PATH/wp-content" \
    uploads/ themes/ plugins/

# ✅ AWS S3 へアップロード（オフサイト）
aws s3 sync "$BACKUP_LOCAL/" "$BACKUP_REMOTE/" \
    --delete \
    --storage-class STANDARD_IA  # 低頻度アクセス = コスト削減

# ✅ 古いバックアップを削除（ローカルのみ）
find "$BACKUP_LOCAL/db" -name "*.sql.gz" -mtime +$DAYS_KEEP -delete
find "$BACKUP_LOCAL/files" -name "*.tar.gz" -mtime +$DAYS_KEEP -delete

# ✅ バックアップ完了通知
echo "Backup completed: db-$DATE.sql.gz" | \
    mail -s "WordPress Backup OK - $(hostname)" admin@example.com
SCRIPT

sudo chmod +x /usr/local/bin/wp-backup.sh

ステップ3：バックアップスケジュールを設定する

# ✅ crontab でスケジュール設定
sudo crontab -e

# ✅ DBバックアップ：毎日午前2時
0 2 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

# ✅ ファイルバックアップ：毎週日曜日午前3時
0 3 * * 0 /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

# ✅ バックアップログを毎月1日に確認
0 9 1 * * tail -50 /var/log/wp-backup.log | mail -s "月次バックアップレポート" admin@example.com

# ✅ AWS CLI をインストール・設定
sudo apt install awscli -y
aws configure
# AWS Access Key ID: xxxxxxxx
# AWS Secret Access Key: xxxxxxxx
# Default region name: ap-northeast-1
# Default output format: json

# ✅ S3 バケットを作成（バージョニング有効）
aws s3 mb s3://my-wp-backup-bucket
aws s3api put-bucket-versioning \
    --bucket my-wp-backup-bucket \
    --versioning-configuration Status=Enabled

ステップ4：バックアップの整合性を検証する

# ✅ DB バックアップファイルの整合性チェック
gunzip -t /var/backups/wordpress/db/db-20240101-020000.sql.gz
# → エラーなし = ファイルが壊れていない

# ✅ SQL ファイルの末尾を確認
zcat /var/backups/wordpress/db/db-*.sql.gz | tail -5
# → -- Dump completed on 2024-01-01 ... ← 正常終了

# ✅ テスト環境で実際に復元テストを実施（月1回推奨）
# テスト用データベースに復元
mysql -u root -p test_db < <(gunzip -c /var/backups/wordpress/db/db-latest.sql.gz)
# WordPress がテスト環境で正常動作するか確認

# ✅ Backblaze B2 への冗長バックアップ（S3より安価）
# b2 CLI でアップロード
b2 authorize-account <applicationKeyId> <applicationKey>
b2 sync /var/backups/wordpress b2://my-wp-backup-bucket/

ステップ5：復元手順を文書化・テストする

# ✅ 復元スクリプトを作成
sudo tee /usr/local/bin/wp-restore.sh << 'SCRIPT'
#!/bin/bash
# 使い方: wp-restore.sh <db-backup.sql.gz> <files-backup.tar.gz>
set -euo pipefail

DB_BACKUP="$1"
FILES_BACKUP="$2"
SITE_PATH="/var/www/html"

# 1. DB を復元
echo "Restoring database..."
gunzip -c "$DB_BACKUP" | wp db import - --path="$SITE_PATH"

# 2. URL を新しいドメインに置換
wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
    --skip-columns=guid \
    --path="$SITE_PATH"

# 3. ファイルを復元
echo "Restoring files..."
tar -xzf "$FILES_BACKUP" -C "$SITE_PATH/wp-content/"
chown -R www-data:www-data "$SITE_PATH"

# 4. キャッシュクリア
wp cache flush --path="$SITE_PATH"
wp rewrite flush --hard --path="$SITE_PATH"

echo "Restore completed!"
SCRIPT
sudo chmod +x /usr/local/bin/wp-restore.sh

# ✅ 復元テストの実施（四半期ごとに推奨）
# sudo wp-restore.sh /path/to/db-backup.sql.gz /path/to/files.tar.gz

注意事項

バックアップを取るだけでは不十分です。定期的に復元テストを実施して、バックアップから実際に正常な状態に戻せることを確認してください。破損したバックアップでは復元できません
S3のSTANDARD_IA（低頻度アクセス）クラスを使うとストレージコストを70%削減できます。ただしデータ取得時に追加料金が発生するため、復元テスト時は注意してください

まとめ

3-2-1バックアップ戦略は①3-2-1ルール（コピー3つ・2種類のメディア・1つはオフサイト）の理解・WordPressのDBサイズとファイルサイズを把握してバックアップ頻度を決定、②バックアップスクリプト作成（wp db export + gzip + tar -czf）・AWS S3へaws s3 syncでオフサイトアップロード・古いファイルを自動削除、③cronで毎日深夜にDB・週1回にファイルを自動バックアップ・S3バケットのバージョニング有効化、④gunzip -tでファイル整合性チェック・テスト環境で実際に復元テスト・Backblaze B2で冗長バックアップ、⑤復元スクリプトを作成して復元手順を文書化・四半期ごとの復元テスト実施の手順で設計します。

Post Views: 2