mcpField
P
planning-disaster-recovery

planning-disaster-recovery

github.com/ancolemanクラウド・DevOps52574 回インストール46 週間前に更新
リポジトリ

planning-disaster-recovery について

planning-disaster-recovery は、インフラやデータベースのチーム向けに、バックアップ、レプリケーション、フェイルオーバー、復旧テストを案内するスキルです。データベース、Kubernetes、クラウドを対象とし、RTO/RPOの計画や自動化例も扱います。

主な機能

  1. 01RTO/RPO目標と復旧計画の策定
  2. 02データベースのバックアップとポイントインタイムリカバリ
  3. 03Kubernetesクラスターのバックアップと復元
  4. 04クロスリージョンレプリケーションとフェイルオーバー方式
  5. 05カオス実験と復旧訓練
  6. 06バックアップ監視・保持・コンプライアンス確認

活用シーン

  1. 01重要システムの復旧目標の設定
  2. 02データベースのバックアップとポイントインタイムリカバリの構成
  3. 03Kubernetesやリージョン障害からの復旧手順の訓練
  4. 04バックアップの整合性と保持ポリシーの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ancoleman/ai-design-components --skill planning-disaster-recovery

インストール後、Claude Code で/planning-disaster-recoveryを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

outputs.yaml
examples/chaos/
db-failover-test.sh
region-failure-test.sh
examples/postgresql/pgbackrest-config/
README.md
examples/runbooks/
database-failover.md
region-failover.md
references/
chaos-engineering.md
cloud-dr-patterns.md
compliance-retention.md
cross-region-replication.md
database-backups.md
kubernetes-dr.md
rto-rpo-planning.md
runbook-automation.md
scripts/
check-retention.sh
dr-drill.sh
generate-dr-report.sh
test-restore.sh
validate-backup.sh

詳細

災害復旧

目的

データベース、Kubernetes クラスター、クラウドインフラ全体における災害復旧(DR)戦略の設計、バックアップシステムの実装、復旧手順の検証について、包括的なガイダンスを提供します。チームが RTO/RPO 目標を定義し、適切なバックアップツールを選択し、自動フェイルオーバーを構成し、カオスエンジニアリングを通じて DR 機能をテストできるようにします。

このスキルを使用するタイミング

次の場合にこのスキルを呼び出してください。

  • 目標復旧時間(RTO)と目標復旧時点(RPO)を定義するとき
  • ポイントインタイムリカバリ(PITR)を使用したデータベースのバックアップを実装するとき
  • Kubernetes クラスターのバックアップと復元のワークフローを設定するとき
  • 高可用性のためにリージョン間レプリケーションを構成するとき
  • カオス実験を通じて災害復旧手順をテストするとき
  • コンプライアンス要件(GDPR、SOC 2、HIPAA)を満たすとき
  • バックアップの監視とアラートを自動化するとき
  • マルチクラウドの災害復旧アーキテクチャを設計するとき

基本概念

RTO と RPO の基礎

目標復旧時間(RTO): 災害発生後、ビジネスへの影響が許容できなくなるまでの、許容可能な最大停止時間です。

目標復旧時点(RPO): 時間で測定する、許容可能な最大データ損失量です。復旧時にどの時点まで遡る必要があるかを定義します。

重要度の階層:

  • 階層 0(ミッションクリティカル): RTO < 1 時間、RPO < 5 分
  • 階層 1(本番環境): RTO 1~4 時間、RPO 15~60 分
  • 階層 2(重要): RTO 4~24 時間、RPO 1~6 時間
  • 階層 3(標準): RTO > 24 時間、RPO > 6 時間
3-2-1 バックアップルール

データのコピーを 3 つ、異なる 2 種類のメディアに保持し、そのうち1 つをオフサイトに保管します。

実装例:

  • プライマリ:本番データベース
  • セカンダリ:ローカルのバックアップストレージ
  • ターシャリ:クラウドバックアップ(S3/GCS/Azure)
バックアップの種類

フルバックアップ: すべてのデータの完全なコピーです。作成に最も時間がかかりますが、復元は最も速く行えます。

増分バックアップ: 前回のバックアップ以降の変更のみを保存します。作成は最も速いですが、復元にはフルバックアップとすべての増分バックアップが必要です。

差分バックアップ: 前回のフルバックアップ以降の変更を保存します。ストレージ容量と復元速度のバランスが取れています。

継続的バックアップ: WAL/binlog のアーカイブを通じて、リアルタイムまたはほぼリアルタイムでバックアップします。RPO を最も小さくできます。

迅速な判断のためのフレームワーク

ステップ 1:RTO/RPO を戦略に対応付ける
RTO < 1 hour, RPO < 5 min
→ Active-Active replication, continuous archiving, automated failover
→ Tools: Aurora Global DB, GCS Multi-Region, pgBackRest PITR
→ Cost: Highest

RTO 1-4 hours, RPO 15-60 min
→ Warm standby, incremental backups, automated failover
→ Tools: pgBackRest, WAL-G, RDS Multi-AZ
→ Cost: High

RTO 4-24 hours, RPO 1-6 hours
→ Daily full + incremental, cross-region backup
→ Tools: pgBackRest, Velero, Restic
→ Cost: Medium

RTO > 24 hours, RPO > 6 hours
→ Weekly full + daily incremental, single region
→ Tools: pg_dump, mysqldump, S3 versioning
→ Cost: Low
ステップ 2:ユースケースに応じてバックアップツールを選択する
ユースケース主なツール代替ツール主な機能
PostgreSQL の本番環境pgBackRestWAL-GPITR、圧縮、複数リポジトリ
MySQL の本番環境Percona XtraBackupWAL-Gホットバックアップ、増分バックアップ
MongoDBAtlas Backupmongodump継続的バックアップ、PITR
Kubernetes クラスターVeleroArgoCD + GitPV スナップショット、スケジューリング
ファイル/オブジェクトのバックアップResticDuplicity暗号化、重複排除
リージョン間レプリケーションAurora Global DBRDS Read Replicaアクティブ/アクティブ対応

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

pgBackRest を使用した PostgreSQL

ユースケース: RPO を 5 分未満にする必要がある本番 PostgreSQL

クイックスタート: examples/postgresql/pgbackrest-config/ を参照してください。

WAL の継続的なアーカイブと、S3/GCS/Azure へのフル/差分/増分バックアップを構成します。週次のフルバックアップと日次の差分バックアップをスケジュールします。pgbackrest --stanza=main --delta restore で PITR を有効にします。

詳細ガイド: references/database-backups.md#postgresql

Percona XtraBackup を使用した MySQL

ユースケース: ホットバックアップが必要な MySQL の本番環境

クイックスタート: examples/mysql/xtrabackup/ を参照してください。

PITR のために、バイナリログのアーカイブと併せて、フルバックアップ(xtrabackup --backup --parallel=4)と増分バックアップを実行します。復元には、解凍、準備、増分バックアップの適用、コピーし戻す手順が必要です。

詳細ガイド: references/database-backups.md#mysql

MongoDB のバックアップ

クイックスタート: 論理バックアップには mongodump --gzip --numParallelCollections=4 を使用するか、PITR に対応した継続的バックアップには MongoDB Atlas を使用してください。

詳細ガイド: references/database-backups.md#mongodb

Kubernetes の災害復旧

クラスターのバックアップに Velero を使用

クイックスタート: velero install --provider aws --bucket my-backups

PV スナップショットを使用して、スケジュールされたバックアップ(毎日のフルバックアップ、本番名前空間の毎時バックアップ)を設定します。velero restore create --from-backup <name> で復元します。選択的な復元(名前空間のマッピング、ストレージクラスの再マッピング)にも対応しています。

例: examples/kubernetes/velero/ 詳細ガイド: references/kubernetes-dr.md

etcd のバックアップ

クイックスタート: ETCDCTL_API=3 etcdctl snapshot save /backups/etcd/snapshot.db

コントロールプレーンの復旧に備えて、定期的に etcd スナップショットを作成します。復元するには、スナップショットデータを使ってクラスターを再作成する必要があります。

例: examples/kubernetes/etcd/

クラウド別の DR パターン

AWS

主要サービス:

  • RDS:自動バックアップ(保持期間 30 日)、PITR、Multi-AZ
  • Aurora Global DB:自動フェイルオーバーに対応したクロスリージョンのアクティブ・パッシブ構成
  • S3 CRR:SLA 15 分のクロスリージョンレプリケーション(Replication Time Control)

例: examples/cloud/aws/ 詳細ガイド: references/cloud-dr-patterns.md#aws

GCP

主要サービス:

  • Cloud SQL:7 日分のトランザクションログを使用した PITR、保持期間 30 日
  • GCS Multi-Regional:100 マイル以上離れたリージョン間での自動レプリケーション
  • Regional HA:リージョン内の同期レプリケーション

詳細ガイド: references/cloud-dr-patterns.md#gcp

Azure

主要サービス:

  • Azure Backup:柔軟な保持期間(日次/週次/月次/年次)に対応した VM バックアップ
  • Azure Site Recovery:アプリケーション整合性のある 4 時間ごとのスナップショットを使用した、クロスリージョンの VM レプリケーション
  • Geo-Redundant Storage:セカンダリリージョンへの自動レプリケーション

詳細ガイド: references/cloud-dr-patterns.md#azure

クロスリージョンレプリケーションのパターン

パターンRTORPOコストユースケース
アクティブ・アクティブ< 1 分< 1 分高両方のリージョンでトラフィックを処理
アクティブ・パッシブ15~60 分5~15 分中フェイルオーバーに備えたスタンバイ
パイロットライト10~30 分5~15 分低セカンダリインフラを最小限に抑える
ウォームスタンバイ5~15 分5~15 分中~高縮小したセカンダリ環境

実装例:

  • PostgreSQL のストリーミングレプリケーション(アクティブ・パッシブ)
  • Aurora Global Database(アクティブ・アクティブ)
  • ASG のスケールアップ自動化(パイロットライト)

詳細ガイド: references/cross-region-replication.md

災害復旧のテスト

カオスエンジニアリング

目的: 制御された障害注入を通じて、DR 手順を検証します。

テストシナリオ:

  • データベースのフェイルオーバー(プライマリを停止し、昇格にかかる時間を測定)
  • リージョン障害(ネットワークを遮断し、DNS フェイルオーバーを実行)
  • Kubernetes の復旧(名前空間を削除し、Velero から復元)

ツール: Chaos Mesh、Gremlin、Litmus、Toxiproxy

例: examples/chaos/db-failover-test.sh、examples/chaos/region-failure-test.sh 詳細ガイド: references/chaos-engineering.md

自動 DR 訓練

毎月テストを実行:

./scripts/dr-drill.sh --environment staging --test-type full
./scripts/test-restore.sh --backup latest --target staging-db

コンプライアンスと保持期間

規制保持期間要件
GDPR1~7 年EU 内のデータ保管、消去権
SOC 21 年以上安全な削除、アクセス制御
HIPAA6 年暗号化、PHI の保護
PCI DSS3 か月~1 年安全な削除、四半期ごとのレビュー

S3/GCS のライフサイクルポリシーで実装: 30d→Standard-IA、90d→Glacier、365d→Deep Archive

イミュータブルバックアップ: ランサムウェア対策として、S3 Object Lock または Azure Immutable Blob Storage を使用します。

詳細ガイド: references/compliance-retention.md

監視とアラート

主要なメトリクス: バックアップ成功率、所要時間、前回のバックアップからの経過時間、RPO 違反、ストレージ使用率

Prometheus アラート: VeleroBackupFailed、VeleroBackupTooOld、BackupSizeTrend

検証スクリプト:

./scripts/validate-backup.sh --backup latest --verify-integrity
./scripts/check-retention.sh --report-violations
./scripts/generate-dr-report.sh --format pdf

自動化とランブック

バックアップスケジュールの自動化: pgBackRest の Cron(毎週フルバックアップ、毎日差分バックアップ)、Velero のスケジュール(K8s)

DR ランブックの手順: 障害を検知 → セカンダリを確認 → 昇格 → DNS を更新 → 通知 → 記録

詳細ガイド: references/runbook-automation.md

他のスキルとの統合

関連スキル

前提条件:

  • infrastructure-as-code:バックアップインフラストラクチャ、DR リージョンをプロビジョニングします
  • kubernetes-operations:Velero 用の K8s クラスターをセットアップします
  • secret-management:バックアップの暗号化キー、認証情報を管理します

並行して使用するスキル:

  • databases-postgresql:PostgreSQL の設定と運用
  • databases-mysql:MySQL の設定と運用
  • observability:バックアップの監視、アラート
  • security-hardening:バックアップストレージの保護、アクセス制御

利用側のスキル:

  • incident-management:インシデント発生時に DR 手順を実行します
  • compliance-frameworks:規制要件を満たします
スキル連携の例
infrastructure-as-code → secret-management → disaster-recovery → observability
       ↓                        ↓                   ↓                ↓
  Create S3 buckets      Store encryption     Configure backups   Monitor jobs
  Provision databases    keys in Vault        Set up replication  Alert failures
  Setup VPCs             Manage credentials   Test DR drills      Track metrics

ベストプラクティス

推奨事項

✓ 定期的にリストアをテストします(重要なシステムでは毎月) ✓ バックアップの監視とアラートを自動化します ✓ 保存中および転送中のバックアップを暗号化します ✓ 3-2-1 バックアップルールを実施します ✓ RTO/RPO を定義し、測定します ✓ DR を検証するためにカオス実験を実施します ✓ 復旧手順を文書化します ✓ 異なるリージョンにバックアップを保存します ✓ ランサムウェア対策にイミュータブルバックアップを使用します ✓ CI/CD で DR テストを自動化します

禁止事項

✗ テストせずにバックアップが機能すると想定しないでください ✗ すべてのバックアップを単一のリージョンに保存しないでください ✗ 保持ポリシーの定義を省略しないでください ✗ 機密データの暗号化を忘れないでください ✗ クラウドプロバイダーのバックアップだけに頼らないでください ✗ バックアップの監視を怠らないでください ✗ 高負荷時にプライマリデータベースからのみバックアップを実行しないでください ✗ 暗号化キーをバックアップと一緒に保存しないでください

参考ドキュメント

  • RTO/RPO の計画: references/rto-rpo-planning.md
  • データベースのバックアップ: references/database-backups.md
  • Kubernetes の DR: references/kubernetes-dr.md
  • クラウド DR パターン: references/cloud-dr-patterns.md
  • リージョン間レプリケーション: references/cross-region-replication.md
  • カオスエンジニアリング: references/chaos-engineering.md
  • コンプライアンス要件: references/compliance-retention.md
  • ランブックの自動化: references/runbook-automation.md

例

  • ランブック: examples/runbooks/database-failover.md、examples/runbooks/region-failover.md
  • PostgreSQL: examples/postgresql/pgbackrest-config/、examples/postgresql/walg-config/
  • MySQL: examples/mysql/xtrabackup/、examples/mysql/walg/
  • Kubernetes: examples/kubernetes/velero/、examples/kubernetes/etcd/
  • クラウド: examples/cloud/aws/、examples/cloud/gcp/、examples/cloud/azure/
  • カオス: examples/chaos/db-failover-test.sh、examples/chaos/region-failure-test.sh

スクリプト

  • scripts/validate-backup.sh:バックアップの整合性を検証します
  • scripts/test-restore.sh:リストアテストを自動化します
  • scripts/dr-drill.sh:DR ドリル全体を実行します
  • scripts/check-retention.sh:保持ポリシーを検証します
  • scripts/generate-dr-report.sh:コンプライアンスレポートを作成します

コメント