How to Rehearse a Database Restore Before You Need One

How to Rehearse a Database Restore Before You Need One

If your database is corrupted, accidentally deleted, or compromised, your backup is the only thing standing between you and a business-ending data loss. But here is the hard truth: an untested backup is not a backup — it is a hope. You do not know if your backup works until you try to restore it, and the worst time to try is during a real incident. This article is a step-by-step rehearsal guide that takes 30 minutes and gives you the confidence that your backup actually works.

The direct answer is that rehearsing a database restore is a 30-minute exercise: download the latest backup, restore it to a test database, verify the data is correct, time the restore, and document the process. By doing this before you need it, you eliminate the uncertainty and build the muscle memory to recover quickly when a real incident happens. For more on backups and recovery, see our article on what SaaS founders should know about deployment rollback and backups.

Why You Need to Rehearse

Three reasons explain why you need to rehearse a database restore. First, backups can fail silently. A backup might be corrupted, incomplete, or in the wrong format, and you will not know until you try to restore it. Second, the restore process might be complex. Depending on your database provider, the restore might involve multiple steps (download, decompress, create a new database, import), and you need to know the steps before you are under pressure. Third, the restore might be slow. If your backup is 10GB, the restore might take 30 minutes, and you need to know that before you are in an incident. For more on incident response, see our article on how to handle your first SaaS deployment incident.

Step-by-Step: The 30-Minute Rehearsal

Step 1: Download the latest backup (5 minutes)

Download the latest backup from your database provider. Most providers (Supabase, Neon, Railway) offer a dashboard where you can download backups. Download the backup file to your local machine.

If your provider does not offer a download option, create a backup manually using pg_dump:

pg_dump "postgresql://user:password@host:5432/mydb" -F c -f backup.dump

This creates a compressed backup file that you can restore later.

Step 2: Create a test database (5 minutes)

Create a new test database (do not use your production database). If you are using Supabase, create a new project. If you are using Neon, create a new branch. If you are using a local Postgres, create a new database:

createdb test_restore

Step 3: Restore the backup to the test database (10 minutes)

Restore the backup file to the test database:

# For a custom-format backup (.dump)
pg_restore -d "postgresql://user:password@host:5432/test_restore" backup.dump

# For a plain SQL backup (.sql)
psql "postgresql://user:password@host:5432/test_restore" < backup.sql

Time the restore. If it takes more than 10 minutes, your backup is large, and you need to factor that into your incident response plan.

Step 4: Verify the data (5 minutes)

Connect to the test database and verify the data is correct:

-- Check the table count
SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';

-- Check the row count for key tables
SELECT count(*) FROM users;
SELECT count(*) FROM subscriptions;
SELECT count(*) FROM payments;

-- Check the latest records
SELECT * FROM users ORDER BY created_at DESC LIMIT 5;
SELECT * FROM payments ORDER BY created_at DESC LIMIT 5;

Verify the data matches your production database. If the row counts are different, the backup might be incomplete. If the data is corrupted, the backup might be damaged.

Step 5: Document the process (5 minutes)

Write down the restore process in a runbook:

## Database Restore Runbook

1. Download the latest backup from [provider dashboard URL]
2. Create a test database: `createdb test_restore`
3. Restore the backup: `pg_restore -d "DATABASE_URL" backup.dump`
4. Verify the data: check row counts for users, subscriptions, payments
5. If restoring to production: point the app's DATABASE_URL to the restored database
6. Restart the app: `deployxa restart --app my-app`

Estimated restore time: X minutes
Backup size: X GB
Last tested: [date]

Store the runbook in a location your team can access (e.g., Notion, Google Docs, GitHub). For more on runbooks, see our article on how to build a deployment process your future team can inherit.

Common Pitfalls and Troubleshooting

The first pitfall is not having a backup to test. If your database provider does not offer automated backups, you need to set them up manually (via pg_dump and a cron job). For more on automated backups, see our article on the agentic database backup pipeline.

The second pitfall is the backup being too old. If the backup is from 24 hours ago, you will lose 24 hours of data during a restore. The fix is to back up more frequently (e.g., every 6 hours or hourly for high-traffic apps).

The third pitfall is the backup being corrupted. If the restore fails with an error, the backup might be corrupted. The fix is to verify the backup's integrity (e.g., check the file size, try a different backup) and to test backups regularly.

The fourth pitfall is the restore being too slow. If the restore takes 30 minutes, your incident response is delayed by 30 minutes. The fix is to use a faster restore method (e.g., point-in-time recovery, which some providers offer) or to reduce the backup size (e.g., archive old data).

The fifth pitfall is not documenting the process. If you are the only one who knows how to restore, you become a bottleneck. The fix is to document the process in a runbook that anyone can follow.

How Often to Rehearse

Rehearse the restore at these intervals:

• Before launch. Test the restore before accepting your first customer. This is part of the pre-launch checklist. For more, see our article on the production checklist before your SaaS takes its first customer.

• Monthly. Test the restore monthly to ensure the backup is still working and the process is still fresh in your mind.

• After major changes. Test the restore after major database changes (e.g., schema migration, new tables, new indexes) to ensure the backup includes the changes.

• After provider changes. Test the restore after changing your database provider (e.g., moving from Supabase to Neon) to ensure the new provider's backups work.

Conclusion: Test Before You Need It

An untested backup is not a backup — it is a hope. By rehearsing the database restore in 30 minutes, you eliminate the uncertainty and build the muscle memory to recover quickly when a real incident happens. Do it before you need it, document the process, and rehearse regularly. Your future self (and your customers) will thank you.

Ready to rehearse? Download your latest backup and follow the 30-minute rehearsal above. For more on backups, see what SaaS founders should know about deployment rollback and backups. For automated backups, see the agentic database backup pipeline. Explore our free developer tools to speed up your workflow.