New to KubeDB? Please start with the KubeDB documentation.

Backup & Restore a TDE-Encrypted Postgres

A TDE-encrypted Postgres cannot use the community physical backup and WAL archiving path: the physical backup tool (pg_basebackup) and the WAL reader used for continuous archiving cannot read pg_tde-encrypted files or its custom WAL records. KubeDB ships pg_tde-aware equivalents for the physical path, so once you point at the right catalog entries, physical backup and restore work the same way you would expect. Logical backups are unaffected: KubeStash’s logical backup path already talks to Postgres over the normal protocol, described below.

Read the TDE overview and TDE guide first.

Logical backup & restore (KubeStash)

KubeStash logical backup uses pg_dump/pg_dumpall to back up and psql to restore, which talk to Postgres over the normal protocol and never touch the on-disk files directly, so a TDE cluster backs up exactly like a community one – no extra configuration needed on the BackupConfiguration/RestoreSession side. The postgres-addon used by KubeStash detects the Percona distribution automatically.

The one thing to plan for is the restore target:

• Restoring a TDE-encrypted dump into another TDE (Percona) cluster works as expected; data is re-encrypted under the target cluster’s own principal key.
• Restoring a TDE-encrypted dump into a non-TDE (community) Postgres is rejected: the dump contains pg_tde/tde_heap DDL that a community server cannot execute. The restore addon detects this up front and fails loudly instead of partially applying the dump.

Physical backup, continuous archiving & PITR

Follow the continuous archiving and PITR guide for the general PostgresArchiver setup (BackupStorage, RetentionPolicy, PostgresArchiver, spec.archiver.ref on the Postgres object). For a TDE cluster, the differences are:

• Full/base backups use pg_tde_basebackup instead of pg_basebackup (selected automatically whenever the database image is a Percona distribution – no field to set).
• WAL archiving and PITR recovery need a pg_tde-aware archiver image, because reading the commit LSN out of the WAL stream (for archiving) and replaying it (for recovery) both require registering pg_tde’s custom WAL resource manager, and – when spec.tde.encryptWAL: true – decrypting the WAL itself. Use a PostgresVersion whose spec.archiver.walg.image points at the Percona build of the archiver image (matching the -percona catalog entries used elsewhere in TDE, e.g. 17.9-percona), not the community build. The KubeDB installer ships the correct image per version; you only need to make sure you deployed the -percona PostgresVersion, the same one used to create the database.
• This applies whether or not spec.tde.encryptWAL is enabled: even with WAL encryption off, pg_tde still writes custom WAL records that a community WAL reader does not recognize.

With the Percona archiver image in place, PITR works the same for both encryptWAL: false and encryptWAL: true clusters. Either way, the original cluster’s principal key must still be resolvable through its key provider (Vault, KMIP, or file) at restore time: decrypting the archived WAL and the base backup’s pg_tde internal keys both depend on it, regardless of whether WAL encryption itself was on. Restore a Postgres with spec.init.archiver.recoveryTimestamp exactly as shown in the PITR guide.

Next Steps

• Review the TDE overview for the key hierarchy and limitations.
• Follow the TDE guide to deploy an encrypted Postgres, rotate the principal key, and enable WAL encryption.
• Learn about logical backup & restore with KubeStash.
• Learn about continuous archiving and point-in-time recovery.