Skip to main content

Encrypt Database Backups

Database dumps contain sensitive data (users, hashes, API keys, orders). If you store DB backups offsite, encrypt them. The safest pattern is: dump -> compress -> encrypt -> verify.

Quick Summary
  • Prefer streaming pipelines to avoid plaintext files on disk.
  • Compress first, then encrypt.
  • Verify by decrypting and testing the compressed layer.

Stream: mysqldump -> zstd -> gpg​

This produces one encrypted artifact.

dump-compress-encrypt-db.sh
mysqldump --single-transaction --quick wordpress \
  | zstd -3 -T0 \
  | gpg --symmetric --cipher-algo AES256 --output "/backups/wp-db-$(date +%F).sql.zst.gpg"

Verification​

Decrypt to stdout and test the inner compression:

verify-encrypted-db-backup.sh
gpg --decrypt "/backups/wp-db-$(date +%F).sql.zst.gpg" | zstd -t

Restore into a staging database​

warning

Restoring overwrites data in the target database. Restore into a staging database first.

restore-encrypted-db-backup.sh
gpg --decrypt /backups/wp-db-2026-03-01.sql.zst.gpg \
  | zstd -dc \
  | mysql wordpress_restore

Key management notes​

  • Symmetric encryption is simple, but you must protect the passphrase.
  • Public-key encryption is better for teams and documented handoffs.

See:

  • opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/gpg-encryption.mdx

Next steps​

  • Offsite upload targets: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rclone-remote-targets.mdx.