pgBackRest 2.60.0 now stops restores on bad page checksums
A restore that hits a corrupted database page used to carry on; now it halts by default, and expire will not retire a backup that would leave checksum errors behind.
pgBackRest 2.60.0 shipped on 18 October, and it changes what happens when a restore finds a corrupted page. The release notes put it plainly: “The restore command will now error and stop if any restored file contains an invalid page checksum, which leaves the cluster incomplete and unable to start, so the restore must be rerun.” The expire command gets the same treatment: it will now refuse to expire a backup if doing so would leave the oldest retained backup with checksum errors in the repository.
The old warn-and-continue behaviour is still there, just opt-in now:
checksum-page-error=nThe release also adds Workload Identity Federation support for GCS, prefetching for multi-file and range reads from object stores, retries for missing Azure batch sub-requests, and confirms support for PostgreSQL 19rc1.
Why it matters: a restore that silently completes on top of a corrupted page is worse than one that fails, because you only find out when the cluster will not start, usually mid-incident. Erroring by default surfaces that during a routine restore test or DR drill instead. Anyone whose automation expects the old warn-only behaviour needs to set checksum-page-error=n explicitly after upgrading, or a previously harmless warning becomes a failed job.
The caveat: the notes don’t say how common these checksum errors actually are in practice, just that the default response to one has changed.