Why Backup Security Matters

Backups are often the weakest link in data security. While production databases have firewalls, access controls, and monitoring, backups may sit on file shares, cloud storage, or backup servers with weaker protections.

Common Backup Security Failures

• Unencrypted backups stored on public cloud storage
• Backup credentials shared in scripts or documentation
• No access logging for backup files
• Backups accessible to more people than production database
• Old backups never deleted, containing outdated but sensitive data
• Backup tapes or drives lost or stolen

Regulatory Requirements

Many regulations explicitly require backup encryption and security controls:

• GDPR - Personal data must be protected in backups
• HIPAA - Healthcare data requires encryption at rest
• PCI-DSS - Cardholder data must be encrypted in backups
• SOC 2 - Backup security controls are audit requirements
• CCPA - California consumer data protection applies to backups

Encryption at Rest

Encryption at rest protects backup files from unauthorized access when stored. Even if someone gains access to your backup storage, encrypted backups are unreadable without the encryption key.

Encryption Methods

There are several approaches to encrypting MySQL backups:

1. Stream Encryption During Backup

Encrypt data as it's being written, before it ever touches disk unencrypted:

# Mariabackup with openssl encryption
mariabackup --backup --stream=xbstream | \
  openssl enc -aes-256-cbc -k 'encryption_password' | \
  gzip > backup.xb.enc.gz

# mysqldump with encryption
mysqldump -u root -p mydb | \
  openssl enc -aes-256-cbc -k 'encryption_password' | \
  gzip > backup.sql.enc.gz

2. Post-Backup Encryption

Encrypt backup files after they're created. Simpler but leaves unencrypted data temporarily on disk:

# Create backup then encrypt
mariabackup --backup --target-dir=/backup/temp
tar -cf - /backup/temp | \
  openssl enc -aes-256-cbc -k 'encryption_password' > backup.tar.enc
rm -rf /backup/temp  # Remove unencrypted version

3. Filesystem/Volume Encryption

Encrypt the entire storage volume where backups are stored. Transparent to backup tools but requires key present when mounting:

• LUKS for Linux volumes
• BitLocker for Windows
• Cloud provider encryption (AWS EBS, GCP Persistent Disk)
• Hardware-encrypted drives

Encryption Algorithms and Key Sizes

Choose appropriate encryption algorithms and key sizes for your security requirements.

Recommended Algorithms

Avoid These

• DES - Obsolete, easily broken
• 3DES - Deprecated, slow
• AES-128 - Acceptable but AES-256 preferred for sensitive data
• ECB mode - Reveals patterns in data
• Password-only encryption without proper key derivation

Key Derivation

When using passwords for encryption, use proper key derivation functions (PBKDF2, Argon2, scrypt) rather than using the password directly. OpenSSL's -pbkdf2 flag does this automatically:

# With proper key derivation
openssl enc -aes-256-cbc -pbkdf2 -iter 100000 -k 'password' ...

# Or use a pre-generated key file (more secure)
openssl enc -aes-256-cbc -kfile /secure/backup.key ...

Key Management

Encryption is only as strong as your key management. A backup encrypted with a key stored next to it provides little security.

Key Management Principles

• Never store encryption keys with the backups they protect
• Limit access to encryption keys to essential personnel only
• Use different keys for different backup sets when practical
• Have secure key backup and recovery procedures
• Rotate keys periodically and after personnel changes

Key Storage Options

Key Rotation

Plan for key rotation - both routine and emergency. When you rotate keys:

• New backups use new key immediately
• Maintain old key to decrypt historical backups
• Document which key applies to which backup period
• Have procedure for emergency key rotation (suspected compromise)

Encryption in Transit

Backups are often transferred between servers, to cloud storage, or to offsite locations. Protect data during transfer.

Secure Transfer Methods

# SCP/SFTP (SSH-based, encrypted)
scp backup.enc.gz backup-server:/backups/

# rsync over SSH
rsync -avz -e ssh backup.enc.gz backup-server:/backups/

# AWS S3 with TLS
aws s3 cp backup.enc.gz s3://my-backup-bucket/ --sse AES256

# Google Cloud Storage with TLS
gsutil cp backup.enc.gz gs://my-backup-bucket/

Avoid These for Backup Transfer

• FTP - Credentials and data sent in plaintext
• HTTP - No encryption
• Unencrypted NFS/SMB - Network traffic visible
• Email attachments - Often stored unencrypted, size limits

Double Encryption Strategy

For maximum security, encrypt the backup content AND the transfer channel. Even if TLS is compromised, the backup itself remains encrypted.

Access Control

Limit who can access backups and track all access. Principle of least privilege applies to backups just like production systems.

Database Backup User

Create a dedicated MySQL user for backups with minimal required privileges:

-- For physical backups (Mariabackup/XtraBackup)
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'secure_password';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup'@'localhost';

-- For logical backups (mysqldump) - read only
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'secure_password';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO 'backup'@'localhost';

Storage Access Control

• Backup files should be owned by dedicated backup user
• Restrict read access to backup operators only
• Disable delete permissions for most users (prevent accidental deletion)
• Use IAM roles/policies for cloud storage access
• Enable access logging on backup storage

Auditing

Log all backup operations for security auditing:

• Who created each backup
• Who accessed or downloaded backups
• Who deleted backups
• Restore operations (who, when, what data)
• Failed access attempts

Secure Backup Credentials

Backup scripts often need database credentials. Storing these securely is critical.

Don't Do This

# BAD: Password in script
mysqldump -u root -p'MyPassword123' mydb > backup.sql

# BAD: Password in environment variable visible to all processes
export MYSQL_PWD='MyPassword123'

Better Approaches

1. MySQL Option File

# Create ~/.my.cnf with restricted permissions
cat > ~/.my.cnf << EOF
[client]
user=backup
password=secure_password
EOF
chmod 600 ~/.my.cnf

# Now run without password in command line
mysqldump mydb > backup.sql

2. MySQL Config Editor (Encrypted)

# Store credentials encrypted
mysql_config_editor set --login-path=backup \
  --host=localhost --user=backup --password

# Use in backup scripts
mysqldump --login-path=backup mydb > backup.sql

3. Secrets Manager Integration

# Retrieve password from secrets manager at runtime
DB_PASS=$(aws secretsmanager get-secret-value \
  --secret-id mysql-backup-creds \
  --query SecretString --output text | jq -r .password)

mysqldump -u backup -p"$DB_PASS" mydb > backup.sql
unset DB_PASS

Ransomware Protection

Ransomware increasingly targets backups to prevent recovery. Network-accessible backups can be encrypted by attackers along with production data.

Air-Gapped Backups

Keep at least one backup copy completely disconnected from your network:

• Offline tape storage
• External drives stored offsite
• Cloud storage with no network path from production
• Write-once media (WORM)

Immutable Backups

Many cloud providers offer immutable storage - once written, backups cannot be modified or deleted for a retention period:

• AWS S3 Object Lock
• Azure Immutable Blob Storage
• GCP Retention Policies
• Wasabi Object Lock

# AWS S3 Object Lock example
aws s3api put-object \
  --bucket my-backup-bucket \
  --key backup-2025-01-15.enc.gz \
  --body backup.enc.gz \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date 2025-04-15T00:00:00Z

Separate Credentials

Use different credentials for backup storage than for production systems. If production is compromised, attackers shouldn't automatically have backup access.

How DBCalm Handles Security

DBCalm implements security best practices automatically, eliminating common configuration mistakes.

Built-in Encryption

• AES-256 encryption for all backups at rest
• Encryption happens before data leaves your server
• TLS encryption for all data in transit
• Encryption keys managed separately from backup data

Access Controls

• Dedicated backup user with minimal database privileges
• Role-based access to backup management
• Audit logging of all backup operations
• Secure credential storage (never in scripts)

Compliance Support

DBCalm's security features support compliance with GDPR, HIPAA, PCI-DSS, and SOC 2 requirements for backup security. Audit logs and encryption provide the documentation compliance teams need.

Frequently Asked Questions

Related Guides

• MySQL Backup Best Practices
• Physical vs Logical Backups
• Incremental Backup Explained