Backup encryption

Configure password-protected ZIP or age-encrypted backups while keeping decryption values in Kubernetes.

RestoreTrust can decode password-protected ZIP containers and age-encrypted backup files before validation. Decryption values stay in a Kubernetes Secret in the selected project worker's job namespace.

Choose an encryption type

Backup protection	Secret key	Notes
Password-protected ZIP	`RT_ARCHIVE_PASSWORD`	Select when the container setting is Auto or ZIP
age recipient encryption	`RT_AGE_IDENTITY`	Contains one or more age identities
age passphrase encryption	`RT_AGE_PASSPHRASE`	One trailing newline is ignored

An age identity value can contain an age identity file or an unencrypted SSH private key accepted by age. Passphrase-protected identities and hardware-backed identities are not supported for unattended checks. Multiple identities can be included to support key rotation.

Configure encrypted backups

1
Prepare dedicated validation access
For recipient encryption, add a RestoreTrust validation recipient to the backup process and keep its private identity separate from the production recovery key. For passphrase or ZIP encryption, use a dedicated, rotatable value where possible.
2
Create the Kubernetes Secret
Put the applicable key above in a Secret in every selected project worker's job namespace. Register matching secret metadata under Secrets.
3
Configure the schedule
In the backup format settings, select age identity, age passphrase, or the ZIP password metadata as appropriate. Choose None only for input that is definitely not age-encrypted.
4
Verify with a manual run
Run the schedule manually and inspect the download and restore stages. Explicit format and encryption settings are enforced; a mismatch fails instead of being silently treated as another format.

Adding a recipient is not retroactive

A validation identity can decrypt only backups encrypted to its recipient. Backups created before that recipient was added remain unreadable unless they were also encrypted to another identity the worker has.

Rotation

For age recipient encryption, temporarily include both old and new identities in RT_AGE_IDENTITY, update the backup process to include the new recipient, and test both recent and retained backups as required. Remove the old identity only after its backup-retention window has passed.

For passphrases or ZIP passwords, historical backups generally still require their original value. Coordinate credential rotation with backup retention and separate schedules if different retained artifacts require different Secrets.

File checks decode only the encryption envelope. They do not unpack an archive or inspect database content; use a database restore schedule when content validation is required.

Loading documentation…

Choose an encryption type

Backup protection	Secret key	Notes
Password-protected ZIP	`RT_ARCHIVE_PASSWORD`	Select when the container setting is Auto or ZIP
age recipient encryption	`RT_AGE_IDENTITY`	Contains one or more age identities
age passphrase encryption	`RT_AGE_PASSPHRASE`	One trailing newline is ignored

Configure encrypted backups

Prepare dedicated validation access

For recipient encryption, add a RestoreTrust validation recipient to the backup process and keep its private identity separate from the production recovery key. For passphrase or ZIP encryption, use a dedicated, rotatable value where possible.

Create the Kubernetes Secret

Put the applicable key above in a Secret in every selected project worker's job namespace. Register matching secret metadata under Secrets.

Configure the schedule

In the backup format settings, select age identity, age passphrase, or the ZIP password metadata as appropriate. Choose None only for input that is definitely not age-encrypted.

Verify with a manual run

Run the schedule manually and inspect the download and restore stages. Explicit format and encryption settings are enforced; a mismatch fails instead of being silently treated as another format.

Adding a recipient is not retroactive

Rotation

File checks decode only the encryption envelope. They do not unpack an archive or inspect database content; use a database restore schedule when content validation is required.