Encrypting Backups Properly

1. Why unencrypted backups are a security risk

An unencrypted backup contains exactly the same sensitive data as the production system, often even more, because older data states and deleted records still exist within it. While the production system is usually secured through firewalls, monitoring, and access controls, a backup frequently ends up on external storage media, in cloud storage, or on removable drives, where that protection does not automatically travel along. Backup encryption closes exactly that gap.

Legally, GDPR tightens this requirement further: personal data must be protected according to the state of the art, and a stolen, unencrypted backup medium generally counts as a reportable data breach. A medium protected through backup encryption, on the other hand, remains unreadable even after physical theft, as long as the key was not compromised as well, which defuses the reporting obligation in many cases.

2. Encryption at rest versus in transit

Backup encryption has to address two different threat scenarios simultaneously. Encryption in transit protects data during transfer, for instance while uploading to an offsite target, usually through TLS. Encryption at rest, on the other hand, protects data in its stored state, regardless of whether it is currently being transferred or sitting idle. Both layers are necessary for complete backup encryption, because TLS alone does not protect against a stolen storage medium, and an encrypted file alone does not protect against an intercepted, unencrypted transport channel.

The most robust approach combines client side encryption, meaning backup encryption applied before the data ever leaves the source system, with additional TLS protection of the transport path. That way, even a compromised intermediate server or a curious cloud provider never sees unencrypted data, which clearly favors client side backup encryption over server side encryption performed by the storage provider.

3. GPG based encryption of backup archives

GnuPG (GPG) is the standard tool for asymmetric backup encryption on Linux. A backup archive is encrypted with the recipient's public key, so only the owner of the matching private key can decrypt it again. This approach is particularly well suited for automated backup encryption, because the public key can safely live on the backup server, without anyone with access to that server alone being able to decrypt anything.

In practice, a tar archive is generated and piped directly into GPG, so an unencrypted intermediate file never touches the disk. This streaming encryption matters for production backup encryption, because an unencrypted intermediate file, even if only present for seconds, opens an additional window of opportunity for an attacker with filesystem access.

#!/usr/bin/env bash
# gpg-backup-encrypt.sh — asymmetric backup encryption, no plaintext temp file
set -euo pipefail

readonly SOURCE_DIR="/var/www/html"
readonly OUTPUT_FILE="/var/backup/encrypted/site-$(date +%Y%m%d).tar.gz.gpg"
readonly RECIPIENT="backup@mironsoft.de"

mkdir -p "$(dirname "$OUTPUT_FILE")"

# Stream tar directly into gpg — no unencrypted archive ever touches disk
tar -czf - -C "$SOURCE_DIR" . | \
  gpg --encrypt \
      --recipient "$RECIPIENT" \
      --trust-model always \
      --output "$OUTPUT_FILE"

echo "[OK] Encrypted backup written to $OUTPUT_FILE"

# Decryption (only possible with the matching private key):
# gpg --decrypt "$OUTPUT_FILE" | tar -xzf - -C /restore/target

4. Key management: where to keep private keys safe

The strongest backup encryption is worthless if the private key is kept insecurely, for instance on the same server that also stores the encrypted backups. An attacker who gains access to that single server would then obtain both the encrypted data and the key that unlocks it, rendering the entire backup encryption ineffective. The private key must therefore be kept strictly separate from the encrypted backups, ideally on a dedicated, especially protected system or in a hardware security module.

For smaller environments, an offline key on an encrypted USB stick, only plugged in for an actual restore, is a pragmatic solution. Larger setups benefit from a dedicated secret store such as HashiCorp Vault or a cloud KMS, which logs key access and restricts it under the principle of least privilege. Either way, backup encryption without a documented, tested key recovery strategy is a risk, because a lost key permanently renders every backup encrypted with it unusable.

; gpg-agent.conf — key handling policy for backup encryption
; Located at ~/.gnupg/gpg-agent.conf on the dedicated backup key host

; Never cache the passphrase longer than necessary for a single operation
default-cache-ttl 60
max-cache-ttl 120

; Require pinentry confirmation for every private key operation
pinentry-program /usr/bin/pinentry-curses

; Log key usage for audit purposes
log-file /var/log/gpg-agent-key-usage.log
verbose

5. OpenSSL as an alternative for symmetric encryption

For cases where full GPG key pair management is too much overhead, openssl enc provides a simpler, symmetric backup encryption using a single shared password. AES-256 in GCM mode provides both confidentiality and integrity protection, which matters for backup encryption because a tampered encrypted archive could otherwise be restored unnoticed. The decisive downside compared to GPG: the password itself has to be shared securely across every system that needs to encrypt or decrypt, which quickly becomes a weak point with multiple people involved.

OpenSSL based backup encryption is therefore best suited for single server scenarios with one responsible person, or as a quick interim solution before a full GPG or secret store infrastructure is built. For teams with multiple authorized people, asymmetric backup encryption with GPG is generally preferable, because each person can keep their own private key instead of sharing a common secret.

#!/usr/bin/env bash
# openssl-backup-encrypt.sh — symmetric backup encryption with AES-256-GCM
set -euo pipefail

readonly SOURCE_DIR="/var/www/html"
readonly OUTPUT_FILE="/var/backup/encrypted/site-$(date +%Y%m%d).tar.gz.enc"
readonly PASS_FILE="/etc/backup/encryption.pass"  # chmod 600, root only

if [[ ! -f "$PASS_FILE" ]]; then
  echo "[ERROR] Passphrase file missing: $PASS_FILE" >&2
  exit 1
fi

tar -czf - -C "$SOURCE_DIR" . | \
  openssl enc -aes-256-gcm -pbkdf2 -iter 100000 \
    -pass "file:$PASS_FILE" \
    -out "$OUTPUT_FILE"

echo "[OK] Symmetrically encrypted backup written to $OUTPUT_FILE"

# Decryption:
# openssl enc -d -aes-256-gcm -pbkdf2 -iter 100000 \
#   -pass "file:$PASS_FILE" -in "$OUTPUT_FILE" | tar -xzf - -C /restore/target

6. restic and Borg: built-in encryption in modern tools

Modern backup tools such as restic and Borg Backup integrate encryption directly into their repository format, instead of adding it as an afterthought via GPG or OpenSSL. With restic, every repository is encrypted by default, there is no option to create a repository without encryption at all. This built-in backup encryption uses AES-256 combined with Poly1305 authentication and additionally deduplicates data before encrypting it, which saves storage without compromising security.

Borg Backup follows a similar approach with repokey or keyfile encryption modes. In repokey mode, the encryption key itself is stored encrypted within the repository and protected by a passphrase, which makes backup encryption particularly simple but elevates the passphrase to a critical single point of failure. Keyfile mode separates key and repository more strongly, similar to the GPG key separation from section four, and is preferable for production environments with higher security requirements.

#!/usr/bin/env bash
# restic-encrypted-backup.sh — built-in encryption, deduplication, and offsite target
set -euo pipefail

export RESTIC_REPOSITORY="s3:s3.eu-central-1.example-cloud.com/mironsoft-backups"
export RESTIC_PASSWORD_FILE="/etc/backup/restic.pass"  # chmod 600

# Repository is always encrypted — restic refuses to create an unencrypted one
if ! restic snapshots &>/dev/null; then
  restic init
fi

# Deduplicated, encrypted backup of the source directory
restic backup /var/www/html --tag nightly

# Verify encryption is enforced and check repository integrity
restic check

echo "[OK] Encrypted, deduplicated backup completed"

7. Combining with encrypted offsite transport

Backup encryption unfolds its full effect only in combination with an offsite strategy, because that is exactly where the backup leaves the physical control of your own data center. An archive already encrypted with GPG or restic can safely be synced via rclone to a cloud target, with no additional server side encryption necessary, because the data is already unreadable before the transfer even starts. The cloud provider itself therefore never gets unencrypted access to the content.

It still matters that the transport path itself is secured via TLS, because double protection, backup encryption plus TLS, additionally guards against metadata leaks such as file sizes or access patterns, which could allow inferences even with encrypted content. This combination of client side backup encryption and transport encrypted offsite sync is the gold standard for backups protected against both physical access and network eavesdropping.

8. Performance overhead and compression before encryption

Backup encryption costs CPU time, in practice usually far less than feared, because AES on modern hardware is accelerated almost without measurable overhead through the AES-NI extension. The far bigger performance factor is the order of compression and encryption: data always has to be compressed first and only then encrypted, never the other way around. Encrypted data looks like random noise to a compression algorithm and can practically no longer be compressed, which needlessly bloats an archive that was already encrypted and then compressed.

Every approach shown in this article automatically respects that order, tar compresses before GPG or OpenSSL encryption, restic and Borg deduplicate and compress internally before their built-in backup encryption. Anyone building their own scripts should explicitly verify this order, because a swapped step remains technically functional but produces needlessly large and slow backups.

9. Encryption methods compared

Choosing the right backup encryption depends on team size, existing infrastructure, and automation requirements.

For most production Linux server setups, restic or Borg with built-in backup encryption is the most pragmatic choice, because encryption, deduplication, and compression come from a single source and no separate script pipeline with manual ordering logic has to be maintained. GPG remains relevant when multiple people need to be able to decrypt independently of each other.

10. Summary

Backup encryption is not an optional add-on, but a basic requirement as soon as a backup leaves your own server, whether onto an external medium or to a cloud target. GPG offers asymmetric encryption with clean key separation for teams, OpenSSL a simple symmetric alternative for single servers, and modern tools such as restic and Borg integrate backup encryption directly into their repository format, combined with deduplication.

Regardless of the chosen tool, key management decides success or failure: a private key kept separate from the backup itself, documented, and regularly verified for functionality as part of restore tests turns backup encryption into a reliable safeguard instead of an additional point of failure.

11. FAQ: Encrypting Backups Properly