pgBackRest brings repository encryption into PostgreSQL backup management

Putting a database backup in remote storage introduces a second place where the database's contents need protection. The database's normal access controls do not define who can read files in that repository. Crunchy Data's December 13 pgBackRest announcement reviews repository encryption alongside S3 support and page-checksum validation, with encryption available across supported repository storage.

The announcement summarizes improvements since version 1.09 in October 2016. It should not be read as a claim that every listed capability first appeared in December. The 1.26 release notes at its tag date that version to November 21 and identify repository encryption as its principal addition. December's announcement presents the accumulated backup capabilities to PostgreSQL users.

I regard backup handling as part of operating PostgreSQL, not an incidental file-copy task. A relational database remains useful after a failure only if its stored backup and required recovery data can be used together. Repository encryption adds a separate requirement, keeping the means of decrypting that data available to the recovery process.

Encryption belongs to repository configuration

The announcement specifies AES-256 encryption on any supported repository storage. This puts the encryption capability in pgBackRest's repository handling. It is not limited to the S3 storage option, and the description does not depend on an object store providing the encryption interface itself.

The user guide at the 1.26 tag describes configuring a cipher type and key before creating and checking the stanza. It recommends a long random passphrase and identifies the companion C library as a requirement for encryption. These details make encryption an explicit deployment configuration, not merely an attribute of the destination path.

Once the repository is configured and the stanza created and checked, the encryption settings cannot be changed. That is a substantial lifecycle boundary. Choosing the settings at initialization determines how the repository will subsequently be read, so the configuration must be treated as part of the recovery arrangement.

Encryption also addresses a different property from successful backup transfer. A completed transfer establishes that pgBackRest stored the required data according to its operation. Encryption governs how that stored data is represented and what is needed to read it. Neither property alone establishes the other.

Stanzas and checks record backup configuration

The announcement highlights stanza-create and stanza-upgrade as the stanza-management commands. The tagged guide says stanza-create initializes the stanza on the repository host. It recommends running check afterward to verify that archiving and backup configuration work together.

For an installation already configured with a stanza called demo, the documented command forms are:

pgbackrest --stanza=demo --log-level-console=info stanza-create
pgbackrest --stanza=demo --log-level-console=info check

These commands assume that the database connection and repository settings have been supplied. They do not create an encryption policy from nothing. Their place in the setup sequence is after configuration, when pgBackRest can initialize the intended stanza and check the resulting arrangement.

Version 1.26 also fixes retrieval of archived WAL for older database versions after stanza-upgrade. Previously, archive-get checked only the most recent database version and identifier, which could prevent recovery of a backup from the previous version. The correction makes the recorded history useful for recovering those earlier backups.

That fix is relevant because upgrading a database does not immediately make its older backups irrelevant. A repository may need to retain a recoverable history across that transition. Looking only at the newest database identifier would discard information the recovery command still needs.

Checksums inspect the source pages

The December announcement says pgBackRest automatically validates page checksums when PostgreSQL has them enabled, on PostgreSQL 9.3 and later. The qualification matters. Backup software cannot validate PostgreSQL page checksums that the database was never configured to maintain.

This validation concerns the integrity of the database pages being backed up. Repository encryption concerns protecting their stored contents. They contribute different information about the backup, so neither should be described as a replacement for the other.

I find this division useful because a backup can preserve a problem as faithfully as it preserves valid data. Checking page checksums during backup gives the operation an opportunity to detect an integrity failure present in the source pages. Encrypting those pages afterward would not resolve such a failure.

Remote storage still needs a recovery chain

S3 support allows repositories in S3 buckets. The announcement also describes multithreaded asynchronous archiving that no longer maintains a separate WAL queue. These changes concern where backup data lives and how archived WAL reaches the repository, while the database still needs the appropriate WAL to recover a backup consistently.

The tagged guide says a backup ensures its required WAL range is in the archive before completing. Its info output distinguishes database size, backup size, and repository size, and lists additional backups required for restoration. An incremental backup's visible size is therefore not the size of its complete recovery dependency set.

Up to seven standbys can be configured for backup-from-standby selection, with the first active standby used. Together with the WAL-history fix, this makes configuration identity and recovery dependencies concrete parts of backup management. The December announcement gathers those capabilities around a repository whose initialization now includes a fixed encryption configuration.