SkillVaultskills Browse all 500 skills

Infrastructure · Version 1.0.0 · Reviewed 2026-08-02

Disaster Recovery Planner

Review and harden RTO and RPO derivation and recovery sequencing with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Turns RTO and RPO targets into a tested recovery plan covering data, dependencies, credentials, DNS, and the human runbook.

₹149 one-time

Get this skill archive

What this skill helps you do

  • RTO and RPO derivation
  • Recovery sequencing
  • Restore verification

How Disaster Recovery Planner works

You provide

RTO and RPO targets, dependencies, and backup config

It inspects

Whether a restore has ever been executed and timed

It decides

Recovery sequence covering credentials, DNS, and data

You verify

A full restore into a clean environment, timed

What it checks first

Disaster Recovery Planner turns RTO and RPO targets into a tested recovery plan covering data, dependencies, credentials, DNS, and the human runbook. Use it when the work involves RTO and RPO derivation, Recovery sequencing, Restore verification.

  1. Whether a restore has actually been executed and timed, which is the only evidence that an RTO is real.
  2. Dependency order during recovery, including credentials, secrets, DNS, and identity providers.
  3. Whether backups are tested for restorability rather than merely for completion.
  4. The RPO implied by replication lag and backup frequency, versus the RPO that was promised.
  5. Whether the recovery procedure depends on systems that would also be down.

Failure modes it recognizes

  • Backups completing successfully for months while being unrestorable due to an encryption key stored only in the failed region.
  • A recovery runbook stored in a wiki hosted in the region that is unavailable.
  • DNS TTL longer than the RTO, making propagation the dominant recovery delay.
  • Secrets and certificates absent from the recovery region, blocking service start.
  • A restore succeeding but with an RPO gap nobody quantified until after the event.
  • Cross-region replication configured for the database but not for object storage the application requires.

Answers it will reject

  • Reporting backup success rate as disaster-recovery readiness.
  • Planning recovery for infrastructure while ignoring identity, DNS, and secret material.
  • Assuming a documented procedure works without an executed rehearsal.
  • Setting RTO and RPO targets by aspiration rather than by tested capability.

Decision rules it applies

  • An untested restore is not a recovery capability; state the tested time as the RTO and the aspiration separately.
  • Store recovery documentation and credentials outside the failure domain they protect against.
  • Lower DNS TTL in advance if failover depends on it; TTL cannot be shortened retroactively.
  • Rehearse on a schedule and treat rehearsal failures as incidents.

Evidence it asks for

  • Execute a full restore into a clean environment and record every step with wall-clock timings.
  • Verify restored data with row counts and application-level checks rather than file size.
  • Test failover with the primary genuinely unavailable, not with a graceful switch.

The method inside

  1. Establish the current state and the constraint that actually limits RTO and RPO derivation.
  2. Separate the requested solution from the underlying problem in recovery sequencing, and name the assumptions carrying the most risk.
  3. Compare only viable options for restore verification against weighted constraints, cost of reversal, and operational ownership.
  4. Commit to a sequenced recommendation with success criteria, guardrails, and the observation that would reverse it.

Deliverables

  • RTO and RPO derivation assessment
  • Recovery sequencing decision and action plan
  • Restore verification verification checklist

Evidence requirements

  • Infrastructure code or configuration
  • Runtime topology and environment constraints
  • Plan, events, policies, and failure symptoms

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

We take nightly backups and replicate to another region. Are we covered for a regional outage?

Expected output

Backups prove data exists; they do not prove you can recover. The steps that usually fail are credential and secret availability in the recovery region, DNS propagation time, and dependency order. Until you have executed a restore and timed it, your RTO is an estimate, not a commitment...

Boundaries and compatibility

Ideal for

  • RTO and RPO derivation: produce a decision or artifact grounded in supplied evidence.
  • Recovery sequencing: produce a decision or artifact grounded in supplied evidence.
  • Restore verification: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Applying infrastructure changes without approval
  • Assuming cloud access or live resource visibility

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.