【2026年版】Web制作バックアップ完全ガイド｜3-2-1-1-0ルール実践方法

# 実際のディレクトリ構成例
/var/www/html/                  # 本番データ
/backup/daily/website/          # バックアップ1（同サーバー）
s3://my-backup/website/         # バックアップ2（AWS S3）

#!/bin/bash
# /usr/local/bin/daily-backup.sh
# Web制作用日次バックアップスクリプト

# ========== 設定 ==========
BACKUP_ROOT="/backup/daily"
WEB_DIR="/var/www/html"
DB_HOST="localhost"
DB_USER="backup_user"
DB_PASS="your-password"  # 本番では環境変数または.my.cnfから読む
DATABASES=("wordpress_db" "client1_db" "client2_db")
RETENTION_DAYS=30
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
LOG_FILE="/var/log/backup.log"

# ========== 関数 ==========
log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a ${LOG_FILE}
}

notify_slack() {
  local status=$1
  local message=$2
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\": \"${status} ${message}\"}" \
    ${SLACK_WEBHOOK}
}

# ========== メイン処理 ==========
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR="${BACKUP_ROOT}/${BACKUP_DATE}"

log "=== バックアップ開始: ${BACKUP_DATE} ==="
mkdir -p ${BACKUP_DIR}

# 1. Webファイルのバックアップ
log "Webファイルをバックアップ中..."
tar -czf ${BACKUP_DIR}/website-files.tar.gz \
  --exclude="${WEB_DIR}/wp-content/cache/*" \
  --exclude="${WEB_DIR}/node_modules/*" \
  ${WEB_DIR}

if [ $? -eq 0 ]; then
  log "✅ Webファイル: 完了"
else
  log "❌ Webファイル: 失敗"
  notify_slack "❌ エラー" "日次バックアップ失敗（Webファイル）"
  exit 1
fi

# 2. データベースのバックアップ
log "データベースをバックアップ中..."
for DB in "${DATABASES[@]}"; do
  mysqldump \
    --single-transaction \
    --quick \
    --lock-tables=false \
    -h ${DB_HOST} \
    -u ${DB_USER} \
    -p${DB_PASS} \
    ${DB} | gzip > ${BACKUP_DIR}/${DB}.sql.gz

  if [ $? -eq 0 ]; then
    log "✅ データベース ${DB}: 完了"
  else
    log "❌ データベース ${DB}: 失敗"
    notify_slack "❌ エラー" "日次バックアップ失敗（DB: ${DB}）"
    exit 1
  fi
done

# 3. サーバー設定のバックアップ
log "サーバー設定をバックアップ中..."
tar -czf ${BACKUP_DIR}/server-config.tar.gz \
  /etc/nginx \
  /etc/apache2 \
  /etc/letsencrypt \
  /etc/cron.d \
  2>/dev/null

# 4. チェックサム生成
log "チェックサムを生成中..."
cd ${BACKUP_DIR}
sha256sum *.tar.gz *.sql.gz > checksums.txt 2>/dev/null

# 5. 古いバックアップを削除
log "古いバックアップを削除中..."
find ${BACKUP_ROOT} -maxdepth 1 -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} \;

BACKUP_SIZE=$(du -sh ${BACKUP_DIR} | cut -f1)
log "=== バックアップ完了: ${BACKUP_SIZE} ==="
notify_slack "✅ 完了" "日次バックアップ完了（${BACKUP_SIZE}）"

# /etc/cron.d/daily-backup
0 3 * * * root nice -n 19 ionice -c 3 /usr/local/bin/daily-backup.sh

#!/bin/bash
# /usr/local/bin/backup-to-s3.sh
# S3へのバックアップアップロード

S3_BUCKET="s3://my-website-backup"
BACKUP_ROOT="/backup/daily"
RETENTION_DAYS=90

# 最新のバックアップをS3にアップロード
LATEST_BACKUP=$(ls -td ${BACKUP_ROOT}/*/ | head -1)
BACKUP_NAME=$(basename ${LATEST_BACKUP})

log "S3にアップロード中: ${BACKUP_NAME}"
aws s3 sync ${LATEST_BACKUP} ${S3_BUCKET}/${BACKUP_NAME}/ \
  --storage-class STANDARD_IA \
  --sse AES256

if [ $? -eq 0 ]; then
  log "✅ S3アップロード: 完了"
else
  log "❌ S3アップロード: 失敗"
  exit 1
fi

#!/bin/bash
# S3イミュータブルバックアップの設定

BUCKET_NAME="my-immutable-backup"
REGION="ap-northeast-1"
RETENTION_DAYS=90

# 1. オブジェクトロック有効化でバケット作成
aws s3api create-bucket \
  --bucket ${BUCKET_NAME} \
  --region ${REGION} \
  --create-bucket-configuration LocationConstraint=${REGION} \
  --object-lock-enabled-for-bucket

# 2. バケットのオブジェクトロック設定
aws s3api put-object-lock-configuration \
  --bucket ${BUCKET_NAME} \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": '$RETENTION_DAYS'
      }
    }
  }'

# 3. バケットポリシーで削除を禁止
cat > bucket-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::${BUCKET_NAME}",
        "arn:aws:s3:::${BUCKET_NAME}/*"
      ]
    }
  ]
}
EOF

aws s3api put-bucket-policy \
  --bucket ${BUCKET_NAME} \
  --policy file://bucket-policy.json

echo "✅ イミュータブルバックアップバケット作成完了"

#!/bin/bash
# エアギャップバックアップ（週次実行）

BACKUP_DATE=$(date +%Y%m%d)
SOURCE_DIR="/backup/daily"
EXTERNAL_HDD="/mnt/external-hdd"
BACKUP_NAME="weekly-backup-${BACKUP_DATE}"

# 1. 外付けHDDを検出
echo "外付けHDDを接続してください..."
while [ ! -b /dev/sdb1 ]; do
  sleep 5
done

# 2. マウント
mount /dev/sdb1 ${EXTERNAL_HDD}
echo "✅ 外付けHDD マウント完了"

# 3. 最新の週次バックアップを作成
LATEST_BACKUP=$(ls -td ${SOURCE_DIR}/*/ | head -1)
tar -czf ${EXTERNAL_HDD}/${BACKUP_NAME}.tar.gz ${LATEST_BACKUP}

# 4. チェックサム生成
cd ${EXTERNAL_HDD}
sha256sum ${BACKUP_NAME}.tar.gz > ${BACKUP_NAME}.sha256

# 5. バックアップログ更新
echo "${BACKUP_DATE}: ${BACKUP_NAME}.tar.gz" >> ${EXTERNAL_HDD}/backup-log.txt

# 6. アンマウント
umount ${EXTERNAL_HDD}

# 7. 通知
echo "✅ エアギャップバックアップ完了"
echo "外付けHDDを取り外して、金庫に保管してください。"

# Slack通知
curl -X POST -H 'Content-type: application/json' \
  --data "{
    \"text\": \"✅ 週次エアギャップバックアップ完了\",
    \"attachments\": [{
      \"color\": \"good\",
      \"text\": \"外付けHDDを取り外して、金庫に保管してください。\"
    }]
  }" \
  https://hooks.slack.com/services/YOUR/WEBHOOK/URL

#!/bin/bash
# /usr/local/bin/restore-test.sh
# 毎週実行される自動リストアテスト

# ========== 設定 ==========
BACKUP_ROOT="/backup/daily"
TEST_ROOT="/tmp/restore-test"
DB_TEST_USER="test_user"
DB_TEST_PASS="test_password"
TEST_DB_NAME="restore_test_db"

# ログ
LOG_FILE="/var/log/restore-test.log"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a ${LOG_FILE}
}

# ========== テスト開始 ==========
log "=== リストアテスト開始 ==="

# 1. 最新バックアップを取得
LATEST_BACKUP=$(ls -td ${BACKUP_ROOT}/*/ | head -1)
BACKUP_NAME=$(basename ${LATEST_BACKUP})
log "テスト対象: ${BACKUP_NAME}"

# 2. テスト環境をクリーンアップ
rm -rf ${TEST_ROOT}
mkdir -p ${TEST_ROOT}

# 3. Webファイルの復元テスト
log "Webファイルの復元テスト中..."
tar -xzf ${LATEST_BACKUP}/website-files.tar.gz -C ${TEST_ROOT}
if [ $? -eq 0 ]; then
  log "✅ Webファイル展開: 成功"
else
  log "❌ Webファイル展開: 失敗"
  exit 1
fi

# 4. 重要ファイルの存在確認
REQUIRED_FILES=(
  "var/www/html/index.php"
  "var/www/html/wp-config.php"
  "var/www/html/wp-content/themes"
  "var/www/html/wp-content/plugins"
)

for file in "${REQUIRED_FILES[@]}"; do
  if [ -e "${TEST_ROOT}/${file}" ]; then
    log "✅ ${file}: 存在確認OK"
  else
    log "❌ ${file}: 見つかりません"
    exit 1
  fi
done

# 5. データベースの復元テスト
log "データベースの復元テスト中..."

# テスト用データベースを作成
mysql -u root -e "DROP DATABASE IF EXISTS ${TEST_DB_NAME};"
mysql -u root -e "CREATE DATABASE ${TEST_DB_NAME};"

# SQLダンプを復元
gunzip < ${LATEST_BACKUP}/database.sql.gz | \
  mysql -u root ${TEST_DB_NAME}

if [ ${PIPESTATUS[1]} -eq 0 ]; then
  log "✅ データベース復元: 成功"
else
  log "❌ データベース復元: 失敗"
  exit 1
fi

# 6. データベースの整合性チェック
log "データベースの整合性チェック中..."
TABLES=$(mysql -u root -N -e "SHOW TABLES FROM ${TEST_DB_NAME}" | wc -l)
POSTS=$(mysql -u root -N -e "SELECT COUNT(*) FROM ${TEST_DB_NAME}.wp_posts" 2>/dev/null)

log "テーブル数: ${TABLES}"
log "投稿数: ${POSTS}"

if [ ${TABLES} -gt 0 ]; then
  log "✅ データベース整合性: OK"
else
  log "❌ データベース整合性: NG"
  exit 1
fi

# 7. Webサーバー起動テスト
log "Webサーバー起動テスト中..."
cd ${TEST_ROOT}/var/www/html
php -S localhost:8888 > /dev/null 2>&1 &
PHP_PID=$!
sleep 3

# 8. HTTPレスポンステスト
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8888)
log "HTTPステータスコード: ${HTTP_STATUS}"

if [ "${HTTP_STATUS}" -eq "200" ]; then
  log "✅ Webサーバー起動: 成功"
else
  log "❌ Webサーバー起動: 失敗"
  kill ${PHP_PID}
  exit 1
fi

# 9. チェックサム検証
log "チェックサム検証中..."
cd ${LATEST_BACKUP}
sha256sum -c checksums.txt > /dev/null 2>&1
if [ $? -eq 0 ]; then
  log "✅ チェックサム検証: 成功"
else
  log "❌ チェックサム検証: 失敗"
fi

# 10. クリーンアップ
kill ${PHP_PID} 2>/dev/null
mysql -u root -e "DROP DATABASE IF EXISTS ${TEST_DB_NAME};"
rm -rf ${TEST_ROOT}

# 11. 結果通知
log "=== リストアテスト完了: すべて正常 ==="

curl -X POST -H 'Content-type: application/json' \
  --data "{
    \"text\": \"✅ 週次リストアテスト完了\",
    \"attachments\": [{
      \"color\": \"good\",
      \"fields\": [
        {\"title\": \"バックアップ\", \"value\": \"${BACKUP_NAME}\", \"short\": true},
        {\"title\": \"テーブル数\", \"value\": \"${TABLES}\", \"short\": true},
        {\"title\": \"投稿数\", \"value\": \"${POSTS}\", \"short\": true},
        {\"title\": \"HTTPステータス\", \"value\": \"${HTTP_STATUS}\", \"short\": true}
      ]
    }]
  }" \
  https://hooks.slack.com/services/YOUR/WEBHOOK/URL

exit 0

# /etc/cron.d/restore-test
0 2 * * 0 root /usr/local/bin/restore-test.sh

#!/bin/bash
# /usr/local/bin/backup-monitor.sh
# バックアップの健全性を監視

BACKUP_ROOT="/backup/daily"
MAX_AGE_HOURS=26  # 26時間以内にバックアップがあるはず
S3_BUCKET="s3://my-website-backup"

# 1. ローカルバックアップの最終実行時間をチェック
LATEST_BACKUP=$(ls -td ${BACKUP_ROOT}/*/ | head -1)
if [ -z "${LATEST_BACKUP}" ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data '{"text": "❌ アラート: ローカルバックアップが見つかりません"}' \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
  exit 1
fi

BACKUP_AGE=$(( ( $(date +%s) - $(stat -c %Y ${LATEST_BACKUP}) ) / 3600 ))

if [ ${BACKUP_AGE} -gt ${MAX_AGE_HOURS} ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data "{\"text\": \"⚠️  警告: ローカルバックアップが${BACKUP_AGE}時間前です\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
fi

# 2. S3バックアップの最終実行時間をチェック
LATEST_S3=$(aws s3 ls ${S3_BUCKET}/ | tail -1 | awk '{print $2}')
# (省略)

# 3. ディスク容量チェック
DISK_USAGE=$(df /backup | tail -1 | awk '{print $5}' | sed 's/%//')
if [ ${DISK_USAGE} -gt 80 ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data "{\"text\": \"⚠️  警告: バックアップディスクが${DISK_USAGE}%使用中\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
fi

echo "✅ バックアップ監視: 正常"

# バックアップ運用マニュアル
最終更新: 2024-01-15

## 1. バックアップ構成の概要

### 3-2-1-1-0ルール実装状況
✓ 3つのコピー
  - 本番サーバー（/var/www/html）
  - ローカルバックアップ（/backup/daily）
  - S3バックアップ（s3://my-website-backup）

✓ 2種類のメディア
  - HDD（本番サーバー内蔵）
  - クラウドストレージ（AWS S3）

✓ 1つのオフサイト
  - AWS S3（東京リージョン）

✓ 1つのイミュータブル/オフライン
  - S3 Object Lock（90日間削除不可）
  - 外付けHDD（週次、エアギャップ）

✓ 0エラー検証
  - 毎週日曜日午前2時に自動リストアテスト

## 2. バックアップスケジュール

| 種類 | 頻度 | 実行時刻 | 保持期間 | スクリプト |
|------|------|----------|----------|-----------|
| ローカル | 毎日 | 03:00 | 30日 | /usr/local/bin/daily-backup.sh |
| S3アップロード | 毎日 | 04:00 | 90日 | /usr/local/bin/backup-to-s3.sh |
| エアギャップ | 毎週日曜 | 02:00 | 4週間 | /usr/local/bin/airgap-backup.sh |
| リストアテスト | 毎週日曜 | 02:30 | - | /usr/local/bin/restore-test.sh |

## 3. 緊急時の復元手順

### 3.1 Webサイトファイルの復元

```bash
# 1. 最新バックアップを確認
ls -lh /backup/daily/

# 2. バックアップを展開
cd /var/www
tar -xzf /backup/daily/20240115-030001/website-files.tar.gz

# 3. 権限を修正
chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html

# 4. Nginxを再起動
systemctl restart nginx
```

### 3.2 データベースの復元

```bash
# 1. データベースを削除（必要な場合）
mysql -u root -e "DROP DATABASE IF EXISTS wordpress_db;"
mysql -u root -e "CREATE DATABASE wordpress_db;"

# 2. バックアップから復元
gunzip < /backup/daily/20240115-030001/database.sql.gz | \
  mysql -u root wordpress_db

# 3. 確認
mysql -u root -e "USE wordpress_db; SHOW TABLES;"
```

### 3.3 S3からの復元（ローカルバックアップが使用不可の場合）

```bash
# 1. S3から最新バックアップをダウンロード
aws s3 sync s3://my-website-backup/20240115-030001/ /tmp/restore/

# 2. 以降は上記と同じ手順
```

## 4. 監視とアラート

### 4.1 日次チェック項目
- [ ] Slackに「✅ 日次バックアップ完了」通知が届いている
- [ ] Slackに「✅ S3バックアップ完了」通知が届いている

### 4.2 週次チェック項目
- [ ] Slackに「✅ 週次リストアテスト完了」通知が届いている
- [ ] エアギャップバックアップの外付けHDDを金庫に保管した

### 4.3 月次チェック項目
- [ ] バックアップログを確認（/var/log/backup.log）
- [ ] S3のコストを確認（AWS Billing Dashboard）
- [ ] ディスク容量を確認（df -h /backup）

## 5. トラブルシューティング

### Q1: バックアップが失敗した場合
1. ログファイルを確認: `tail -100 /var/log/backup.log`
2. ディスク容量を確認: `df -h`
3. エラー内容をSlackで報告
4. 手動でバックアップを実行: `/usr/local/bin/daily-backup.sh`

### Q2: リストアテストが失敗した場合
1. テストログを確認: `cat /var/log/restore-test.log`
2. バックアップファイルの整合性確認: `sha256sum -c checksums.txt`
3. 別の日付のバックアップでテスト
4. 問題が続く場合は、バックアップスクリプトを見直す

### Q3: S3アップロードが失敗した場合
1. AWS認証情報を確認: `aws configure list`
2. S3バケットへのアクセス権限確認
3. ネットワーク接続を確認
4. 手動でアップロード: `/usr/local/bin/backup-to-s3.sh`

## 6. 連絡先

### 緊急連絡先
- サーバー管理者: 山田太郎 (090-XXXX-XXXX)
- バックアップ責任者: 佐藤花子 (080-XXXX-XXXX)

### ベンダー連絡先
- AWS サポート: https://console.aws.amazon.com/support/
- サーバーホスティング: support@example.com

# rsyncで差分バックアップ
rsync -avz --delete \
  /var/www/html/ \
  /backup/incremental/$(date +%Y%m%d)/

# 前日との差分のみバックアップされるため、容量削減

# .gitignoreのようなexcludeリストを作成
# /etc/backup-exclude.txt
*.log
*.tmp
/var/www/html/wp-content/cache/*
/var/www/html/node_modules/*
/var/www/html/.git/*

# tarコマンドで除外
tar -czf backup.tar.gz \
  --exclude-from=/etc/backup-exclude.txt \
  /var/www/html/

# CPUとディスクI/Oの優先度を下げて実行
nice -n 19 ionice -c 3 /usr/local/bin/daily-backup.sh

#!/bin/bash
# エックスサーバーからS3へのバックアップ
# SSH接続後に実行

XSERVER_HOME="/home/ユーザー名"
DOMAIN="example.com"
PUBLIC_HTML="${XSERVER_HOME}/${DOMAIN}/public_html"

# Webファイルをtar圧縮
tar -czf /tmp/backup-$(date +%Y%m%d).tar.gz ${PUBLIC_HTML}

# S3にアップロード
aws s3 cp /tmp/backup-$(date +%Y%m%d).tar.gz \
  s3://my-backup-bucket/xserver/

# 一時ファイルを削除
rm /tmp/backup-$(date +%Y%m%d).tar.gz

#!/bin/bash
# さくらインターネット向けバックアップ
# データベースはコントロールパネルでホスト名・ユーザー名を確認

DB_HOST="mysqlXX.db.sakura.ne.jp"
DB_USER="さくらのユーザー名"
DB_PASS="データベースパスワード"
DB_NAME="データベース名"

mysqldump \
  -h ${DB_HOST} \
  -u ${DB_USER} \
  -p${DB_PASS} \
  --single-transaction \
  ${DB_NAME} | gzip > sakura-db-$(date +%Y%m%d).sql.gz

#!/bin/bash
# ConoHa VPS向け完全バックアップスクリプト

# 1. Webファイル
tar -czf /backup/web-$(date +%Y%m%d).tar.gz /var/www/html

# 2. MySQL全データベース
mysqldump --all-databases \
  --single-transaction \
  | gzip > /backup/mysql-all-$(date +%Y%m%d).sql.gz

# 3. Nginx設定
tar -czf /backup/nginx-conf-$(date +%Y%m%d).tar.gz /etc/nginx

# 4. Let's Encrypt証明書
tar -czf /backup/ssl-$(date +%Y%m%d).tar.gz /etc/letsencrypt

# 5. S3アップロード
aws s3 sync /backup/ s3://my-vps-backup/$(hostname)/

# OpenSSLでバックアップを暗号化
openssl enc -aes-256-cbc -salt \
  -in backup.tar.gz \
  -out backup.tar.gz.enc \
  -pass pass:${ENCRYPTION_PASSWORD}

# 復号化
openssl enc -d -aes-256-cbc \
  -in backup.tar.gz.enc \
  -out backup.tar.gz \
  -pass pass:${ENCRYPTION_PASSWORD}

# S3バケットのパブリックアクセスをブロック
aws s3api put-public-access-block \
  --bucket your-backup-bucket \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# AWS Secrets Managerを使用
aws secretsmanager create-secret \
  --name prod/backup/db-password \
  --secret-string "your-secure-password"

# スクリプトから取得
DB_PASSWORD=$(aws secretsmanager get-secret-value \
  --secret-id prod/backup/db-password \
  --query SecretString \
  --output text)

# S3バケットのバージョニング有効化
aws s3api put-bucket-versioning \
  --bucket your-backup-bucket \
  --versioning-configuration Status=Enabled

# オブジェクトロック設定（削除防止）
aws s3api put-object-lock-configuration \
  --bucket your-backup-bucket \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "GOVERNANCE",
        "Days": 30
      }
    }
  }'

ROI = (期待損失削減額 - バックアップコスト) / バックアップコスト × 100
    = (¥350,000 - ¥32,400) / ¥32,400 × 100
    = 980%

つまり、¥32,400の投資で¥350,000の損失を回避できる
→ 約10倍のリターン

# ライフサイクルポリシーで自動的に安価なストレージクラスへ移行
aws s3api put-bucket-lifecycle-configuration \
  --bucket your-backup-bucket \
  --lifecycle-configuration '{
    "Rules": [
      {
        "Id": "MoveToIA",
        "Status": "Enabled",
        "Transitions": [
          {
            "Days": 30,
            "StorageClass": "STANDARD_IA"
          },
          {
            "Days": 90,
            "StorageClass": "GLACIER"
          },
          {
            "Days": 365,
            "StorageClass": "DEEP_ARCHIVE"
          }
        ]
      },
      {
        "Id": "DeleteOldBackups",
        "Status": "Enabled",
        "Expiration": {
          "Days": 1095
        }
      }
    ]
  }'

# rsyncの増分バックアップで、変更ファイルのみ転送
rsync -avz --link-dest=${YESTERDAY_BACKUP} \
  /var/www/html/ \
  ${TODAY_BACKUP}/

# 結果：初回は100GB転送、2回目以降は1-5GB程度に削減

# gzip圧縮（高速、圧縮率60%程度）
tar -czf backup.tar.gz /var/www/html

# xz圧縮（低速、圧縮率70-80%）
tar -cJf backup.tar.xz /var/www/html

# データベースはgzipで十分（SQLは高圧縮率）
mysqldump database_name | gzip > db.sql.gz
# 圧縮率：通常80-90%削減

# CloudWatch Alarmでバックアップの異常を検知
aws cloudwatch put-metric-alarm \
  --alarm-name BackupFailureAlert \
  --alarm-description "Backup failed or not executed" \
  --metric-name BackupSuccessCount \
  --namespace CustomMetrics \
  --statistic Sum \
  --period 86400 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789:BackupAlert