pgBackRest 2.28 adds Azure storage and repairs forced restores
Azure repository support arrives alongside a correction to forced restores and control over automatic expiration. The release separates where backups live from how they are retained and restored.
A restore option that promises to overwrite files has to do exactly that. pgBackRest 2.28 repairs a case where restore with force behaved like force combined with delta. Timestamp and size comparisons could leave files unchanged when they should have been replaced. The July 20 release notes say ordinary restores and delta restores were unaffected. That distinction makes the correction relevant to a particular restore mode rather than every operation the tool performs.
The same release adds Azure repository storage and an option to disable automatic expiration after successful backups. These changes address separate parts of a backup system. Storage determines where retained data goes. Expiration determines which copies remain available. Restore semantics determine what happens when those copies are used to reconstruct a database directory.
I default to PostgreSQL for relational systems, and a backup tool's restore behaviour matters as much as its ability to finish a backup. An option named force deserves a precise interpretation. Reusing an existing file after a metadata comparison is a different operation from replacing that file, even when both operations are useful in other circumstances.
Restore begins with a destination check
The restore implementation in 2.28 contains a destination safeguard. When force or delta is requested, it checks for PG_VERSION or a backup manifest to establish that the destination is a recognizable database directory. Without either marker, it disables those options. Existing files in the destination can then cause the restore to abort.
This check gives an operator a useful explanation for a restore that refuses a populated directory despite an explicit option. The program needs evidence about what that directory represents. An option permitting work in an existing database directory does not authorize treating every populated path as one. That distinction protects the interpretation of the restore request before individual files are considered.
The bug fixed in this release concerns the later file replacement decision. A timestamp and file size can identify candidates for reuse, but those attributes do not say that the bytes necessarily match. When an operator selects an overwrite operation, the restore must follow that operation's contract. A metadata shortcut changes the requested behaviour if it leaves a file that should have been replaced.
Azure becomes a repository choice
The versioned configuration reference documents Azure authorization with either a shared key or a shared access signature. Repository configuration includes the choice of key type. The storage addition consequently belongs in repository configuration, rather than in a change to an application's SQL or database schema.
That separation is useful for PostgreSQL installations whose storage administration already includes Azure. A repository can fit the chosen object storage environment while pgBackRest remains responsible for its backup and restore operations. The feature does not turn the application's database connection into an Azure connection. It changes the destination used by the backup tooling.
I prefer to assess repository access together with the recovery procedure that needs it. Backup creation and restoration are distinct uses of the retained data. Choosing an authentication method is part of making that access explicit, and a procedure should identify which repository it intends to read without relying on the application deployment to explain the choice.
Expiration can follow a separate schedule
The new expire-auto option controls whether successful backups automatically run expiration. Disabling it permits a separate expiration process. It also removes the automatic cleanup that would otherwise apply after backup completion. Retaining everything indefinitely can exhaust repository space, so an independent expiration process needs an explicit owner and schedule.
An illustrative configuration fragment disables that automatic step:
[global]
expire-auto=n
This fragment expresses only the expiration decision. It is not a complete backup configuration, and it does not itself supply a replacement schedule. The distinction matters when an organization has a retention process separate from the process that creates backups. Moving the timing of cleanup leaves the retention requirement in place. Successful backup completion alone will no longer initiate that cleanup step.
The release file also records that time-based full-backup retention arrived in 2.27. It should therefore be understood as existing functionality when evaluating 2.28. The same applies to ad hoc expiration and newer compression choices listed in that earlier release. A version comparison needs to distinguish a newly added control from the capabilities already present around it.
For recovery, that history helps identify what changed in an upgrade. Azure storage and automatic-expiration control are additions in this release, while the forced-restore correction changes an existing operation. An operational procedure can then describe the intended repository and cleanup policy separately from the exact restore mode selected when rebuilding the database directory.