pgBackRest 2.58.0 changes the object storage contract

pgBackRest 2.58.0, released on January 19, changes several assumptions around object storage. Azure managed identities become available, S3 EKS pod identity arrives experimentally, and upload chunks adapt to file size. The release notes also raise minimum chunk sizes and require TLS 1.2 or later unless verification is disabled. These changes affect the connection between a PostgreSQL installation and its backup repository, which is a part of an upgrade I would examine before changing the production binary.

I have run PostgreSQL in production for decades and still choose it by default for relational work. My confidence in the database does not remove the need to understand its backup dependencies. A backup design includes the identity that can access the repository and the configuration needed to read it during recovery. This release makes me particularly interested in whether those dependencies remain available when a restore happens outside the environment that normally creates the backups.

File size changes the upload behavior

The release notes describe two related improvements. pgBackRest dynamically sizes S3, GCS and Azure upload chunks for large uploads, and optimizes chunk size for small files. They also call out an incompatible configuration assumption. The minimum values accepted by repo-storage-upload-chunk-size have increased to match the vendors' minimums. An existing override therefore deserves attention even if the storage endpoint has not changed.

The configuration definitions shipped with 2.58.0 make those limits concrete. Azure and GCS default to 4 MiB, with an allowed range starting at 4 MiB. S3 defaults to 5 MiB, with an allowed range starting at 5 MiB. Each has an upper bound of 1 GiB for this option. I would check an explicit value against the repository type before treating an old configuration as suitable for the new binary.

These are configuration bounds, and the release separately describes dynamic sizing during uploads. I would avoid reading the default as a promise that every upload uses chunks of exactly that size. The practical question is whether a deployment has overridden a setting whose accepted range has changed. Removing an unnecessary override may be preferable to preserving a number whose original justification nobody can explain.

The notes do not provide a performance measurement for a particular database or storage provider. I would therefore evaluate the change with the file sizes and repository used by the installation concerned. A faster backup would be useful, but I would also want to confirm that the same repository remains readable in the recovery environment. Checking both backup and restore is a reasonable acceptance criterion for a change to the storage connection.

Cloud identity becomes part of recovery planning

The community announcement identifies Azure managed identities as a new capability and labels S3 EKS pod identity experimental. That qualification matters to my adoption decision. I would assess the experimental integration separately from the decision to upgrade pgBackRest itself, particularly if an existing authentication method already meets the deployment's requirements.

The versioned configuration definitions distinguish the mechanisms. repo-azure-key-type accepts shared, sas and auto, while repo-s3-key-type accepts shared, auto, web-id and pod-id. The available modes make clear that adding an identity integration does not require every repository to switch authentication methods. It creates another deployment choice that needs its own recovery procedure.

I like the prospect of reducing manually distributed storage credentials. I would still ask how a replacement host obtains access and which identity the recovery process will use. Those are design questions, not evidence that either new integration is defective. My preference would be to document the normal backup identity and the recovery identity separately whenever they differ, then test the actual route selected for recovery.

The announcement lists support for multiple repositories and remote operation through SSH or TLS among pgBackRest's existing capabilities. That breadth is useful, but it means a successful backup in one environment does not answer every access question in another. I would include the relevant repository and authentication mode in a restore rehearsal instead of assuming that the normal backup job has exercised them all.

Transport changes need configuration review

HTTP support for S3, GCS and Azure is another new capability. At the same time, the release tightens the TLS requirement to version 1.2 or later. The notes say that disabling verification relaxes this requirement, and the announcement advises against doing so. I would treat a connection failure after the upgrade as a reason to inspect the endpoint and its TLS configuration before considering any change to verification.

The release permits configuration of TLS cipher suites. That gives operators another setting to review alongside the protocol requirement. I would keep the investigation focused on the actual endpoint and policy involved, since the announcement does not establish that every deployment needs a cipher override. Adding configuration without a specific requirement would create another value to preserve during recovery.

Two other changes affect upgrade scope. pgBackRest removes PostgreSQL 9.5 support under its policy of supporting five end-of-life PostgreSQL versions. It adds the ability to expire the oldest full backup regardless of current retention. I would check server compatibility before rollout and assess the expiration capability against the recovery history the installation must retain. Neither should become an incidental consequence of adopting the object storage improvements.

For this release, my acceptance work would concentrate on existing chunk-size overrides and the selected storage authentication mode. I would then rehearse a restore using the intended recovery environment, keeping TLS verification enabled. That would give me evidence about the configuration I need to operate, including the dependencies that a routine backup job may not exercise.