Backup and Restore Testing for Small Apps: A Practical Guide

A backup is only useful if you can restore it, quickly, into a working app. Most small apps, and nearly every AI-built app we look at, have some form of backup switched on and no evidence that it works. A restore test answers three questions: does the backup contain what you need, how long does getting it back take, and does the app actually run afterwards? This guide shows a founder or a small team how to answer them in an afternoon.

Why test restores at all?

Because the day you need a backup is the worst day to discover it is incomplete. The US Cybersecurity and Infrastructure Security Agency advises organisations to “maintain offline, encrypted backups of critical data” and to “regularly test the availability and integrity of backups in a disaster recovery scenario” (CISA Ransomware Guide). That advice was written for ransomware, but it applies equally to a bad deploy, a mistaken bulk delete or an AI agent that runs the wrong command.

That last one is not hypothetical. In July 2025 a Replit AI agent deleted a live production database during a declared code freeze. The agent first said a rollback would not work, and the data was recovered manually (Fortune, 2025). Knowing your own restore path, rather than trusting what a tool tells you in a crisis, is the point of testing.

What do your backups actually cover?

Start by reading your provider’s documentation rather than assuming. Supabase is a good example because so many AI-built apps run on it:

• Daily backups are automatic on Pro, Team and Enterprise plans. Free-plan projects are advised to “regularly export their data” themselves.
• Daily backups are kept for 7 days on Pro, 14 on Team and up to 30 on Enterprise.
• Point-in-time recovery is a paid add-on which, in the worst case, gives a recovery point of two minutes.
• “Database backups do not include objects you store via the Storage API”, so uploaded files such as images, PDFs and documents are not in the database backup.

All four points are from Supabase’s backup documentation. The last one catches many teams out: you restore the database, and every link to an uploaded file is broken.

Make a short inventory of everything your app needs to run:

1. The database: tables and their contents.
2. Uploaded files: whatever your users put in storage buckets.
3. Configuration: environment variables, database policies, scheduled jobs, webhooks.
4. Code: usually in Git, but confirm the deployed version matches what is in the repository.
5. Third-party state: payment, email and authentication settings that live in other dashboards.

For each item, write down where its backup is, how often it runs, and how long it is kept. Gaps in this list are your first findings.

How do you run your first restore test?

Do it on a copy, never on your live app. The goal is to rebuild a working version of your app from backups alone and see what is missing.

1. Pick a time and a target. Choose a quiet afternoon. Decide what “working” means: for example, a test user can log in, see their data, open an uploaded file and complete the main action your app exists for.
2. Create an empty, separate project. A new database project and a new hosting environment with a different address. Keeping it separate means a mistake cannot touch production. Our production readiness checklist explains why development and production need to be separate in the first place.
3. Restore the latest database backup into it. Follow your provider’s restore steps exactly. Time it from start to finish.
4. Restore the files. If you have no separate file backup, note that as a finding, because you have just learned you cannot get them back.
5. Point a copy of your app at the restored data. Deploy the same code version as production, with environment variables for the test project. Use new keys for the test project, not your production secrets; see exposed secrets in AI-built apps for why.
6. Check it against your definition of “working”. Log in, click through, open files, run the main action.
7. Check your security rules came back too. If you use Supabase, confirm row level security is still on for every table in the restored copy. Our guide to Supabase row level security shows how.
8. Write down three numbers. How old was the newest data you recovered? How long did the whole restore take? What did you have to fix by hand?
9. Delete the test environment when you are done, so it does not become an unprotected copy of your users’ data.

What should you write down afterwards?

A one-page restore runbook. It should let someone other than you restore the app at 2am. Include:

• where each backup lives and who has access to it,
• the exact steps you followed, including any manual fixes,
• the time each step took,
• the gaps you found and who is fixing them,
• the date of the test and the date of the next one.

Those three numbers from step 8 matter to more than engineers. They tell you, in plain terms, how much data you could lose and how long your customers would wait. If either is unacceptable, you now know what to spend money on: more frequent backups, point-in-time recovery, or a separate file backup.

How often should a small team test?

There is no single right answer, but a simple rhythm works for most small apps:

• After any major change to the database structure, storage or hosting.
• Every quarter as a routine, even if nothing big has changed.
• After a provider changes its plans or backup features. Read their changelog.

Keep at least one copy somewhere your main account cannot delete. CISA’s advice on offline, encrypted copies exists because some attacks look for reachable backups to destroy first (CISA Ransomware Guide). For a small app, a scheduled export to separate storage under a different account is a reasonable start.

Who should run the test?

Ideally, not the person who set up the backups. A restore test is partly a test of your documentation, and the person who built the system will fill gaps from memory without noticing. If you are a solo founder, write the steps down first, then follow only what you wrote. If you have a small team, ask someone else to follow the runbook while you watch and take notes.

Either way, make sure at least two people can reach the backups and the provider dashboards. A backup that only one person can open is a single point of failure, whether that person is on holiday, unwell or has left the company. The same applies to the accounts that hold your domain, your hosting and your payment provider.

What are the common gaps we see?

These turn up often enough that they are worth checking first:

• Backups switched on for the database but not for uploaded files.
• A free plan with no automatic backups at all, and no export routine.
• Only one person able to access the backups.
• Retention too short to catch a problem noticed after a fortnight.
• Restores that work but bring back a database with security rules missing or out of date.
• No record of which code version matched which backup.

Want help keeping it running?

Restore testing is part of our ongoing support, from $249 a month: we run scheduled restore tests, keep the runbook current, and a named engineer approves every change, with every action recorded. If you would like to know where you stand first, start with a free production check: a call, a written report and a quote.

Sources

• CISA, #StopRansomware Guide
• Fortune, Replit AI agent deletes production database (23 Jul 2025)
• Supabase, Database backups