What is backup verification?

Backup verification is the practice of checking, before you need it, that a backup is usable. "The backup job exited 0" proves a file was written. Verification proves two further things: the file can be restored, and what you get back is the data you expected.

Most teams stop at the first. The failures that hurt are in the other two.

Verification is a ladder. Each rung catches problems the one below it cannot.

• Level 1, job status. Did the backup job finish without an error? This catches crashed jobs and little else.
• Level 2, integrity checks. Checksums, listing the archive's contents, or a tool such as pg_verifybackup for PostgreSQL base backups. This catches truncated and corrupted files.
• Level 3, restore test. Restore the backup into a clean, isolated database and see whether the restore completes. This catches missing extensions, version incompatibilities and permission errors that integrity checks cannot see.
• Level 4, data verification. After the restore, assert things about the data: row counts in the expected range, key tables and columns present, no nulls in critical columns, newest row recent. This catches a backup that is intact, restores cleanly and is still wrong.

A restore drill is levels 3 and 4 done on a schedule, with the result recorded.

Each of these passes level 1 and fails when you actually restore:

• A dump truncated because the disk filled up part-way through.
• A missing database extension, so the restore errors out on the first statement that needs it.
• Expired credentials, leaving a backup that is valid but nearly empty.
• A backup of the wrong database, or of a staging copy.
• Schema drift, where the backup restores but your application no longer works against it.
• A restore that works but takes six hours when your recovery objective is one.

A restore test also gives you a number most teams do not have: how long recovery actually takes. If you have a recovery time objective, that duration is the only honest evidence that you meet it. Record it every time.

It depends on how much unnoticed loss you can tolerate. A common pattern is an automated restore and data check every week, plus a fuller drill when the schema or the backup tooling changes. The point is that the check runs on a schedule and someone is told when it fails, or when it stops running.

Recovery testing is an expected control in the common frameworks (ISO/IEC 27001:2022 Annex A 8.13 on information backup, and SOC 2 Availability criterion A1.3 on testing recovery plans), and cyber-insurance renewals increasingly ask whether you restored from backup in the last twelve months. What they want is a dated record of a real restore, not a statement that backups are taken.

You can do all four levels with PostgreSQL's own tools and a short script; the two guides below show exactly how. Dokaz automates the same steps for PostgreSQL: it restores your backup into an isolated, single-use sandbox, runs data assertions, and produces a signed Proof-of-Recovery report that anyone can verify offline. See how it works, or run the sample drill with no card.