Integrity checks and restore tests
How backupd proves each backup is good. Integrity checks after every backup, and restore tests in a sandbox with row and document counts.
backupd checks backups in two ways: an integrity check after every backup, and a restore test on your plan's cadence.
Integrity check
Runs after every backup, on every plan and every engine.
- The stored file is read back from backupd Storage.
- It is decrypted and decompressed.
- Both checksums, of the stored file and of the dump inside it, are compared with the ones recorded when the backup was made.
- The engine's archive format is checked. For Convex, the ZIP is tested end to end.
A backup that fails its integrity check is not counted as good.
Restore test
The restore test proves the backup actually restores.
- The backup is fetched from storage, decrypted and decompressed, like any restore.
- It is restored into a temporary database on a sandbox server running the same engine. Your database is never touched.
- Every table or collection is counted and compared with the counts taken when the backup was made.
- The temporary database is dropped.
The backup's page shows the result under Restore test, including what it was restored into and how many tables were checked.
How often
| Plan | Restore tests |
|---|---|
| Starter | The latest backup, once a day |
| Pro | Every backup up to 10 GB, and the latest larger backup once a day |
| Custom | Every backup, whatever its size |
The first backup of every database is always restore-tested. To test a backup again, open it and click Re-run restore test (owners and admins).
What is compared
- PostgreSQL: exact row counts when the database has up to about 25 million rows and a snapshot can be exported, which needs a primary. Otherwise counts are estimates and those tables aren't compared.
- MySQL and MariaDB: exact row counts for every table, taken from the dump.
- MongoDB: document counts for every collection, as reported by
mongodump. Theadmin,configandlocaldatabases are not restored or tested. - Convex: no restore test. Convex has no temporary deployment to restore into, so Convex backups get the integrity check and per-table document counts.
When a check fails
The backup is marked Restore failed and the Restore test failed event goes to your notification channels. The backup's page lists each table that came back short, with both counts. Keep an older verified backup until the problem is resolved: retention always keeps the newest verified backup of each database.