Backup Encryption End to End with age, gpg, and restic

An unencrypted backup is a second copy of the data you were protecting, parked somewhere less defended. End-to-end encryption means the archive cannot be read by the storage provider, by a thief who steals a disk, or by an attacker who finds a compromised backup bucket. The price is key management: if the key goes away, the backups may as well not exist. This post covers the three mainstream layers, age, gpg, and restic's native crypto, and the habits that keep them recoverable.

age: the modern file-encryption default

age is a small, audited encryption tool designed for exactly the encrypt-a-file-before-moving-it job. Key generation is one command, and the file format is self-describing, so the recipient does not need your specific version of age to decrypt.

age-keygen -o backup.key
age-keygen -y backup.key > backup.key.pub
age -r $(<backup.key.pub) -o dump.sql.gz.age dump.sql.gz
age -d -i backup.key -o dump.sql.gz dump.sql.gz.age

The private key never touches the backup host after setup: the server holds only the public half and can encrypt all day, while the decrypting key sleeps in a password manager or a safe.

gpg: familiar and batch-friendly

gpg covers both symmetric encryption with a passphrase and asymmetric encryption with keys. For scheduled backups the asymmetric path is nicer: the server holds the public key only, so compromising the server cannot decrypt archives.

gpg --batch --yes -r backup@example.net   --encrypt --output dump.sql.gz.gpg dump.sql.gz
gpg --batch --yes --output dump.sql.gz dump.sql.gz.gpg

The secret key lives on a workstation or an offline card, never on the box that runs cron.

restic: crypto baked into the repository

If restic already runs your filesystem backups, encryption is already on: every chunk is AES-256 encrypted with keys derived from the repository password, and file names are obfuscated. The practical job is keeping the two secrets, the repository password and any copy of the master key, independent from the repository itself.

export RESTIC_REPOSITORY=sftp:offsite:/restic/app
export RESTIC_PASSWORD_FILE=/root/restic-password
restic key list -r sftp:offsite:/restic/app
restic key add -r sftp:offsite:/restic/app

Adding a second password with restic key add and storing it somewhere else means losing one password does not lock the archives forever.

Rules that keep encryption recoverable

• Store keys and passwords in at least two places, and never next to the archives.
• Encrypt on the source host; transport and storage stay ciphertext end to end.
• Test decryption as part of the monthly restore drill; a key that has not decrypted in 90 days is unproven.
• Print one emergency copy of the private key or repository password to paper in a safe, then document where it lives.

Encrypt in transit too

Encryption at rest protects the archive where it sleeps; SFTP and SSH protect it on the wire. Never pipe plaintext dumps over unencrypted channels. If your object store speaks only HTTPS, the age- or gpg-encrypted dumps you shipped stay doubly covered anyway.

Takeaway

End-to-end encryption is one command to start and a habit to maintain: keys off-box, decryption tested in drills, copies in two places. age for files, gpg for interoperability, restic when the repository already does the dedup — pick one layer, but never skip the three habits. The Netbay VPS that hosts your archives starts at netbayhosts.in; the keys stay with you.