How to encrypt backups

Quick answer: Encrypt backups before or as they leave the source: restic and borg encrypt by default with a passphrase you choose, and gpg can wrap plain tar/SQL archives. Store the passphrase somewhere that survives losing the server — encrypted backups with a lost key are just noise.

Overview

Encryption protects the copies, which usually travel further and live longer than the originals. With client-side encryption, the storage server only ever sees ciphertext — even someone with full access to the Storage VPS reads nothing. The trade: key management becomes part of your disaster recovery plan.

Before you start

• A backup pipeline to protect (setup guide).
• A decision on tooling: restic/borg (encryption built in) vs gpg on top of tar/rsync.
• A safe place for keys and passphrases off the servers: password manager plus an offline copy.

Step-by-step guide

1. restic — encrypted, deduplicated, incremental:

   restic -r sftp:[email protected]:/srv/backups/web1 init
   restic -r sftp:[email protected]:/srv/backups/web1 backup /var/www /etc

   The passphrase you set at init encrypts everything; without it the repo is unreadable.
2. borg — same idea:

   borg init --encryption=repokey-blake2 [email protected]:/srv/backups/web1/repo
   borg create ssh://[email protected]/srv/backups/web1/repo::{now} /var/www /etc

   With repokey, export the key too: borg key export — store the export with your passphrase.
3. gpg for classic archives:

   tar czf - /var/www | gpg --symmetric --cipher-algo AES256 -o web-$(date +%F).tar.gz.gpg

   Decrypt with gpg -d web-2026-07-15.tar.gz.gpg | tar xzf -.
4. Escrow the secrets: passphrase + (for borg) exported key into the password manager and one offline location; add "retrieve backup keys" as step zero of your DR plan.
5. Test a decrypt-restore quarterly — encryption adds one more thing that must work under stress (see integrity testing).

Common issues

• Passphrase stored next to the backups: a PASSWORD.txt in the repo directory defeats the whole exercise.
• Key existed only on the dead server: the most common total-loss story — escrow before the first nightly run.
• Encrypting the only copy in place: encryption is for the backup copies; do not replace plain local data with an encrypted blob and call it done.

When to contact support

Cloud2Y cannot recover a lost encryption passphrase — nobody can, that is the point. For anything infrastructure-side (transfer failures, disk errors on the repo), open a ticket.

Frequently asked questions

Do restic and borg encrypt backups by default?

Yes — both encrypt all data client-side with a passphrase you set when initialising the repository, so the storage server only ever holds ciphertext it cannot read.

What happens if I lose the backup passphrase?

The data is unrecoverable — by design, nobody including Cloud2Y can decrypt it. Escrow the passphrase (and borg key export) in a password manager plus one offline copy first.

How do I encrypt plain tar or SQL backups?

Pipe them through gpg, e.g. "tar czf - /var/www | gpg --symmetric --cipher-algo AES256 -o site.tar.gz.gpg" — one command adds strong encryption to any classic archive workflow.

Related articles

• How to secure backup access
• How to test backup integrity
• How to create a disaster recovery plan
• Backup retention policy explained

Need reliable space for your backups? Order a Storage VPS at Cloud2Y →