The backup said healthy. It wouldn't restore.
In this controlled demo, the backup health check only looks for a backup file that isn't empty. The file is there but broken, so the check says healthy and the restore fails.
Demo built and tested 1 Oct 2026 · Published 1 Oct 2026 · Last reviewed 1 Oct 2026 · By Ctrl+Z Therapy (how we test)
How do I know my database backup will actually restore?
Only by restoring it. A check that the backup file exists, or isn't empty, says nothing about whether the data inside can come back. In our controlled demo, a broken backup passed that kind of check and then failed to restore. The fix: restore a backup into a separate test database on a schedule and check that your records are really there. Never test by overwriting your live database.
How to tell if your app has this
No code needed.
- Ask yourself: have we ever restored one of our backups? If not, you don't know yet whether they work.
- Find out what your plan includes. On Supabase, backups are under Database > Backups in the dashboard, and the Free plan has no automatic daily backups.
- Ask your AI tool: "How is our database backed up, and how would I restore it into a separate test database? Walk me through a test restore."
Before and after
Health check said healthy. The restore failed.
The broken backup fails the restore test. A good one passes.
Why AI-built apps end up with this
AI tools add backups the way they add most features: something runs on a schedule and reports success. Checking that the file exists is easy to write and always passes. A real restore needs a second database and a comparison, so it is usually left out unless you ask, and nobody notices until the day they need it.
How do I fix it? Paste this into your AI tool
Our backup check only confirms that a backup file exists, not that it can be restored. Set up a restore test: on a schedule, restore the latest backup into a separate test database (never the live one), then check that the important tables are there, have a sensible number of rows, and contain a few records we know should exist. Alert me if the restore fails or the data looks wrong. Write down the exact restore steps so I can follow them in an emergency, and tell me which backups our hosting plan actually includes.Works with Lovable, Bolt, Cursor, Replit and similar tools. Then run the check-up below on your own app.
How we checked the fix
| Same request | Before | After |
|---|---|---|
| Broken backup file | Health check: healthy | Restore test: failed |
| Good backup file | Health check: healthy | Restore test: passed |
Results from our demo test, run against the same demo before and after the fix.
Common mistakes when fixing this
- Never test a restore by overwriting your live database. Restore into a separate copy.
- A backup you have never restored is a guess. Time the restore too, so you know how long you would be down.
Questions people ask
Does my hosting provider's backup count?
Yes, if your plan really includes it and you know how to restore it. Check what your plan includes and how far back it goes, then try a restore into a new project or test database.
How often should I test a restore?
On a schedule you will keep, for example monthly, and after big changes to your database. An automatic restore test that alerts you when it fails is best.
Can I test the restore on my live database?
No. A restore overwrites what is there. Always restore into a separate test database or a new project.
For developers: the cause and the fix in code
− healthy = backup_file.exists() and backup_file.size > 0 + restore(backup_file, into=test_db) # never the live database + healthy = test_db has the records you expect
Simplified. Your stack will look different; the principle is the same.