Run pg_verifybackup against the backup directory. It compares the backup with the manifest the server wrote at backup time, checking files, sizes, checksums and the WAL needed for recovery. A pass is useful evidence, but the PostgreSQL docs still recommend test restores.
What it checks
The PostgreSQL documentation describes four stages:
- The manifest exists, is well formed, matches the backup's system identifier and passes its own checksum.
- Files present on disk match what the server meant to send, with extra and missing files reported.
- Each file's checksum matches the manifest.
- The WAL records needed for recovery are present and parseable.
What it does not check
- It cannot cover everything a running server checks when it uses the backup.
- It cannot detect logically wrong WAL records that have valid checksums.
- It ignores some files that legitimately change during a backup, such as recovery signal files.
- It does not verify WAL files that are not needed for recovery.
- WAL checks are version specific, so use the verify tool matching the backup version.
- Tar format backups do not support WAL verification yet, so you need the no parse WAL option.
The documentation says to still do test restores and data verification. Treat this as a fast first gate, not the final proof.
Steps
pg_verifybackup /backups/base-2026-10-19
pg_verifybackup -F t --no-parse-wal /backups/base-tar
- Take base backups with the tool that writes a manifest.
- Run the verify command right after each backup in the same job, and fail the job on any error.
- Run it again on the copy in long term storage, to catch damage in transit or at rest.
- Use the skip checksums option for a quick presence and size check only when time is tight. It is much faster but weaker.
- Keep the output with your backup records.
- On a schedule, restore a recent backup into a scratch server and run application level checks.
Useful options
| Option | Purpose |
|---|---|
| Format option | Say whether the backup is plain or tar |
| No parse WAL | Skip WAL parsing, needed for tar |
| Skip checksums | Faster, checks presence and size only |
| Exit on error | Stop at first problem |
| Wal directory | Find WAL stored outside the backup |
Availability
The tool ships with PostgreSQL versions that support backup manifests. Check your own server version's documentation for the exact options before scripting it.
Safeguard offers compliance and evidence automation, which can store dated proof that verification ran, alongside dependency scanning. Try the free scan.
Quick check
Does a passing verify mean I can restore?
It means the backup matches its manifest and has the WAL needed. It does not prove the data is right for your application, so keep restore tests.
Does it work on SQL dumps?
No. It is for base backups with a manifest, not for dump files.
Sources
Last reviewed: 19 October 2026.
