What changed
On October 18, 2026, pgBackRest 2.60.0 introduced checksum-page-error handling that changes default behaviour during restore and backup expiration. A restore now fails and stops when any restored file contains an invalid page checksum; the target PostgreSQL cluster is incomplete and cannot be started until restore is rerun. The expire command refuses to expire the oldest retained backup if doing so would leave the retained set with checksum errors, preventing associated archive expiry. Operators may choose checksum-page-error=n to log warnings rather than errors. Other 2.60 changes include GCS Workload Identity Federation, object-store multi-file/range prefetch and OpenSSL 4 build support.
Why it matters
Backup integrity checks are only useful if their failures change decisions. This release makes checksum corruption a hard recovery and retention boundary by default, rather than allowing operators to overlook warnings and continue. That protects against silently booting a damaged restored cluster or expiring a potentially needed clean recovery point, but it can also interrupt scripted restores and retention workflows that previously succeeded. Database operators should test their failure procedures, especially when time to recovery matters.
Restores can now fail instead of leaving warnings
pgBackRest's October 18 announcement explicitly says restore stops if a restored file contains an invalid PostgreSQL page checksum. The partially restored data directory is incomplete and the restore must be rerun. The documented restore default for checksum-page-error is y; the same option can be disabled to warn instead, but that knowingly accepts a recovery-integrity risk. This is separate from backup-time checksum validation, whose command-reference default for checksum-page-error remains n.
Retention now guards against expiring the wrong recovery point
The expire command refuses to expire the oldest retained backup if the resulting oldest retained backup would contain checksum errors; associated archive expiration is also prevented. That makes backup pruning sensitive to corruption history, so storage alerts and automated cleanup need to distinguish a deliberate safety stop from a broken scheduler.
Cloud storage and build changes are operationally relevant
Version 2.60 adds prefetch of multi-file and byte-range reads from object stores and GCS Workload Identity Federation, reducing dependence on static credentials for compatible Google Cloud deployments. OpenSSL 4 and illumos build support broaden supported environments. The announcement does not establish independent throughput gains, so performance should be tested against each repository and restore workload.