database-backup

データベースのバックアップ

このスキルを使用すると、AI エージェントが PostgreSQL、MySQL、MongoDB にわたるデータベースのバックアップ戦略を計画し、実行できます。エージェントは適切なバックアップの種類（フル、増分、差分、またはポイントインタイム）を選択し、圧縮と暗号化を含むバックアップスクリプトを生成し、cron などのツールを使用した自動スケジュールを設定し、保持ポリシーを定義して、リストアテストを通じてバックアップの整合性を確認します。

ワークフロー

1. バックアップ要件を評価する： データベースの種類、サイズ、許容されるデータ損失時間（目標復旧時点）、許容されるダウンタイム（目標復旧時間）を特定します。バックアップに一貫性が必要か（アプリケーションレベルのロックまたはスナップショットを使用するか）、またバックアップ中にデータベースが短時間のロックに耐えられるかを確認します。

2. バックアップ戦略を選択する： 要件に基づいて適切なバックアップの種類を選択します。フルバックアップはデータベース全体を取得するため、リストアが最も簡単ですが、作成には最も時間がかかります。増分バックアップは前回のバックアップ以降の変更のみを取得するため、時間とストレージを節約できます。差分バックアップは前回のフルバックアップ以降の変更を取得し、両者の中間的な選択肢となります。ポイントインタイムリカバリ（PITR）は、先行書き込みログまたは oplog を使用して任意の時点にリストアする方式で、RPO を最小限に抑えられます。

3. バックアップスクリプトを生成する： 対象のデータベースに適したバックアップツールを呼び出すシェルスクリプトを作成します。圧縮（gzip、lz4、または zstd）、任意の暗号化（GPG または OpenSSL）、タイムスタンプ付きファイル名、終了コードを使ったエラー処理を含めます。監視できるように、スクリプトで出力をログに記録します。

4. スケジュールと保持を設定する： cron、systemd タイマー、またはタスクスケジューラーを使用して自動実行を設定します。保持ポリシー（例：日次バックアップを7個、週次バックアップを4個、月次バックアップを12個保持）を定義し、ストレージ使用量を管理するために期限切れのバックアップを削除します。

5. バックアップの整合性を確認する： 各バックアップの後に、ファイルが空でないこととチェックサムが有効であることを確認します。バックアップから実際にリカバリできることを確かめるため、定期的にステージング環境へテストリストアを実施します。検証に失敗した場合はアラートを送信します。

6. 文書化と監視を行う： バックアップスケジュール、保持ポリシー、保存場所、リストア手順を記録します。Prometheus、Datadog などのツール、または簡易的なメール通知を使用して、バックアップの未実行や失敗を知らせる監視アラートを設定します。

対応技術

• PostgreSQL： PITR 用の pg_dump、pg_basebackup、WAL アーカイブ
• MySQL： PITR 用の mysqldump、mysqlpump、Percona XtraBackup、binlog
• MongoDB： PITR 用の mongodump、mongorestore、ファイルシステムスナップショット、oplog
• 圧縮： gzip、lz4、zstd、pigz
• 暗号化： GPG、OpenSSL AES-256
• ストレージ： ローカルディスク、AWS S3、Google Cloud Storage、Azure Blob Storage

使用方法

データベースの種類、名前、接続情報をエージェントに伝えてください。RPO/RTO の要件、希望する保存先、暗号化が必要かどうかを指定してください。エージェントは、スクリプト、スケジュール、保持ポリシー、検証手順を含む完全なバックアップソリューションを生成します。

例

例 1：PostgreSQL のフルバックアップと cron スケジュール

リクエスト： PostgreSQL データベースの夜間フルバックアップを設定してください。保持期間は30日とし、圧縮してローカルのバックアップディレクトリにアップロードしてください。

#!/usr/bin/env bash
# pg_backup.sh — Nightly PostgreSQL full backup
set -euo pipefail

DB_NAME="production"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/postgresql"
RETENTION_DAYS=30
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${TIMESTAMP}.sql.gz"

mkdir -p "$BACKUP_DIR"

echo "[$(date)] Starting backup of database '${DB_NAME}'..."
pg_dump -U "$DB_USER" -h localhost -Fc "$DB_NAME" | gzip > "$BACKUP_FILE"

# Verify the backup file is non-empty
if [ ! -s "$BACKUP_FILE" ]; then
    echo "[$(date)] ERROR: Backup file is empty. Aborting." >&2
    exit 1
fi

FILE_SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
echo "[$(date)] Backup complete: ${BACKUP_FILE} (${FILE_SIZE})"

# Clean up backups older than retention period
find "$BACKUP_DIR" -name "${DB_NAME}_*.sql.gz" -mtime +${RETENTION_DAYS} -delete
echo "[$(date)] Expired backups removed (older than ${RETENTION_DAYS} days)."

cron エントリー（毎日午前2時に実行）：

0 2 * * * /usr/local/bin/pg_backup.sh >> /var/log/pg_backup.log 2>&1

例 2：MongoDB のバックアップとリストア手順

リクエスト： MongoDB レプリカセットをバックアップし、リストア手順を文書化してください。

バックアップスクリプト：

#!/usr/bin/env bash
# mongo_backup.sh — MongoDB replica set backup
set -euo pipefail

: "${MONGO_URI:?Set MONGO_URI through the secret manager or environment}"
BACKUP_DIR="/var/backups/mongodb"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DUMP_DIR="${BACKUP_DIR}/dump_${TIMESTAMP}"

mkdir -p "$BACKUP_DIR"

echo "[$(date)] Starting mongodump..."
mongodump --uri="$MONGO_URI" --oplog --out="$DUMP_DIR"

# Compress the dump directory
tar -czf "${DUMP_DIR}.tar.gz" -C "$BACKUP_DIR" "dump_${TIMESTAMP}"
tar -tzf "${DUMP_DIR}.tar.gz" >/dev/null

# Refuse cleanup unless the resolved path is the expected timestamped child.
case "$DUMP_DIR" in
  "$BACKUP_DIR"/dump_[0-9]*) rm -rf -- "$DUMP_DIR" ;;
  *) echo "Refusing unsafe cleanup path: $DUMP_DIR" >&2; exit 1 ;;
esac

echo "[$(date)] Backup complete: ${DUMP_DIR}.tar.gz"

# Retain only the last 14 backups
ls -t ${BACKUP_DIR}/dump_*.tar.gz | tail -n +15 | xargs -r rm --

リストア手順：

# 1. Extract the backup archive
tar -xzf /var/backups/mongodb/dump_20250115_020000.tar.gz -C /tmp/

# 2. Restore to the target MongoDB instance
: "${RESTORE_MONGO_URI:?Set RESTORE_MONGO_URI through the secret manager or environment}"
: "${RESTORE_TARGET_CONFIRMED:?Set RESTORE_TARGET_CONFIRMED=yes only after verifying the target is the authorized restore environment}"
[ "$RESTORE_TARGET_CONFIRMED" = "yes" ] || { echo "Restore target is not confirmed" >&2; exit 1; }
mongorestore --uri="$RESTORE_MONGO_URI" \
  --oplogReplay --drop /tmp/dump_20250115_020000/

# 3. Verify collections and document counts
mongosh --eval "db.adminCommand({listDatabases: 1})"

ベストプラクティス

• 定期的にリストアをテストします — 一度もリストアしたことがないバックアップは、信頼できるバックアップとは言えません。ステージング環境へのリストア訓練を毎月予定してください。
• バックアップは保存時と転送時に暗号化します。特にオフサイトやクラウドストレージに保存する場合は、GPG または AES-256 を使用してください。暗号化キーをバックアップと一緒に保存しないでください。
• --oplog フラグ（MongoDB）または WAL アーカイブ（PostgreSQL）を使用してポイントインタイムリカバリーを有効にすると、潜在的なデータ損失を大幅に抑えられます。
• バックアップは別の障害ドメインに保存します — 別のサーバー、アベイラビリティーゾーン、またはクラウドリージョンに保存すれば、単一のインフラ障害でデータベースとバックアップの両方が失われるのを防げます。
• アラートでバックアップジョブを監視します — 通知がないことは成功を意味しません。バックアップの欠落、サイズが 0 バイトのファイル、または一致しないチェックサムについてアラートを設定してください。
• リストア手順を正確に文書化します。正確なコマンド、想定所要時間、担当者を記載し、プレッシャーのかかる状況でも推測に頼らず復旧できるようにしてください。

安全性と権限

• まず設定を確認し、リストア計画を立ててください。対象環境を明示した明確な許可を得ずに、スケジュールを設定したり、期限切れのバックアップを削除したり、データをアップロードしたり、リストアを開始したりしないでください。
• --drop などのリストアコマンドは破壊的な操作として扱ってください。対象を特定して独立して確認し、意図した隔離済みのリストア先であることを確認し、該当する場合はリストア前のリカバリーポイントを取得してください。対象を特定できない場合は中止してください。
• 認証情報をスクリプト、コマンド出力、ログ、生成されたサンプルに含めないでください。最小権限のバックアップ用およびリストア用 ID とともに、シークレットマネージャーからの注入、または保護されたクライアント設定を優先してください。
• リストア訓練の間、元のバックアップとそのチェックサムを保持してください。アーカイブの一覧表示やチェックサムの検証だけを根拠に復旧可能と報告しないでください。代表的なリストアを検証し、アプリケーションレベルの不変条件も確認してください。

エッジケース

• データベースのサイズが大きく、ディスク容量を超える場合： 使用可能なローカルストレージより大きいデータベースでは、バックアップをオブジェクトストレージに直接ストリーミングします（例：pg_dump | gzip | aws s3 cp - s3://bucket/backup.gz）。これにより、ローカルディスクの容量不足を回避できます。
• バックアップ中も書き込みが継続する場合： 書き込みが継続していても整合性のあるポイントインタイムバックアップを取得できるように、pg_dump では --snapshot を、MongoDB では --oplog を使用してください。MySQL では、ロックせずに InnoDB のホットバックアップを取得するために Percona XtraBackup を使用してください。
• 暗号化されたデータベースのバックアップ： Transparent Data Encryption（TDE）が有効になっている場合は、暗号化キーを別途バックアップし、バックアッププロセスで暗号化されたデータをリストア可能な形式で取得できるようにしてください。
• リージョン間レプリケーションの遅延： レプリカからバックアップを取得する場合は、古いデータを取得しないよう、バックアップを開始する前にレプリケーション遅延がゼロ、またはほぼゼロであることを確認してください。
• バックアップ認証情報のローテーション： 認証情報はスクリプトにハードコードせず、シークレットマネージャー（Vault、AWS Secrets Manager）に保存してください。また、バックアップスクリプトが手動更新なしで認証情報のローテーションに対応できるようにしてください。