PostgreSQL Backup Manifests: Verify Files Before Restore

Context

A PostgreSQL backup manifest describes the files a base-backup operation intended to produce and the information needed to check them. pg_verifybackup compares the stored backup against that manifest. This can catch transfer errors and missing files before an emergency, but it does not prove that the application can run from the recovered database.

Prerequisites

Identify the backup's PostgreSQL major version, format, compression, manifest location, required WAL, and transfer history. Keep an unchanged source copy and use an inspection account that does not modify the backup. This guide follows current PostgreSQL 18 documentation. Confirm tool compatibility, especially for WAL parsing, which depends on the relevant major version. Obtain an isolated recovery environment for the later server test.

Verify the artifact

1. Inventory the complete backup set after transfer or download. Confirm that the manifest belongs to this backup rather than a similarly named run. Record backup identity, source system identifier, creation time, storage location, and the verification tool version. A checksum list detached from its intended artifact is weak operational evidence.
2. Run the supported pg_verifybackup invocation against the copied artifact. For a plain-format test backup, an illustrative command is pg_verifybackup /srv/restore-test/basebackup; replace that example path with a verified backup path. The tool reads the backup and reports problems. Use documented format-specific options rather than bypassing checks merely to obtain a successful exit status.
3. Interpret the result by verification stage. A missing or malformed manifest, a missing file, a changed file checksum, and an unreadable required WAL record describe different failures. Preserve the exact diagnostic and compare the suspect copy with the original source. Some configuration and recovery-related files are intentionally treated differently, so read the documented exceptions before classifying every difference as corruption.
4. Perform a separate isolated recovery test using the approved restore procedure. Prevent the test server from reaching production applications or triggering outbound jobs. Confirm startup, database availability, representative records, and the intended backup identity. Verification checks required backup WAL under its documented rules; it does not automatically prove an entire later archive recovery window.

Diagnostic table

Illustrative scenario

A large backup is copied to a second storage system, and one file is truncated during an interrupted transfer. Verification catches the mismatch before the source backup expires. The team recopies the affected artifact, repeats verification, and completes a test recovery. The value is early detection with time to repair the copy, rather than a claim that a checksum guarantees recovery.

Correction and acceptance

Do not edit the manifest to make an unexpected file match. Preserve evidence, retrieve a trustworthy copy, and investigate the transfer or storage path. Record both successful verification and the isolated recovery outcome. If the backup starts but key application records are absent, revisit backup selection and recovery targets rather than declaring success from the tool result.

Monitoring and SOP

Schedule artifact verification after backup creation and material transfers, with alerts on missing results as well as failures. Retain tool versions, artifact identities, and diagnostic output. Rotate isolated recovery exercises across retained backup ages and destinations. Recheck the procedure after a PostgreSQL major upgrade so version-specific WAL validation remains part of the actual operating workflow.

Explore Clouvenix backup disaster recovery for implementation and operational handover.

Technical reference

• www.postgresql.org documentation
• www.postgresql.org documentation