Pg_tde_archive_decrypt/pg_tde_restore_encrypt limitation in pgbackrest

PostgreSQL PG_TDE – Transparent Data Encryption (TDE)
1

Hey,

wondering why you added the requirement to decrypt/encrypt the WAL if pgbackrest is used in the limitations documentation.

I remember it wasn’t there before.

We are currently using pgbackrest without encrypt/decrypt and it works fine. No problems with Restores or anything else. Is it just to make sure that the WAL Files could be used on a (non encrypted) standby or other external tool?

2

@grill

The limitation:- Limitations of pg_tde - Percona Transparent Data Encryption for PostgreSQL mentions that the following options should be set in PgBackRest to allow pg_tde WAL encryption.

Need to Configure/Enable:

pg_tde_archive_decrypt
`pg_tde_restore_encrypt

Need to disable them:

archive-async
archive-header-check
checksum-page

PgBackRest will still work if you are not using the WAL encryption option; however, if you want to apply it, then it must be configured as mentioned above. The underlying tool, PgBackRest itself, doesn’t need to know about the encryption or decryption mechanism. The tool will simply recognise the WALs once they are decrypted by the pg_tde process.

E.g,

archive_command='pg_tde_archive_decrypt %f %p "pgbackrest --stanza=your_stanza archive-push %%p"'

Yes, other external tools can use the WAL unless they are managed by the pg_tde wal encryption.

3

That is why I am confused. We have WAL encryption activated but have not set the encrypt/decrypt commands and everything works just fine.

We have disabled the flags like archive-header-check.

4

Hi,

Offhand, it sounds like there’s a bit of communication confusion. The issue about tde is pgbackrest being able to understand the WAL when it’s encrypted. You may not have a problem by virtue of the manner your implementation.

If you think it’s worth your time, maybe you can describe the exact steps you are performing.

5

Hi Robert,

sure: we setup the postgres cluster on debian following the installation in your docs:

Percona Server for PostgreSQL 18.6.1
KMS is vault.

Afterwards we activated WAL encryption. To confirm that WAL encryption is working we inserted some data and used hexdump to verify it is encrypted.

This is the postgresql.conf we use:

shared_preload_libraries = 'pg_stat_statements, pg_tde'
pg_tde.wal_encrypt = on
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

notice that no decrypt is used.

This is the pgbackrest.conf:

[global]
repo1-type=s3
repo1-path=/main
repo1-s3-uri-style=path
repo1-s3-endpoint=xxx.internal
repo1-s3-region=us-east-1
repo1-s3-bucket=dev-dbbackup
repo1-s3-key=xxx
repo1-s3-key-secret=xxx

repo1-storage-verify-tls=n

start-fast=y
process-max=4

archive-async=n
archive-header-check=n

[main]
pg1-path=/var/lib/postgresql/18/main
pg1-port=5432
pg1-user=postgres

To restore, we use no additional options. For PITR this works:
sudo -u postgres pgbackrest --stanza=main --type=time --target="2026-09-10 10:44:00+02" restore

For a complete restore:
sudo -u postgres pgbackrest --stanza=main restore

Either removing all postgres data with sudo rm -rf /var/lib/postgresql/18/main/ or using the --delta option works.

During restore I do not modify the restore_command of pgbackrest, so it is the default restore_command = 'pgbackrest --stanza=main archive-get %f "%p"'

pg_tde_archive_decrypt and pg_tde_archive_encrypt are not used at all.
My questions is why the documentation tells you that you must use these commands.
This notice was not there when we first set up the system a few months ago, so something had to happen in the meantime that this is “forced” now.