How to prove your backups actually restore

A backup is only real after a restore

On January 31, 2017, an engineer at GitLab deleted a production database directory by mistake. The team then went looking for backups. In their own public postmortem, they describe that the regular database dumps had been failing silently because of a version mismatch, and the failure emails were being rejected, so nobody knew. Disk snapshots were not enabled for the database servers. They recovered from a copy taken about six hours earlier, and lost roughly six hours of data, including thousands of projects and comments.

Their summary is the sentence worth remembering: "we were never aware of the backups failing, until it was too late."

GitLab had several different safety nets on paper. What was missing was a routine of restoring one and checking it. That routine is what this guide gives you. It takes an afternoon the first time and less than an hour after that.

Run every test below into a separate, new database, server or bucket. Never restore over production to test.

What a restore test proves

A good test answers four questions:

1. Does a recent backup exist? Check the date, not just that the job "ran".
2. Can you actually restore it? With the access and tools you have today.
3. Is the data complete and usable? Your app can read it, row counts look right, files open.
4. How long did it take? That is your real recovery time. Write it down.

Managed database snapshots (Amazon RDS)

Amazon RDS (the AWS managed database service) takes automated backups and lets you create manual snapshots. Restoring always creates a new database instance, which makes testing safe.

Steps:

1. RDS console, then Snapshots. Pick the most recent automated or manual snapshot and note its time.
2. Actions, then Restore snapshot. Give the new instance a clear name such as restore-test-2026-10.
3. Choose the same parameter group (the database settings file) and a security group that only your team can reach. By default, RDS attaches the default parameter group and default security group, so set these on purpose.
4. Choose Restore DB instance and time how long it takes to reach the Available status.
5. Connect with your usual database client and run checks:
6. Row counts of your 5 most important tables, compared with production.
7. The newest record's timestamp in a busy table. This shows how much data you would lose.
8. One real query your app runs, such as loading a user and their orders.
9. Optional but strong: point a staging copy of your app at the restored database and log in.
10. Delete the test instance when done, so it does not bill all month.

The same from the command line:

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier restore-test-2026-10 \
  --db-snapshot-identifier <your-snapshot-id>

Also test point-in-time restore at least once (Databases, select the instance, Actions, Restore to point in time). It is the option you would use after a bad deploy or a mistaken delete.

A freshly restored RDS instance loads data in the background. The first queries can be slow, so time your test to "app usable", not just "status Available".

Supabase projects

On Supabase paid plans (Pro, Team, Enterprise), the database is backed up daily, and Point-in-Time Recovery is an optional add-on. The Free plan has no automatic backups, so export your data yourself with the Supabase CLI db dump command or pg_dump.

Steps:

1. In the dashboard, open Database, then Backups, and confirm the latest backup date.
2. For a safe test, take a logical copy with supabase db dump (or pg_dump) and restore it into a separate, empty project or a local Postgres with psql or pg_restore.
3. Run the same row-count and newest-record checks as above.

One thing many teams miss: Supabase's own docs state that database backups do not include files stored through the Storage API. If users upload files, back those up separately and test them too (see object storage below).

Plain Postgres or MySQL dumps on your own server

If a cron job runs pg_dump or mysqldump:

1. Find where the dump files land and check the newest file's date and size. A file that is suddenly much smaller than last week's is a warning.
2. Copy the newest dump to a separate machine or container.
3. Restore it: pg_restore -d restore_test latest.dump (or psql restore_test < latest.sql), or mysql restore_test < latest.sql.
4. Run the row-count and newest-record checks.
5. Check that the client tool version matches or is newer than the database server version. A version mismatch is exactly what broke GitLab's dumps.
6. Check that a failed backup sends an alert someone actually reads.

Server backups (EC2 snapshots and images)

If your app runs on virtual servers, backups are usually EBS snapshots (copies of a server's disk) or AMIs (full server images).

Steps:

1. EC2 console, then Snapshots (or AMIs). Confirm the newest one is from the expected schedule.
2. For a snapshot: Actions, then Create volume from snapshot, in the same availability zone as a small test server. Attach it to that server and mount it read-only. Check that key folders, config files and uploads are there.
3. For an image: Launch instance from AMI into a private subnet with no public access. Check that the app starts and its services come up.
4. Note anything that lived outside the disk: environment variables, secrets, DNS records, load balancer settings. Write down where those are kept, because a disk backup will not bring them back.
5. Terminate the test server and delete the test volume.

If you use AWS Backup, it has a built-in restore testing feature that restores recovery points on a schedule and reports whether they succeeded. It is worth turning on once you have done one manual test and know what "good" looks like.

Object storage (S3 and similar)

Files in S3 are durable, but durability does not protect you from someone deleting or overwriting them, or from a script with a bug.

Check:

1. S3 console, open the bucket, Properties: is Bucket Versioning enabled? Versioning keeps older copies when a file is overwritten or deleted.
2. Under Management, is there a lifecycle rule that removes old versions after a set time, so versioning does not grow forever?
3. Is there a copy outside the bucket? For important data, replication to a bucket in another account or region protects against an account-level mistake. Object Lock can make copies undeletable for a set period.

Test:

1. Upload a test file, overwrite it, then delete it.
2. In the bucket, turn on Show versions, find the old version and restore it by copying it back.
3. If you replicate, confirm the same file shows up in the replica bucket.

The printable checklist

What good looks like

A short page in your docs that says: what is backed up, how often, how long it is kept, who gets the alert when it fails, the date of the last successful restore test, and how long the restore took. If a second person on your team could follow it without calling you, you are in good shape.

Not sure where your gaps are? The 2-minute check covers backups, outages and access, with one fix you can do today for each gap.

Want a second pair of eyes?

The free review checks whether your backups exist, run on their own and have ever been restore-tested, using view-only access. You get a short written report and can do every fix yourself.

Sources

• GitLab: Postmortem of database outage of January 31 (2017)
• Amazon RDS: Restoring to a DB instance
• Amazon RDS: Restoring a DB instance to a specified time
• Supabase: Database backups
• PostgreSQL: pg_dump and pg_restore
• Amazon EBS snapshots
• AWS Backup: Restore testing
• Amazon S3: Versioning, Replication, Object Lock

From keelops.co/backup-restore-test. Free to print and share.