Use PostgreSQL manifest verification before an actual restore rehearsal

Record manifest checks and database restore acceptance as two separate recovery gates.

Source facts

PostgreSQL 17 pg_verifybackup checks a pg_basebackup backup against its server-generated backup_manifest. It expects plain-format files; a tar-format backup must first be extracted. Verification checks the manifest, the expected file set, file checksums, and required WAL information, with documented exceptions. It does not perform every check a running PostgreSQL server will perform. The project explicitly recommends test restores and checking that the resulting databases work as expected even when manifest verification succeeds.

Source: PostgreSQL 17 — pg_verifybackup.

Applicability

This applies to PostgreSQL 17 base backups with a usable manifest. It does not describe pg_dump archives, application acceptance testing, or an unconditional guarantee of recoverability.

DSE recommendation

DSE recommends giving manifest verification its own recorded result before scheduling the restore rehearsal. Preserve the manifest with the backup, retain all verification errors, and investigate unexpected files or changes rather than dismissing them as harmless. Keep the backup identity identical through verification and rehearsal so the evidence refers to the same artifact. Define application-level checks separately, including the records and relationships that matter to the service owner.

Verification

On an isolated copy, run the verification tool and retain its exit status. Then restore that same backup, allow recovery to complete, and perform the agreed application checks. Document a failed integrity check and a failed application check differently; each requires investigation before accepting the recovery point.

Official reference

PostgreSQL 17 — pg_verifybackup. Reviewed October 15, 2026.