バックアップ・復旧
Bazbiiシステムのバックアップ方針と災害復旧計画を説明します。
バックアップの概要
バックアップ対象
- データベース: PostgreSQLのデータ
- 設定ファイル: Kubernetes manifests、環境変数
- ログ: 重要なログ（必要に応じて）
バックアップの目的
- データ保護: データ損失の防止
- 障害復旧: 障害発生時のデータ復旧
- 監査対応: 監査ログの保持
データベースバックアップ
バックアップ方針
バックアップ頻度
- フルバックアップ: 毎日1回（深夜）
- 増分バックアップ: 1時間ごと（検討中）
- トランザクションログ: 継続的なアーカイブ
保持期間
- フルバックアップ: 30日間
- 増分バックアップ: 7日間
- トランザクションログ: 7日間
バックアップ方法
PostgreSQLのバックアップ
# pg_dumpでバックアップ
pg_dump -h postgres-host -U postgres -d bazbii \
-F c -f backup_$(date +%Y%m%d_%H%M%S).dump
# 圧縮して保存
gzip backup_*.dump
Kubernetes CronJobでの自動バックアップ
apiVersion: batch/v1
kind: CronJob
metadata:
name: postgres-backup
spec:
schedule: "0 2 * * *" # 毎日2時
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: postgres:15
command:
- /bin/sh
- -c
- |
pg_dump -h $PGHOST -U $PGUSER -d $PGDATABASE \
-F c > /backup/backup_$(date +%Y%m%d).dump
env:
- name: PGHOST
value: postgres
- name: PGUSER
valueFrom:
secretKeyRef:
name: postgres-secret
key: username
volumeMounts:
- name: backup-storage
mountPath: /backup
volumes:
- name: backup-storage
persistentVolumeClaim:
claimName: backup-pvc
restartPolicy: OnFailure
バックアップの検証
バックアップの整合性確認
# バックアップファイルの確認
ls -lh backup_*.dump
# バックアップの内容確認（メタデータのみ）
pg_restore -l backup_20240101_020000.dump
# テスト環境でリストアテスト
pg_restore -h test-postgres -U postgres -d bazbii_test \
--clean --if-exists backup_20240101_020000.dump
定期テスト
- 月次: バックアップのリストアテスト
- 四半期: 災害復旧訓練（DRテスト）
復旧手順
データベースの復旧
ポイントインタイムリカバリ（PITR）
PostgreSQLのWAL（Write-Ahead Log）を使用した復旧：
# 1. ベースバックアップのリストア
pg_restore -h postgres -U postgres -d bazbii \
--clean --if-exists backup_20240101_020000.dump
# 2. WALアーカイブの適用（特定の時点まで）
# recovery.conf または postgresql.conf で設定
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2024-01-01 10:30:00'
フルリストア
# バックアップから完全復旧
pg_restore -h postgres -U postgres -d bazbii \
--clean --if-exists backup_20240101_020000.dump
# 復旧後の確認
psql -h postgres -U postgres -d bazbii -c "SELECT count(*) FROM posts;"
復旧時間目標（RTO）と復旧ポイント目標（RPO）
RTO（Recovery Time Objective）
- 目標: 4時間以内
- 現実的: 8時間以内
RPO（Recovery Point Objective）
- 目標: 1時間以内のデータ損失
- 現実的: 24時間以内のデータ損失
復旧シナリオ
シナリオ1: データベースサーバーの障害
- 新しいデータベースサーバーの起動
- 最新のバックアップからリストア
- WALアーカイブの適用（可能な場合）
- アプリケーションの接続先変更
- 動作確認
シナリオ2: データの誤削除
- 影響範囲の特定: どのデータが削除されたか
- バックアップの選択: 削除前の時点のバックアップ
- テスト環境でのリストアテスト
- 本番環境へのリストア
- データの整合性確認
シナリオ3: データの不整合
- 不整合の範囲を特定
- トランザクションログの確認
- 整合性を保つ範囲でリストア
- 不足データの手動復旧（必要に応じて）
災害復旧（DR）計画
DR環境の構成
プライマリ環境
- リージョン: 東京
- データベース: PostgreSQL（マスター）
- アプリケーション: Kubernetesクラスター
セカンダリ環境（将来構築予定）
- リージョン: 大阪（または別リージョン）
- データベース: PostgreSQL（スタンバイ、ストリーミングレプリケーション）
- アプリケーション: Kubernetesクラスター（スタンバイ）
DR手順
1. フェイルオーバーの判断
以下の場合はフェイルオーバーを検討：
- プライマリ環境の完全停止
- データベースの完全な障害
- リージョン全体の障害
2. セカンダリ環境への切替
# セカンダリ環境をプライマリに昇格
kubectl apply -f infra/k8s/overlays/dr/
# DNS切り替え（Cloudflare）
# api.bazbii.app → セカンダリ環境のIP
# 動作確認
curl https://api.bazbii.app/healthz
3. データの整合性確認
- データベースの整合性チェック
- アプリケーションの動作確認
- ユーザー影響の確認
バックアップの監視
バックアップ成功の確認
# バックアップジョブの確認
kubectl get jobs -n backup
# バックアップファイルの確認
kubectl exec backup-pod -- ls -lh /backup/
# バックアップサイズの確認
kubectl exec backup-pod -- du -sh /backup/
アラート設定
- バックアップ失敗: バックアップジョブの失敗時にアラート
- バックアップサイズ異常: 通常と大きく異なる場合にアラート
- バックアップ古すぎ: 24時間以上更新されていない場合にアラート
バックアップのベストプラクティス
1. 3-2-1ルール
- 3: データの3つのコピー
- 2: 異なる2つのメディア
- 1: 1つのオフサイトバックアップ
2. バックアップの暗号化
# バックアップの暗号化
pg_dump -h postgres -U postgres -d bazbii | \
gpg --encrypt --recipient backup@bazbii.app > backup.dump.gpg
3. バックアップの検証
- 定期的なリストアテスト
- バックアップファイルの整合性確認
4. オフサイトバックアップ
- クラウドストレージへの保存（S3、GCSなど）
- 別リージョンへのレプリケーション