planning-disaster-recovery について
planning-disaster-recovery は、インフラやデータベースのチーム向けに、バックアップ、レプリケーション、フェイルオーバー、復旧テストを案内するスキルです。データベース、Kubernetes、クラウドを対象とし、RTO/RPOの計画や自動化例も扱います。
主な機能
- 01RTO/RPO目標と復旧計画の策定
- 02データベースのバックアップとポイントインタイムリカバリ
- 03Kubernetesクラスターのバックアップと復元
- 04クロスリージョンレプリケーションとフェイルオーバー方式
- 05カオス実験と復旧訓練
- 06バックアップ監視・保持・コンプライアンス確認
活用シーン
- 01重要システムの復旧目標の設定
- 02データベースのバックアップとポイントインタイムリカバリの構成
- 03Kubernetesやリージョン障害からの復旧手順の訓練
- 04バックアップの整合性と保持ポリシーの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ancoleman/ ai-design-components --skill planning-disaster-recoveryインストール後、Claude Code で/planning-disaster-recoveryを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
outputs.yamlexamples/chaos/db-failover-test.shregion-failure-test.shexamples/postgresql/pgbackrest-config/README.mdexamples/runbooks/database-failover.mdregion-failover.mdreferences/chaos-engineering.mdcloud-dr-patterns.mdcompliance-retention.mdcross-region-replication.mddatabase-backups.mdkubernetes-dr.mdrto-rpo-planning.mdrunbook-automation.mdscripts/check-retention.shdr-drill.shgenerate-dr-report.shtest-restore.shvalidate-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 の本番環境 | pgBackRest | WAL-G | PITR、圧縮、複数リポジトリ |
| MySQL の本番環境 | Percona XtraBackup | WAL-G | ホットバックアップ、増分バックアップ |
| MongoDB | Atlas Backup | mongodump | 継続的バックアップ、PITR |
| Kubernetes クラスター | Velero | ArgoCD + Git | PV スナップショット、スケジューリング |
| ファイル/オブジェクトのバックアップ | Restic | Duplicity | 暗号化、重複排除 |
| リージョン間レプリケーション | Aurora Global DB | RDS 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
クロスリージョンレプリケーションのパターン
| パターン | RTO | RPO | コスト | ユースケース |
|---|---|---|---|---|
| アクティブ・アクティブ | < 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
コンプライアンスと保持期間
| 規制 | 保持期間 | 要件 |
|---|---|---|
| GDPR | 1~7 年 | EU 内のデータ保管、消去権 |
| SOC 2 | 1 年以上 | 安全な削除、アクセス制御 |
| HIPAA | 6 年 | 暗号化、PHI の保護 |
| PCI DSS | 3 か月~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:コンプライアンスレポートを作成します