Backup Encryption
Encrypting backups, managing the keys so a restore is still possible, and separating backup credentials from database credentials.
A backup is a complete copy of your data, usually stored somewhere with different access controls from the database, and frequently for years. It deserves at least as much protection as the primary.
Encrypting
Most backup tools encrypt natively, which is preferable to piping through a separate tool because the metadata and the chain are handled consistently:
# pgBackRest
repo1-cipher-type = aes-256-cbc
repo1-cipher-pass = <from the secret manager># XtraBackup
xtrabackup --backup --encrypt=AES256 --encrypt-key-file=/etc/keys/backup.key
# mariabackup
mariabackup --backup --encrypt=AES256 --encrypt-key-file=/etc/keys/backup.key# Generic: encrypt a logical dump in the pipeline, never writing plaintext to disk.
pg_dump --format=custom shop \
| age -r age1qz... \
> /backups/shop-$(date -u +%Y%m%dT%H%M%SZ).dump.ageServer-side encryption in the object store is a useful additional layer and is not a substitute: it protects the bytes at rest in the provider, and anyone who can read the bucket still gets plaintext.
Key management
Also plan for:
- Key rotation. New backups use the new key; old backups still need the old one. Retain historical keys for as long as the backups they encrypt.
- Access separation. The account that writes backups should not be able to read or delete them; the account that restores should not be able to write.
- Deliberate destruction. Destroying the key is an effective way to render backups permanently unreadable, which is exactly what you want at the end of a retention period — and a disaster if the period had not actually expired.
Separate credentials from the database
Add immutability where the storage supports it — object lock, write-once retention — so nothing can delete a backup inside its retention window, including a compromised administrator.
Verify the encrypted path
The restore drill must exercise the encrypted backup, not an unencrypted copy made for convenience:
- Retrieve the key from the key management service, using the emergency access path.
- Restore the encrypted backup into an isolated environment.
- Verify the data, and record how long the whole thing took.
A drill that skips the key retrieval step has not tested the part most likely to fail.
Do not forget the intermediate copies
Plaintext frequently escapes into places the encryption plan did not consider: a temporary dump on local disk before upload, a staging environment restored from production, a developer's laptop, and a support ticket attachment. Encrypt in the pipeline so plaintext never touches disk, and apply the same controls to any environment restored from a production backup.