Turn a Database Backup Into a Proven Restore Drill

A green backup job proves that bytes were written somewhere. It does not prove you can restore the right database, on the right version, inside the recovery time your product needs.

This guide belongs to reel R078. Comment RESTORE for the matching module and runnable starter.

Define the boundary before building

Input: backup job configuration, encrypted backup artifact metadata, target database version, recovery objectives, integrity queries, and restore owner.

Output: a restore runbook, isolated recovery plan, measured recovery time, integrity check results, failure notes, and follow-up actions.

The starter keeps exact checks in code and gives Claude only the reviewable drafting work. Dry-run is the default. Live mode can call Anthropic's Messages API, but it still returns a draft and performs no external action.

Paste this boundary into Claude Code before asking for implementation:

Workflow: Turn a Database Backup Into a Proven Restore Drill
Input: backup job configuration, encrypted backup artifact metadata, target database version, recovery objectives, integrity queries, and restore owner
Output: a restore runbook, isolated recovery plan, measured recovery time, integrity check results, failure notes, and follow-up actions

Map the trigger, strict input fields, deterministic code checks, Claude drafting step, approval gate, failure queue, and saved evidence. Use null for missing facts. Do not change code or call an external service yet.

The modules that matter

Restore away from production

Create a disposable target with the same database engine and extensions. Use fictional or approved sanitized data. Never discover a destructive restore flag against the live cluster.

Measure two recovery promises

Recovery point tells you how much recent data could be lost. Recovery time tells you how long service restoration takes. Name both targets before the drill starts.

Check product invariants

Row counts are only a start. Verify foreign keys, ledger totals, latest timestamps, authentication records, and a real application read path. Record every command and elapsed time in the runbook.

Rules worth keeping beside the code

Restore into an isolated environment before declaring a backup usable.
Record recovery time and recovery point against named objectives.
Verify application-level invariants, not only row counts.
Keep production credentials and customer data out of the starter.

The dangerous version is testing against production, exposing backup contents, assuming a successful upload means a restorable backup, or skipping application integrity checks. The pack deliberately stops at a draft so a person can inspect those boundaries before enabling anything real.

Test the ugly paths

Corrupted archive is rejected.
Wrong database version fails visibly.
Required extensions are recreated.
Integrity queries match expected fictional values.
The app starts against the restored database.
The restore owner can repeat the runbook without hidden knowledge.

The final verification is concrete: Restore a fictional snapshot into a disposable database, run every integrity query, start the application against it, and record the elapsed recovery time.

Use this prompt to turn the evidence into acceptance tests:

Design tests for Turn a Database Backup Into a Proven Restore Drill using only the attached fictional fixtures.
Cover the normal path, missing input, malformed input, a repeated event, a permission failure, a dependency failure, and the named safety boundary.
For each test return: input, expected state, prohibited side effect, and evidence to save.
Do not execute external actions.

Run the pack locally

The ZIP is a complete Node 22 starter with no third-party npm dependency. It includes an importable n8n webhook, Docker Compose, GitHub Actions validation and manual-run workflows, deterministic samples, and tests.

npm test
npm run validate
npm run sample
cp .env.example .env
docker compose up --build

Only set WORKFLOW_MODE=live, ANTHROPIC_API_KEY, and ANTHROPIC_MODEL after the dry-run output and tests make sense for your system. Keep real secrets in the environment, never in the n8n export.

Download the runnable pack

Start with the fictional dry-run. It validates the input and returns a reviewable draft without changing code, production data, customer accounts, or an external service.

Before enabling a real action

Replace every fictional fixture, assign the approval owner, define the duplicate key, set a timeout and retry rule, and save the original evidence. Then test one failure on purpose. If the workflow cannot stop visibly and replay safely, it is not ready to act.