A backup is not a recovery plan until someone tests the restore

"We have backups" answers one question.

It tells me that a system is expected to create copies of something on a schedule.

It does not tell me what those copies contain, whether they can be restored or how the database becomes a working application again. That second part is the recovery plan.

You can prove it without touching production.

Start with the failure you are preparing for

A useful restore test begins with a specific event.

For example:

A bad database migration reaches production at 14:00. The problem is noticed at 14:20. Customer records written after 14:00 may conflict with the old schema.

That is different from losing the entire hosting account, deleting one customer's records or losing access to a third-party service. Each event needs a different recovery path.

Pick the failure that would hurt the product most and is plausible enough to prepare for. Then define two tolerances in ordinary language:

• How much recent data can the business afford to lose?
• How long can the application remain unavailable or partly unavailable?

The technical names are recovery point objective and recovery time objective. The plain answers matter first.

Find out what the backup includes

Do not assume the provider backs up the whole application.

A database backup may contain table records while excluding uploaded files, environment variables, API keys, edge functions, authentication settings and vendor configuration.

Supabase documents this boundary directly. Its database backups do not include objects stored through the Storage API, and some role passwords need to be reset after restoration. A restore can also require downtime. The current details belong in Supabase's backup documentation, not in somebody's memory.

Create an inventory for your stack:

If a row is blank, the restore test has already found something useful.

Restore somewhere disposable

Do not use the live project as the first place you test recovery.

Create a separate environment with no route to real customers. Use temporary credentials and block outbound actions that could send email, charge cards or call customer webhooks.

Then follow the written process exactly.

Do not let the person who wrote the instructions fill in missing steps from memory. The test is partly checking whether another authorized person can use the document.

A basic database restore usually looks like this:

1. Create the target database or project.
2. Restore the selected backup.
3. Apply any configuration the backup does not contain.
4. Reconnect the application with safe test credentials.
5. Start the application against the restored data.
6. Run a known set of verification checks.

PostgreSQL supports several backup approaches, including SQL dumps, file-system backups and continuous archiving. Each has different assumptions. The PostgreSQL backup and restore documentation is the source to use when the database is managed directly.

Check the application after the rows come back

A successful restore command can still produce an unusable product.

The verification should cross the same systems customers use:

• Can an ordinary user sign in?
• Can one customer see only its own records?
• Do uploaded files open?
• Does the core paid workflow complete?
• Are background jobs present but prevented from contacting real users?
• Can an administrator perform a safe read-only check?
• Do expected database extensions, functions and scheduled jobs exist?

Choose a small set of known records before the exercise. Record their identifiers and expected state. That gives the test something better than "the tables look populated."

If the restore contains production-derived data, handle it under the same access and deletion rules as production. A recovery test is not permission to copy customer data into an unsecured developer laptop.

Time every step

The restore procedure may be correct and still take longer than the business can tolerate.

Record:

• Time to obtain the backup
• Time to create the target environment
• Time to restore data and files
• Time to recreate configuration
• Time to complete verification
• Total time until the application is usable

Do not turn the result into a guaranteed recovery time after one clean test. Treat it as evidence from this environment, with this amount of data, on this date.

The next test may include a larger database or a person who did not write the runbook.

Write down what failed

The first restore often exposes ordinary gaps:

• A password existed only in the previous operator's account.
• File metadata came back but the files did not.
• A database extension was missing.
• The application started sending real transactional email.
• One setup step depended on an undocumented dashboard click.
• The backup retained less history than the team assumed.

Fix the instructions as well as the test environment.

Then delete the temporary environment and any copied data according to the access procedure. Record the deletion as part of the exercise.

The recovery plan is the tested route

A short recovery record should contain:

• The scenario tested
• Backup and restore points used
• Systems included and excluded
• Person who performed the restore
• Start and finish times
• Verification results
• Missing steps or failed checks
• Follow-up owner and due date
• Date for the next exercise

That is enough for a small founder-led product. It replaces a reassuring dashboard assumption with a route somebody has followed.

Backup and rollback readiness are part of the production baseline in the 10-Day Production Takeover. The goal is not a certificate. It is knowing what can be recovered, by whom and what still needs work before customers are waiting.