Database backups you have actually restored

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Database backups you have actually restored

A launch brings the first real users, and their data is the one thing the production site cannot recreate. Find out exactly how the database is backed up, close the gaps, and prove a restore works, so a bad migration or a mistaken delete on launch week is a bad hour, not the end.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Restore over, drop or modify the production database.
- Change backup settings in a provider's dashboard: I do that.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Find what is backed up

Identify every place data lives: the main database, file or image storage, any second database or cache that holds data you cannot rebuild. For each, find what backups the provider makes (automatic snapshots, point-in-time recovery), how often, and how long they are kept. Tell me what you cannot see from the code and must check in a dashboard.

### 2. Close the gaps

Where there is no backup or the window is short, propose the fix: turning on the provider's point-in-time recovery, a scheduled export to separate storage, or longer retention. Uploaded files need their own plan (versioning or a copy to a second bucket).

### 3. Write and test a restore

Write a step-by-step restore runbook: restore to a new, separate database, check row counts and a few records, then point the app at it. Where possible, run the restore into a scratch database yourself to prove the steps work. Never restore over the production database.

### 4. Guard migrations

Make sure database migrations are reviewed and that destructive ones (dropping columns or tables) require an explicit step. Note how to take a manual backup before a risky migration.

## Done means

- [ ] Every data store is listed with its backup frequency and retention.
- [ ] The gaps have a proposed fix, and I know which dashboard settings to change.
- [ ] A restore runbook exists, and a restore into a scratch database has been tested where possible.
- [ ] Destructive migrations need an explicit step, with a manual backup first.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.