What can go wrong that an upload check won't catch
A pg_dump can be truncated by a dropped connection, a disk-pressure event, or a lock timeout partway through — and still produce a file that uploads successfully. A schema can reference an extension that isn’t available at restore time. None of these failures touch the upload step. They only appear when you try to load the file back into Postgres, which is usually the day something has already gone wrong.
What an actual restore test checks
Each backup run goes through the same sequence, automatically:
- The dump is restored into a fresh, disposable Postgres instance.
- Table row counts are compared against an inventory captured at dump time.
- Auth user counts are compared the same way.
- Supabase Storage files, if included, are copied separately and checked byte-for-byte with SHA-256.
If any step fails — the restore itself, a row count mismatch, a checksum mismatch — that shows up on the backup run immediately, with the specific mismatch recorded, not just a generic failure.
What you get to keep as evidence
Every verified backup run keeps the database version, schema and table counts, row counts, auth user counts, and Storage file counts and sizes. You can download the verified database dump or a checksummed Storage manifest directly — evidence you can hand to an auditor or a teammate, not just a green checkmark.