Knowledgebase

An unencrypted backup is a single point of failure for your entire security posture — if it's ever accessed by an unauthorized party, all the data it contains is fully exposed. This guide covers encrypting backups properly.

Why Encrypt Backups

• Backups often contain the same sensitive data as production (customer data, credentials) but with potentially weaker access controls at the storage destination
• Off-site storage (object storage, a secondary server) is an additional location that could be compromised independently of your primary server
• Compliance requirements often specifically mandate encryption of backups containing personal data

Symmetric Encryption with GPG (Simple, Widely Compatible)

gpg --symmetric --cipher-algo AES256 backup.sql.gz

You'll be prompted for a passphrase — this same passphrase is required to decrypt later, so store it securely and separately from the backup itself.

Decrypting:

gpg --decrypt backup.sql.gz.gpg > backup.sql.gz

Automating Encrypted Backups

sudo nano /usr/local/bin/backup-encrypted.sh

#!/bin/bash
TIMESTAMP=$(date +%F)
BACKUP_DIR="/var/backups"
PASSPHRASE_FILE="/root/.backup-passphrase"

mysqldump -u root --all-databases | gzip > "$BACKUP_DIR/backup-$TIMESTAMP.sql.gz"

gpg --batch --yes --passphrase-file "$PASSPHRASE_FILE" \
  --symmetric --cipher-algo AES256 \
  "$BACKUP_DIR/backup-$TIMESTAMP.sql.gz"

rm "$BACKUP_DIR/backup-$TIMESTAMP.sql.gz"

sudo chmod 600 /root/.backup-passphrase

Restricting the passphrase file to root-only access is critical — anyone who can read it can decrypt every backup.

Asymmetric Encryption with GPG (Better for Automated, Unattended Backups)

Rather than a shared passphrase, encrypt with a public key — only the corresponding private key (which never needs to exist on the backup-creating server) can decrypt:

gpg --encrypt --recipient [email protected] backup.sql.gz

This is generally preferable for unattended cron jobs, since the encryption key on the server can't itself decrypt anything.

Encrypting Before Upload to Object Storage

gpg --symmetric --cipher-algo AES256 backup.sql.gz
aws s3 cp backup.sql.gz.gpg s3://your-backup-bucket/ --profile backup

Server-Side Encryption at the Storage Provider

Many object storage providers also offer server-side encryption at rest as a bucket-level setting — this protects against unauthorized access to the storage infrastructure itself, but is complementary to, not a replacement for, client-side encryption before upload, since server-side encryption doesn't protect against a compromised access credential.

Key/Passphrase Management

• Never store the decryption passphrase/key in the same location as the encrypted backups
• Document where the passphrase is stored as part of your disaster recovery plan — see How to Create a Disaster Recovery Plan for Your VPS
• Losing the passphrase means losing access to your backups permanently, so treat it with corresponding care

Testing Decryption

As part of your regular backup verification (see How to Test and Verify Your Backups Actually Work), confirm you can actually decrypt a backup successfully — not just that encryption completes without error.

Common Errors

"gpg: decryption failed: No secret key" — attempting to decrypt with the wrong key, or the private key isn't available on the machine attempting decryption.

Forgot the passphrase — there is generally no recovery mechanism for a forgotten symmetric encryption passphrase; this underscores the importance of secure, redundant passphrase storage.

Best Practices

• Encrypt any backup containing sensitive or personal data
• Store the decryption key/passphrase separately from the encrypted backups themselves
• Test decryption periodically as part of backup verification

Related Articles

• How to Back Up to Object Storage (S3-Compatible)
• How to Test and Verify Your Backups Actually Work
• How to Manage Environment Variables and Secrets on a VPS