バックアップと復元
マルチリージョン構成でリアルタイムレプリケーションを組んでいても、バックアップは別途必要です。レプリケーションはデータの「コピー」を作りますが、誤操作やデータ破壊もコピーされる からです。
レプリケーションだけでは守れないもの:
・管理者が誤って DELETE FROM users を実行 → レプリカにも即反映
・アプリのバグで全テナントの設定が上書き → レプリカも破壊
・ランサムウェアがデータを暗号化 → レプリカも暗号化
バックアップがあれば:
→ 「昨日の 3:00 時点」にデータを戻せる
クラウドの恩恵: クラウドのマネージド DB では、日次スナップショットの自動取得、PITR（任意の秒単位の時点に復元）、クロスリージョンへの自動コピーがサービスとして提供されます。オンプレミスではこれらを自前で構築する必要があり（テープバックアップ、遠隔地搬送、WAL アーカイブ等）、運用コストが大きく異なります。
何をバックアップするか
| 対象 | 方法 | 頻度 | 保持期間 | RPO への影響 |
|---|---|---|---|---|
| DB（全データ） | スナップショット | 日次 + オンデマンド | 35日〜 | バックアップ間隔分 |
| DB（トランザクションログ） | 継続的バックアップ / PITR | 継続的 | 同上 | 数分（任意の時点に復元可能） |
| アプ リ設定 | Git / IaC | コミットごと | 永久 | 最終コミット時点 |
| テナント設定 | DB に含まれる | DB と同じ | DB と同じ | DB と同じ |
| 秘密情報（鍵、シークレット） | シークレットマネージャー | 変更ごと | バージョン管理 | 最終変更時点 |
| 監査ログ | オブジェクトストレージ | リアルタイム | 法令要件に準拠 | - |
| コンテナイメージ | コンテナレジストリ | ビルドごと | 世代管理 | - |
DB のバックアップ戦略
┌─ 日次スナップショット ─────────────────────────────────┐
│ │
│ 毎日 3:00 UTC に自動取得 │
│ 保持: 35日間 │
│ → 最大 24時間分のデータ損失（RPO = 24時間） │
│ │
├─ PITR（Point-in-Time Recovery）──────────────────────┤
│ │
│ トランザクションログを継続的に保存 │
│ 任意の秒単位の時点に復元可能 │
│ → RPO = 数分（ログの遅延分のみ） │
│ │
│ 例: 「2026-03-29 14:35:00 の状態に戻して」 │
│ → スナップショット + トランザクションログの再生で復元 │
│ │
├─ 手動スナップショット ───────────────────────────────┤
│ │
│ リリース前、メンテナンス前に手動取得 │
│ → ロールバックポイントとして使用 │
│ │
└─────────────────────────────────────────────────────────┘
どこにバックアップするか
原則: バックアップは本番と異なるリージョン / アカウントに保存
❌ 同じリージョン、同じアカウント
→ リージョン障害で本番もバックアップも使えなくなる
→ アカウント侵害でバックアップも削除される
✅ 異なるリージョンにコピー
→ クロスリージョンバックアップ
✅ 異なるアカウントにコピー（推奨）
→ アカウント侵害からも保護
復元手順
DB の復元
1. 復元先を決める
・同一リージョンの新しいクラスタ？
・DR リージョン？
2. スナップショットから復元
・スナップショットを指定 → 新しい DB クラスタが作成される
・元の DB は残る（上書きではない）
3. PITR の場合
・復元時点を指定（例: 2026-03-29 14:35:00 UTC）
・スナップショット + トランザクションログから新クラスタを構築
4. アプリの接続先を切り替え
・新しい DB のエンドポイントをアプリに設定
・または DNS を切り替え
5. 動作確認
・データの整合性確認
・テナントが正常にアクセスできるか
復元時間の目安
| DB サイズ | スナップショット復元 | PITR 復元 |
|---|---|---|
| 10GB | 10〜20分 | 15〜30分 |
| 100GB | 30〜60分 | 45〜90分 |
| 1TB | 2〜4時間 | 3〜5時間 |
復元時間は DB サイズに比例する。 大規模 DB では RTO を満たせない可能性がある → レプリケーション（Pilot Light 以上）を検討。
バックアップの検証
バックアップは「取っている」だけでは意味がない。
「復元できる」ことを定期的に検証する。
検証項目:
□ スナップショットから実際に DB を復元できるか
□ 復元した DB にアプリが接続できるか
□ データの整合性が保たれているか
□ 復元にかかる時間は RTO を満たすか
頻度:
・月次: スナップショット復元テスト
・四半期: PITR 復元テスト
・年次: フル DR テスト（→ Game Day）
やってはいけないこと
❌ バックアップの復元テストをしていない
→ いざというとき「バックアップが壊れていた」が最悪のシナリオ
❌ バックアップを同じリージョン / アカウントにだけ保存
→ 本番と一緒に消える
❌ 秘密情報（DB パスワード等）のバックアップを忘れる
→ DB は復元できたがパスワードがわからない
❌ 復元手順をドキュメント化していない
→ 障害時に「どうやって復元するんだっけ？」
まとめ
バックアップの原則:
1. DB は日次スナップショット + PITR（継続的バックアップ）
2. バックアップは別リージョン / 別アカウントに保存
3. アプリ設定は Git / IaC で管理（バックアップ不要）
4. 秘密情報はシークレットマネージャーでバージョン管理
5. 月次で復元テストを実施（取っているだけでは不十分）
次のステップ
- フェイルオーバー手順: 実際の切り替え手順