PG_VERIFYBACKUP(1)

💖 pg_verifybackup(1) — the vibe check for your base backup 💖

okay so bestie, this is the manual page for pg_verifybackup, and it's genuinely one of the most useful little tools in the PostgreSQL 15.19 lineup. it's the one that looks at your backup and goes "hmm, are we actually sure about this?" — and honestly? we love a friend who double-checks. 🫶

---

✨ NAME ✨

pg_verifybackup — verify the integrity of a base backup of a PostgreSQL cluster

no cap, that's the whole job. it checks that your backup is what it says it is. 🎀

---

✨ SYNOPSIS ✨

pg_verifybackup [option...]

that's it. that's the whole call. very demure, very mindful. 💅

---

✨ DESCRIPTION ✨

so here's the deal. pg_verifybackup checks the integrity of a database cluster backup that you took using pg_basebackup, and it does that by comparing your backup against a backup_manifest that the server itself generated at the time of the backup. 🔥

⚠️ important: the backup has to be stored in the "plain" format. if you've got a "tar" format backup, you can still check it — but only after you extract it. 💀

ngl, there's one thing you really need to internalize: the validation pg_verifybackup performs does not — and literally cannot — include every check that a running server will do when it tries to actually use the backup. so even if you use this tool, you should still do test restores and verify that the resulting databases work as expected and appear to contain the correct data. 😭 like, this tool is your bestie, not your only friend. but to be fair, it can detect many problems that commonly happen due to storage problems or user error, and that's already a lot. 💖

🦋 the four stages of verification 🦋

backup verification proceeds in four stages. here's the play-by-play:

Stage 1 — the manifest check. first, pg_verifybackup reads the backup_manifest file. if that file does not exist, cannot be read, is malformed, or fails verification against its own internal checksum, pg_verifybackup will terminate with a fatal error. periodt. 🚩

Stage 2 — the files-on-disk check. second, pg_verifybackup will attempt to verify that the data files currently stored on disk are exactly the same as the data files which the server intended to send, with some exceptions described below. extra and missing files will be detected, with a few exceptions. this step will ignore the presence or absence of, or any modifications to, postgresql.auto.conf, standby.signal, and recovery.signal, because it is expected that these files may have been created or modified as part of the process of taking the backup. it also won't complain about a backup_manifest file in the target directory or about anything inside pg_wal, even though these files won't be listed in the backup_manifest. only files are checked — the presence or absence of directories is not verified, except indirectly: if a directory is missing, any files it should have contained will necessarily also be missing. iykyk. 🌸

Stage 3 — the checksum check. next, pg_verifybackup will checksum all the files, compare the checksums against the values in the manifest, and emit errors for any files for which the computed checksum does not match the checksum stored in the manifest. this step is not performed for any files which produced errors in the previous step, since they are already known to have problems. files which were ignored in the previous step are also ignored in this step. no double-dipping. 🙈

Stage 4 — the WAL check. finally, pg_verifybackup will use the manifest to verify that the write-ahead log records which will be needed to recover the backup are present, and that they can be read and parsed. the backup_manifest contains information about which write-ahead log records will be needed, and pg_verifybackup will use that information to invoke pg_waldump to parse those write-ahead log records. the --quiet flag will be used, so that pg_waldump will only report errors, without producing any other output. 🔥

⚠️ while this level of verification is sufficient to detect obvious problems such as a missing file or one whose internal checksums do not match, they aren't extensive enough to detect every possible problem that might occur when attempting to recover. for instance, a server bug that produces write-ahead log records that have the correct checksums but specify nonsensical actions can't be detected by this method. 😬 so yeah. it's giving "good, not omniscient."

🧚 a couple more notes, bestie 🧚

note that if extra WAL files which are not required to recover the backup are present, they will not be checked by this tool, although a separate invocation of pg_waldump could be used for that purpose. 👀

also note that WAL verification is version-specific: you must use the version of pg_verifybackup, and thus of pg_waldump, which pertains to the backup being checked. in contrast, the data file integrity checks should work with any version of the server that generates a backup_manifest file. so the checksum side is chill and cross-compatible, and the WAL side is very much "we match versions in this house." 💅

---

✨ OPTIONS ✨

pg_verifybackup accepts the following command-line arguments:

• -e, --exit-on-error — exit as soon as a problem with the backup is detected. if this option is not specified, pg_verifybackup will continue checking the backup even after a problem has been detected, and will report all problems detected as errors. honestly, sometimes you want the full receipts, sometimes you just want out. 😌
• -i path, --ignore=path — ignore the specified file or directory, which should be expressed as a relative path name, when comparing the list of data files actually present in the backup to those listed in the backup_manifest file. if a directory is specified, this option affects the entire subtree rooted at that location. complaints about extra files, missing files, file size differences, or checksum mismatches will be suppressed if the relative path name matches the specified path name. this option can be specified multiple times. 🎀
• -m path, --manifest-path=path — use the manifest file at the specified path, rather than one located in the root of the backup directory. iconic for when you've stashed the manifest somewhere secure. 🔐
• -n, --no-parse-wal — don't attempt to parse write-ahead log data that will be needed to recover from this backup. skipping the WAL era. ✌️
• -q, --quiet — don't print anything when a backup is successfully verified. silent slay. 🤫
• -s, --skip-checksums — do not verify data file checksums. the presence or absence of files and the sizes of those files will still be checked. this is much faster, because the files themselves do not need to be read. ⚡
• -w path, --wal-directory=path — try to parse WAL files stored in the specified directory, rather than in pg_wal. this may be useful if the backup is stored in a separate location from the WAL archive. 🗂️

🌈 other options are also available 🌈

• -V, --version — print the pg_verifybackup version and exit. 👑
• -?, --help — show help about pg_verifybackup command line arguments, and exit. 🫶

---

✨ EXAMPLES ✨

🌸 example 1: backup and verify 🌸

to create a base backup of the server at mydbserver and verify the integrity of the backup:

$ pg_basebackup -h mydbserver -D /usr/local/pgsql/data
$ pg_verifybackup /usr/local/pgsql/data

🦋 example 2: manifest goes on a field trip 🦋

to create a base backup of the server at mydbserver, move the manifest somewhere outside the backup directory, and verify the backup:

$ pg_basebackup -h mydbserver -D /usr/local/pgsql/backup1234
$ mv /usr/local/pgsql/backup1234/backup_manifest /my/secure/location/backup_manifest.1234
$ pg_verifybackup -m /my/secure/location/backup_manifest.1234 /usr/local/pgsql/backup1234

💜 example 3: there's a lil extra file in there 💜

to verify a backup while ignoring a file that was added manually to the backup directory, and also skipping checksum verification:

$ pg_basebackup -h mydbserver -D /usr/local/pgsql/data
$ edit /usr/local/pgsql/data/note.to.self
$ pg_verifybackup --ignore=note.to.self --skip-checksums /usr/local/pgsql/data

(ngl, note.to.self is such a mood. we all leave little notes for ourselves in our data directories. 💀)

---

✨ SEE ALSO ✨

pg_basebackup(1) — the one that made the backup in the first place. the origin story. 🌟

---

✨ and that's the whole page! this was PostgreSQL 15.19, dated 2026 — so go forth, verify your backups, do your test restores, and remember: a backup you haven't verified is just a folder of hope. 💖🎀🦋💅