Backups are not enough: how to prove you can restore your app.

The direct answer: prove your backup by restoring a real recovery point into a separate, protected test environment, then check that the app opens, important records and files are present, permissions still work, and your essential customer journeys succeed. Record how long it took and how much recent data would be missing. Never run a rehearsal by overwriting your live database.

What a successful backup message does not tell you

A backup job can finish successfully while leaving out uploaded files, a second database, a crucial configuration value or the steps needed to restart the app. Even a complete copy may be unreadable because an encryption key is unavailable. A snapshot tells you that something was saved at one moment; it does not demonstrate that a working service can be rebuilt from it.

This matters especially for a vibe-coded app assembled from several services. Your app might keep account records in one database, images in object storage, payment state at a payment provider and login settings elsewhere. Restoring only the database can produce an app that starts but shows broken images, missing orders or failed sign-ins. First identify what is yours to back up and what a provider can recover on its own.

Make a one-page recovery map

Write down every place where irreplaceable information lives: the main database, file uploads, generated documents, configuration, infrastructure definitions and any external service whose data your app needs to function. For each, note the backup method, location, frequency, retention period, person with restore access and instructions. Do not paste passwords or recovery keys into the document; record where approved custodians can retrieve them securely.

Next, ask two plain-English questions. How much recent information could we afford to lose? If backups run nightly, a failure just before the next backup might cost nearly a day of changes. How long could the service stay down? A restore that takes four hours may be unacceptable if customers need immediate access. These are recovery point and recovery time goals, but you do not need the jargon to make a decision. State the tolerances before testing so a result can be judged honestly.

A safe restore drill, step by step

1. Choose a real recovery point. Select a recent backup from the system you would actually rely on during an incident. Note its timestamp. Occasionally try an older point too, so you know retention works.
2. Prepare an isolated destination. Use a separately named database and app environment with limited access. Confirm the target before any restore command. Disable live payment actions, outgoing customer emails, webhooks and scheduled jobs so the test cannot create orders or contact real people.
3. Restore the whole set. Follow written steps for the database and any files or other stores. Use approved secret-management and encryption-key access. If the pieces were backed up at different times, record the mismatch and check whether it creates missing or duplicate references.
4. Check the result, not just the job status. Can a controlled test account sign in? Do a few known records and uploaded files appear? Can the app read and write a disposable test record? Do private records stay private? Try the journeys that matter to your business, such as opening an order or downloading a document, without sending real payments or messages.
5. Measure and document. Record start and finish time, backup timestamp, records or files checked, failed steps, and who performed the drill. Compare the observed downtime and potential data loss with the tolerances you wrote down. Keep screenshots or logs that do not expose personal data or secrets.

If restoring customer data into a test environment would create a privacy or security risk, use a controlled backup with synthetic test records, a protected recovery account or another method approved for your setup. A useful drill still needs to exercise the real restore path. Do not download a production data dump to an unsecured laptop simply to tick a box.

What counts as a pass?

“Restore job completed” is only an intermediate result. A credible pass means the restored service can run the agreed checks, the required data is present and usable, access controls hold, and measured recovery time and data loss are within your stated limits. If you cannot verify a third-party integration in the isolated environment, mark it not tested instead of silently calling the entire drill a success.

A failed drill is valuable information if it happens before an emergency. Common discoveries include missing storage buckets, undocumented environment settings, expired access, backups encrypted with a lost key, or a restore that takes much longer than expected. Fix the gap, update the instructions, and repeat the test. Do not delete an older known-good recovery point until the new approach has been proven and retention requirements are understood.

Keep recovery usable as the app changes

Run a first drill before launch. Repeat on a schedule that matches your risk, and after meaningful changes to your database, file storage, hosting or authentication. A solo founder may choose a calendar reminder and a simple evidence log; a larger or more critical app may need automated tests and more frequent exercises. The right frequency depends on the value and pace of the data, not on a universal number.

Keep the runbook short enough to use under pressure: where backups are found, who has access, how to choose a recovery point, the safe restore destination, the order of steps, checks to run, and a rollback or stop point. Include a separate incident contact plan. Recovery may also require telling users what happened and what data is affected; a backup cannot answer those questions for you.

This distinction is supported by the Microsoft reliability guidance on backup and restore, which calls for regular testing and verification, and AWS Backup's restore-testing guidance, which separates a completed restore job from optional validation of the result. Those products are examples, not requirements for your app.

What to ask your coding assistant or developer

Ask: “List every data store needed to rebuild this app. Show the actual backup schedule and retention settings. Give me a safe, isolated restore procedure and a checklist for proving the app works afterward. Which parts remain untested?” Request specific settings, commands or dashboard locations relevant to your own stack, not an invented generic answer. Have a qualified person review any step that can overwrite production or move customer data.

KHDS Ship Doctor helps vibe coders and non-technical founders gather evidence for a production-readiness check. The free builder creates a starter instruction; the £49 one-off toolkit adds reusable workflows, evidence templates and a remediation plan. See the public sample report for how findings and unverified areas are distinguished. For the wider launch picture, read the AI-built app production checklist and production-readiness guide.

Frequently asked questions

Is a backup the same as a recovery plan?

No. A backup is a saved copy. A recovery plan covers the systems, access, order of steps, checks and communications needed to get a usable service back.

How often should a solo founder test a restore?

Before launch, after major storage or deployment changes, and regularly at a cadence that fits your risk. Record the date and outcome; a scheduled backup alone is not proof.

Can I test a restore without touching production?

Yes. Restore to a separately named, access-controlled environment with live payments, emails, webhooks and customer-facing domains disconnected. Protect copied personal data.

What if my app uses more than one storage service?

List and test each required store, then check that the restored pieces work together. A database backup may not include uploaded files or records held by another provider.