---

name: plan-backup-dr description: > Plan-only audit of whether a project can actually recover from data loss, not just whether backups exist. Use when "can we recover if the DB dies", "audit our backups", "what's our RPO/RTO", or "disaster recovery". license: MIT effort: high

plan-backup-dr — Recovery capability plan

Degree of freedom: HIGH — prove restore, quantify RPO/RTO, plan. Stay plan-only. No PITR toggles or prod-writing drills until approved.

Role: Platform / disaster-recovery engineer.

Task: Prove restore works, quantify RPO/RTO, emit plan-backup-dr.md. Audit & plan only — no PITR toggles, lifecycle edits, or drills that write to prod until approved.

Backup existence is not recovery capability. An untested backup is a hope.

This skill vs neighbors

Skill	Owns
plan-backup-dr (this)	Can you restore? RPO/RTO, drill evidence, SPOF
plan-data-integrity	Stop destructive ops going forward (unguarded DELETE/DROP)
audit-env-parity	Staging pointing at prod data (blast-radius setup)
audit-infra-cost	Backup retention that silently explodes the bill
plan-secrets-audit	Credential exposure — not "can I reconstruct secrets after loss"

Do not fire for "is this migration safe / agent might delete prod" → plan-data-integrity. That skill prevents wipe; this one recovers after one.

How to reason (every plan item)

1. Propose — backup, restore path, drill, or off-provider export
2. Risk — worst-case in plain language ("lose up to a day of uploads")
3. Keep-working — stores that already have a proven restore
4. Phase — P0 / P1 / P2 (do not execute)

Worked example

Propose: run one isolated restore drill of the primary DB; write the runbook from what you actually did. Risk: daily snapshot exists, never restored — RPO 24h is a hope, RTO unbounded. Keep-working: object-storage versioning already on. Phase: P0 — no proven restore. Target: drill into an isolated env, never over prod.

---

Phase 0 — Map the recovery surface [HIGH freedom]

For each stateful thing, find backup and restore:

• Primary DB (Supabase/Postgres): PITR? snapshots? retention? who restores?
• Object storage: versioning? lifecycle that deletes? backed up at all?
• Secrets & config: reconstructable if the account vanished?
• Auth users: identities recoverable, or only app rows?
• External state: Stripe, third-party subs, DNS, domain
• Code & IaC: reproducible from repo, or dashboard-only?

---

Phase 1 — Audit recovery reality [HIGH freedom]

RPO — Real gap between backups. Daily snapshot = up to 24h gone. PITR = seconds. State the number, not the aspiration.

RTO — Walk the actual restore runbook. No runbook → RTO is unbounded.

Restore drill — Evidence a restore succeeded and was verified. None → P0 is "run one end-to-end drill" (into an isolated env, never over prod).

SPOF — One provider/region/account. Billing/ToS/compromise suspends everything? Off-provider export?

Silent loss — Lifecycle rules or ON DELETE CASCADE that erase more than intended (cross-check plan-data-integrity). Backups that expire before anyone would notice slow corruption.

Bus-factor — Restore credentials behind a login only one person has.

---

Phase 2 — Phased DR plan (approve before executing) [HIGH freedom — plan only]

• P0 — no proven restore; any store with no backup; secrets unrecoverable; bus-factor-1
• P1 — RPO worse than the data justifies; no written runbook; no off-provider export
• P2 — RTO reduction, automated restore verify, drill cadence

Each item: current state, worst-case in plain language ("lose up to a day of uploads"), target RPO/RTO, concrete change.

Self-critique before the burndown [LOW freedom — do not skip]

1. RPO is a number — not "we have backups"
2. Drill evidence or P0 — absence is the finding
3. No prod writes — isolated env only, and only after approval
4. Right owner — unguarded DELETE → plan-data-integrity
5. Do not cut restore to save cost (audit-infra-cost must not expire backups)

Definition of Done

• Every stateful store has backup AND restore method
• RPO stated as a real number per store
• RTO estimated from the actual (or absent) runbook
• Restore-drill evidence found — or absence flagged P0
• Secrets/config reconstructable
• SPOF + off-provider export status known
• Recovery-access bus-factor assessed
• Plan approved before infra change

Output format

1. Recovery surface — store | backup | restore | RPO | RTO | last drill
2. Findings — issue | worst-case | severity | evidence
3. SPOF map — shared account/region/provider
4. Phased DR plan — P0/P1/P2 with target RPO/RTO
5. Recap and await approval — end the turn with a standalone recap in chat: the two or three highest-impact findings and the first phase to approve. plan-backup-dr.md is the deliverable; write it before the recap. Test restore only into an isolated env.

Related

• plan-data-integrity — prevent wipe; this proves restore
• audit-env-parity — staging vs prod data targeting
• audit-infra-cost — retention vs bill
• plan-secrets-audit — leaked keys, not reconstructability
• workflow-environment-ready — local runnability, not DR