Whether this system could actually come back from data loss — whether backups exist, cover what matters, and have ever been proven to restore.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge whether the system could recover from data loss, corruption, or a bad deploy — not whether backups are configured, but whether a restore would actually work when it counts.
Read-only pass. Read infra config, backup jobs, and any runbooks; change nothing. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
every stateful store actually backed up, not just the obvious database
whether a restore has ever been tested, or the backup is untested and maybe unrestorable
how much data loss the backup cadence permits versus what is acceptable
how long a full restore takes versus the tolerable downtime
encrypted, off-site, versioned, retained long enough, immune to the same failure
can you recover one table or tenant, or only everything at once
a written, current recovery procedure someone could follow under pressure
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List every stateful store.
Backup coverage — every stateful store actually backed up, not just the obvious database.
Rank by data-loss risk.
Create RECOVERY.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:backup-recovery.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-backup-recovery:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=91 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/91.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Backup & Recovery Audit You are working inside this repo. Mission: judge whether the system could recover from data loss, corruption, or a bad deploy — not whether backups are configured, but whether a restore would actually work when it counts. Read-only pass. Read infra config, backup jobs, and any runbooks; change nothing. Your only write is the report file. ## Phase 1 — Inventory what must survive - List every stateful store: primary database, file/object storage, caches with no source, config, secrets. - For each, find whether and how it is backed up, how often, and where the backup lives. - Note what the business can tolerate losing — in data and in downtime. ## Phase 2 — Audit through 7 lenses 1. **Backup coverage** — every stateful store actually backed up, not just the obvious database 2. **Restore proof** — whether a restore has ever been tested, or the backup is untested and maybe unrestorable 3. **RPO** — how much data loss the backup cadence permits versus what is acceptable 4. **RTO** — how long a full restore takes versus the tolerable downtime 5. **Integrity & retention** — encrypted, off-site, versioned, retained long enough, immune to the same failure 6. **Partial & point-in-time** — can you recover one table or tenant, or only everything at once 7. **Runbook & ownership** — a written, current recovery procedure someone could follow under pressure ## Phase 3 — Curate - Rank by data-loss risk: an unbacked store with no source outranks a slow-but-working restore. - For each gap, state the failure it leaves the system exposed to. - Separate "no backup" from "backup never tested"; the second is the more common surprise. ## Phase 4 — Report Create `RECOVERY.md` at repo root: 1. **Recovery posture** — per store: backed up? tested? RPO/RTO actual vs target 2. **Gaps** — ranked by data-loss risk, each with the exposure it creates 3. **RPO/RTO table** — where the system meets its targets and where it does not 4. **Next drill** — the restore to actually run to prove recovery works Start the report with today's date. If `RECOVERY.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - An untested backup is a hope, not a backup - Recovery is measured in data lost and time down, not in jobs configured - No data to back up in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which recovery gaps to close first
reports/ directory exists at the repo root, write the report there instead of the root.Map merged-PR to production; every manual step is a finding. Includes the rollback-readiness verdict.
Expensive queries, chatty API loops, unbounded storage, oversized resources — savings ranked by effort.
The 3am table — for each failure scenario: how you'd detect it, how you'd respond, and the gap in between.
Every knob, var, and magic value — where config sprawls, where environments drift, what explodes at boot versus at 3am, and which secrets hide in plain sight.
Runs inside these playbooks — curated sequences you can launch with one paste: