← Back to Articles

Backup and Disaster Recovery Security: Protecting Your Last Line of Defense

June 19, 2025•Data Protection•3 min read

In 2023, the Veeam Ransomware Trends Report revealed that 93% of ransomware attacks specifically target backup repositories. Think about that for a moment: the very systems you built to recover from disaster are now the first thing adversaries destroy. If your backup infrastructure isn't hardened with the same rigor as your production environment, you don't actually have a recovery plan—you have a false sense of security.

Why Backup Security Is Now a Top-Tier Priority

Traditional backup strategies assumed the threat model was hardware failure, natural disaster, or accidental deletion. Today's threat model includes an intelligent adversary who has been living in your network for weeks, has mapped your backup topology, and plans to encrypt or delete every copy before detonating ransomware on production systems.

This fundamentally changes how we must architect disaster recovery. Backups are no longer just an operations concern—they are a critical security control.

The 3-2-1-1-0 Rule

The classic 3-2-1 rule (three copies, two media types, one offsite) needs an upgrade. The modern standard is 3-2-1-1-0:

  • 3 copies of your data
  • 2 different storage media
  • 1 offsite copy
  • 1 immutable or air-gapped copy
  • 0 errors after automated recovery verification

That immutable copy is the game-changer. Without it, a privileged attacker can wipe everything.

Implementing Immutable Backups

On Linux-based backup repositories, you can leverage immutable flags to prevent modification even by root:

# Set an immutable attribute on backup files (ext4/xfs)
chattr +i /backup/vault/full-backup-2024-12-01.tar.gz

# Verify immutability
lsattr /backup/vault/full-backup-2024-12-01.tar.gz
# Output: ----i--------e-- /backup/vault/full-backup-2024-12-01.tar.gz

For S3-compatible object storage (AWS, MinIO, Wasabi), enable Object Lock with a retention policy:

{
  "Rule": {
    "DefaultRetention": {
      "Mode": "COMPLIANCE",
      "Days": 30
    }
  }
}

COMPLIANCE mode is critical here—unlike GOVERNANCE mode, even the root account cannot delete objects before the retention period expires.

Encrypting Backups at Rest and in Transit

Unencrypted backups are a data breach waiting to happen. Use AES-256 encryption at rest and TLS 1.3 in transit:

# Encrypt a backup archive with GPG before storage
gpg --symmetric --cipher-algo AES256 \
    --output /backup/vault/backup-2024-12-01.enc \
    /backup/staging/backup-2024-12-01.tar.gz

# Securely transfer to offsite repository
rsync -avz -e "ssh -o Ciphers=aes256-gcm@openssh.com" \
    /backup/vault/ offsite-repo:/secure-vault/

Store encryption keys in a dedicated secrets manager (HashiCorp Vault, AWS KMS)—never on the same system as the backups themselves.

Isolating Backup Credentials

One of the most common failures I see in enterprise environments is backup service accounts sharing credentials with Active Directory domain admins. If an attacker compromises your domain, they inherit your backup infrastructure.

Mitigations:

  • Use dedicated, non-domain-joined service accounts for backup systems
  • Store backup admin credentials in a separate PAM vault with break-glass procedures
  • Enforce MFA on all backup console access
  • Segment backup networks into isolated VLANs with strict firewall rules

Automated Recovery Testing

A backup you haven't tested is a backup that doesn't exist. Automate weekly restore validation:

#!/bin/bash
# automated-restore-test.sh
BACKUP_FILE="/backup/vault/latest-full.enc"
RESTORE_DIR="/tmp/restore-test-$(date +%s)"

gpg --decrypt "$BACKUP_FILE" | tar xzf - -C "$RESTORE_DIR"
CHECKSUM=$(sha256sum "$RESTORE_DIR/critical-db.sql" | awk '{print $1}')

if [ "$CHECKSUM" = "$EXPECTED_CHECKSUM" ]; then
    echo "PASS: Restore verification successful" | logger -t backup-audit
else
    echo "FAIL: Restore integrity mismatch" | logger -t backup-audit -p user.crit
fi
rm -rf "$RESTORE_DIR"

Pipe results into your SIEM so failed restore tests trigger incident response workflows.

Final Thoughts

Backup and disaster recovery security isn't a checkbox—it's an ongoing adversarial exercise. Assume your production environment will be fully compromised and work backward: can you still recover? If the answer requires any hesitation, it's time to re-architect. Your backups aren't your safety net until they're the one thing an attacker cannot touch.

Have questions about backup and disaster recovery security? I'm always happy to talk shop — reach out or connect with me on LinkedIn.

← Back to Articles