How to verify a Supabase backup can be restored
A successful backup job tells you a file was written. It does not tell you the file can be restored. The gap between those two statements is where most backup failures live, and they are usually discovered during an incident, which is the worst moment to learn that a dump is truncated or that an extension is missing on the target.
What a green job does not prove
- That the dump completed rather than stopping partway through with a warning.
- That the target can recreate every extension, role and constraint the dump references.
- That sequences, grants, policies and row-level-security state survived the restore.
- That rows behind row-level security were readable by the account that took the backup.
- That the uploaded file is byte-identical to what was produced locally.
Four checks that do prove it
- Restore into a clean, isolated database rather than an existing one, so nothing already present masks a missing object.
- Make errors fatal. A restore that logs warnings and exits zero will happily produce a half-populated database.
- Compare the result with an inventory taken at capture time: table counts, row counts, and the presence of extensions and roles.
- Hash artifacts that are not restorable, such as Storage objects and function bundles, and compare with the source.
The full procedure for the database layer is in how to test the database layer of a backup.
Do it every time, not quarterly
The usual advice is to schedule a restore drill monthly or quarterly. That is better than nothing, and it still leaves weeks in which a backup can be silently broken. A schema change, a new extension or a permission change can break restores between drills, and you find out at the next drill or during the incident, whichever comes first.
Testing every backup removes that window. It costs compute, which is the honest reason most tools do not do it.
What ReviveDB does
Every database backup is restored into an isolated PostgreSQL instance and compared against an inventory taken when it was captured. Storage objects and Edge Function bundles are verified by SHA-256 rather than restored. The result is a report per recovery point showing what was verified, what could not be captured, and which steps remain manual.
The downloadable report names the checks precisely: schemas, tables, row counts, columns, constraints, indexes, views, functions, triggers, policies, row-level-security state, grants, sequences, extensions, publications, replica identity, cron jobs and queues. It also records restore duration, mismatch counts, captured Storage objects and whether their bytes were verified.
One privacy decision came from building this against real database inventories: the downloadable verification report exposes mismatch categories and counts, but not customer schema, table or column names. Evidence should be specific without creating another copy of a customer’s data model.
Two boundaries worth being explicit about: the restore test covers the database, not every component, and secret values such as Edge Function secrets and Vault contents are never copied, so they are recreated by hand after a restore.
See how ReviveDB verifies every database backup for the product method, what a restore test is for the definition, or compare the available tools on whether they verify at all.