How backup verification works

Uploading a dump proves that a file exists. ReviveDB verifies a recovery point by restoring it and comparing the result with an inventory captured from the same PostgreSQL snapshot.

One consistent source snapshot

One exported PostgreSQL snapshot feeds both the logical dump and the source inventory. That prevents normal application writes from creating false mismatches between what was dumped and what was counted.

Isolated database restore

The dump is restored into a short-lived, isolated PostgreSQL verification database using the matching supported client. ReviveDB rejects unsupported source versions before saving a connection.

Structural and data comparison

• Required schemas, tables, columns, indexes, constraints, functions and triggers.
• Table row counts and sequence state.
• Required PostgreSQL extensions and their availability in the verification environment.
• Supabase Storage object size and SHA-256 for every captured file.

A verifiable mismatch fails the run. Failed replacement runs do not remove the last verified recovery point on the Free plan.

Open image

What verified does not claim

• That secret values or external service credentials were copied. Those values remain manual.
• That every possible future target environment will accept the recovery point without preparation.
• That amber or unavailable components became complete because the database passed.