disaster-recovery-plan skill answers the question that a runbook and a deployment plan deliberately do not: what happens when the primary infrastructure itself is gone? This skill handles the catastrophic scenarios — a region is down, a database is corrupted, a backup was never actually tested, or an attacker has encrypted production data. It defines, in dollars and hours, how much data loss and downtime the business has decided is survivable, then works backward to the backup, replication, and failover architecture required to hit those targets. The recovery drill is treated as the document’s real test of validity, not the document itself.
Type: Workflow · Estimated time: 2–4 hours · Standards: 3-2-1 backup rule; ISO 22301; compliance-friendly for PCI-DSS, SOC 2 · Output file:
.engineering-docs/18-disaster-recovery.md · Conditional skill — include when downtime or data loss has a business or compliance cost, and especially before launch of any system holding financial or critical user data.Best for
Pre-launch compliance
Formalizing recovery commitments before launching a system that holds financial, payment, or otherwise critical data — and satisfying PCI-DSS, SOC 2, or ISO 22301 audit requirements.
Backup reality check
Assessing whether current backup infrastructure can actually meet the business’s downtime and data-loss tolerance, rather than assuming it can.
Infrastructure topology review
Surfacing single points of failure in current infrastructure and mapping each to a DR tier with explicit cost/recovery-speed trade-offs.
Drill schedule creation
Planning and scheduling regular disaster recovery drills and game days so a backup that has never been restored is no longer the plan.
What it produces
The generated DR plan covers every layer from business impact through drill cadence:How to invoke it
Pass the system or service name as the argument. Providing current backup tooling, frequency, hosting details, and any prior outage history gives the agent what it needs to evaluate whether current infrastructure actually meets business RTO/RPO requirements.Example scenarios
Regional outage planning
Regional outage planning
Write a disaster recovery plan in case our primary hosting provider has a regional outageProduces a DR tier assessment, a warm-standby architecture recommendation, and a step-by-step regional failover runsheet covering DNS TTL strategy, database promotion, traffic rerouting, and data integrity validation.Payment ledger RTO/RPO definition
Payment ledger RTO/RPO definition
Define RTO and RPO targets for our payment ledger database and the backup strategy needed to hit themProduces a Business Impact Analysis that quantifies the hourly cost of downtime and data loss, sets RTO/RPO targets backed by that cost, maps the gap between current backup frequency and the required RPO, and recommends the backup architecture to close it.Backup validation and drill schedule
Backup validation and drill schedule
We've never actually tested restoring from backup — help me build a DR plan and drill schedule that fixes thatProduces a live restore drill procedure, a quarterly tabletop exercise template, a drill log table, and the action items needed to verify the current backup strategy before the first drill date.Key concepts
RTO vs. RPO
These are business decisions with a cost curve attached — lower RTO/RPO requires more expensive infrastructure. The skill works backward from business need to infrastructure requirements, not the other way around.
DR tiers
Not every system needs Tier 3. The skill maps each system’s actual business criticality to the cheapest tier that meets its RTO/RPO — a Tier 3 admin dashboard is over-engineering; a Tier 0 payment ledger is a liability.
The 3-2-1 backup rule
Keep 3 copies of data, on 2 different media/storage types, with 1 copy off-site (different provider or region than production). A single provider’s snapshot feature alone does not satisfy this rule — a provider-wide outage or account compromise takes the snapshot with it.Named disaster scenarios
A DR plan must address specific scenarios, not just “something bad happens”:- Regional/provider-wide infrastructure outage — DR runsheet: Section 8.1
- Data corruption or accidental mass deletion — DR runsheet: Section 8.2
- Ransomware / malicious encryption of production data — DR runsheet: Section 8.3
- Critical third-party dependency loss — DR runsheet: Section 8.4
- DNS failover — DR runsheet: Section 8.5
Ransomware-specific procedures
Ransomware requires distinct procedures beyond generic data corruption recovery. The skill enforces isolation first — before any recovery attempt, affected systems are disconnected from the network to prevent lateral spread. It identifies the most recent verified-clean backup (backups taken during the compromise window may also be encrypted), requires forensic preservation before wiping, and mandates full credential rotation before reconnecting. The ransom payment policy and legal/regulatory notification requirements are documented explicitly.Data integrity validation
After any recovery, the plan requires structured validation before declaring recovery complete: row count verification against known-good baselines, file checksum comparison, referential integrity checks for orphaned records, and application-level smoke tests covering critical user journeys. An automated validation script (scripts/dr-validation.sh) captures all checks in a single pass/fail report.
Drills are the real test
A DR plan is a hypothesis until it has been drilled. The skill schedules recovery drills on a fixed cadence and treats any drill failure as more urgent than the document itself. Every drill result — pass or fail — is logged, and every gap found becomes an action item with an owner and deadline.Interview process
The agent conducts a structured interview before drafting, loading prior.engineering-docs/ files first to avoid re-asking known facts:
1
Context loading
Reads existing documents (business-plan, system-architecture, deployment-plan, SLO document) to extract hosting infrastructure, known uptime requirements, and existing backup tooling.
2
Backup reality check (≤ 2–3 questions)
Confirms what is actually backed up today, how often, where backups are stored, and critically — whether a full restore has ever been tested.
3
Business tolerance
In concrete terms: how many hours of downtime and how much data loss would be damaging-but-survivable versus catastrophic for this business?
4
Business impact analysis
Identifies every critical component, classifies its criticality tier, and states the cost of downtime and data loss in concrete terms.
5
RTO/RPO target setting
Sets explicit RTO/RPO per system, driven by the BIA — not by what current infrastructure happens to provide.
6
Backup and replication strategy
Designs the backup/replication architecture required to hit each RPO, applies the 3-2-1 rule, and documents encryption and retention.
7
Failover runsheets and drill schedule
Writes the numbered runsheet per scenario and sets the recurring drill cadence with the first drill scheduled before the plan is marked Approved.
Output structure
The generated.engineering-docs/18-disaster-recovery.md mirrors the full template:
18-disaster-recovery.md (structure)
Handoff
Reads from
1-business-plan.md— business impact of downtime, revenue exposure7-system-architecture.md— infrastructure topology, single points of failure16-deployment-plan.md— current deployment and rollback procedures19-slo-error-budget.md— RTO/RPO alignment with SLO commitments
Feeds into
17-technical-runbook.md— recovery procedures referenced during incidents- Compliance documentation (PCI-DSS, SOC 2, ISO 22301)
- Incident postmortems — DR gaps discovered during incidents
Quality gate
Before marking the planfinal, verify every item in this checklist:
- Every critical system has explicit RTO and RPO targets derived from business impact analysis, not from current infrastructure capability
- The backup strategy for each system satisfies the 3-2-1 rule (3 copies, 2 media types, 1 off-site with a different provider)
- Every disaster scenario in the catalog has a corresponding recovery runsheet with numbered steps, owners, and estimated times
- At least one recovery drill (tabletop or live restore) is scheduled before the plan is marked
Approved, and the drill log table exists - The communication plan defines internal and external notification responsibilities at each stage
- Ransomware-specific recovery procedures are documented, including isolation steps and forensic preservation
- Data integrity validation procedures (row counts, checksums, referential integrity, smoke tests) are documented for post-recovery verification
- Cost modeling is presented per DR tier, showing the cost/downtime trade-off
- Recovery priority ordering is defined based on BIA, with dependency mapping
- DNS failover strategy is documented (TTL, global LB routing, CDN failover behavior)
- Backup encryption key management is documented (storage, rotation, access control, KMS backup/escrow)
- Third-party dependency DR is addressed (inventory, impact, fallback, provider DR review)