Backups
Backup encryption basics: protect copies at rest and in transit
Backup encryption protects data when the backup destination, transport media, or copied archive is accessed outside the intended recovery workflow. The important design questions are where encryption happens, who controls the key, how keys are backed up, and whether an emergency restore can still obtain them.
Separate transport and at-rest encryption
SFTP/TLS can protect data while it moves, while repository/file encryption protects the stored backup itself. One does not automatically provide the other.
If the backup server can decrypt everything with the same credentials an attacker steals from production, the design may share more risk than expected.
Decide who owns recovery keys
Client-side encryption gives the source/operator control but makes key loss catastrophic. Store keys or recovery material in a separate protected system with access that does not depend on the destroyed server.
Use role-specific credentials and keep a universal master secret out of individual backup scripts.
Plan rotation without orphaning old backups
Changing encryption keys must account for existing archives. Decide whether old data remains decryptable with archived keys, is re-encrypted, or expires before old key retirement.
Document key version alongside backup metadata without exposing secret material.
Test decrypt-and-restore
A backup can upload successfully while the key file is missing or wrong. Recovery drills should retrieve credentials from the emergency path, decrypt a real archive, and validate the data/application.
- Protect transport and stored data.
- Keep keys outside the source failure domain.
- Version/rotate keys deliberately.
- Test decryption during restore drills.