Designing backup architecture that withstands ransomware encryption and deletion attempts
Migrating from traditional backup to ransomware-resilient backup with immutable storage
Establishing RPO/RTO targets for critical systems and validating them through restore testing
Isolating backup credentials and infrastructure from the production Active Directory domain
Meeting cyber insurance requirements for backup resilience and tested recovery capabilities
Do not use as a substitute for endpoint protection, network segmentation, or incident response planning. Backups are a last line of defense, not a primary prevention control.
Prerequisites
Inventory of critical systems, applications, and data classified by business impact (Tier 1/2/3)
Defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective) per tier
Isolated backup network segment or air-gapped storage infrastructure
Separate backup admin credentials not joined to the production AD domain
Workflow
Step 1: Classify Assets and Define Recovery Objectives
Map all systems into recovery tiers based on business impact:
Tier
Examples
RPO
RTO
Backup Frequency
Tier 1 (Critical)
Domain controllers, ERP, databases
1 hour
4 hours
Hourly incremental, daily full
Tier 2 (Important)
File servers, email, web apps
4 hours
12 hours
Every 4 hours incremental, daily full
Tier 3 (Standard)
Dev environments, archives
24 hours
48 hours
Daily incremental, weekly full
Document dependencies between systems. Domain controllers and DNS must recover before application servers. Database servers before application tiers.
Step 2: Implement 3-2-1-1-0 Architecture
Configure backup storage following the extended 3-2-1-1-0 rule:
Copy 1 - Primary backup on local storage:
# Veeam backup job targeting local repository
# Fast restore for operational recovery
Backup Repository: Local NAS (CIFS/NFS) or SAN
Retention: 14 days of restore points
Encryption: AES-256 with password not stored in AD
Copy 2 - Secondary backup on different media:
# Replicate to secondary site or cloud
# Veeam Backup Copy Job or Scale-Out Backup Repository
Target: AWS S3 / Azure Blob / Wasabi / tape library
Retention: 30 days
Transfer: Encrypted TLS 1.2+ in transit
Copy 3 - Offsite copy:
# Geographically separated from primary and secondary
# Cloud object storage in different region or physical tape rotation
Target: Cross-region cloud storage or Iron Mountain tape vaulting
Retention: 90 days
+1 - Immutable or air-gapped copy:
# Cannot be modified or deleted for defined retention period
# Veeam Hardened Repository on Linux with immutable flag
# Or AWS S3 Object Lock in Compliance mode
# Or physical air-gapped tape
+0 - Zero errors on restore verification:
# Automated restore testing using Veeam SureBackup or equivalent
# Scheduled weekly for Tier 1, monthly for Tier 2/3
# Verify boot, network connectivity, and application health
Step 3: Isolate Backup Credentials
Ransomware operators target backup infrastructure by compromising backup admin credentials through Active Directory:
Separate backup admin accounts from the production AD domain. Use local accounts on backup servers or a dedicated backup management domain.
Dedicated backup network segment with firewall rules allowing only backup traffic (specific ports, specific source/destination IPs).
MFA on backup console access using hardware tokens or authenticator apps, not SMS.
Disable RDP on backup servers. Use out-of-band management (iLO/iDRAC/IPMI) for emergency access.
Remove backup servers from domain or place in a dedicated OU with restricted GPO inheritance.
# Linux Hardened Repository - disable SSH password authsudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
# Set immutable flag on backup files (XFS filesystem)sudo chattr +i /mnt/backup/repository/*
# Veeam Hardened Repository uses single-use credentials# that are not stored on the Veeam server after initial setup
Step 4: Configure Immutable Storage
Veeam Hardened Linux Repository:
# Minimal Ubuntu 22.04 LTS installation# No GUI, no unnecessary services# Veeam uses temporary SSH credentials during backup window only# Configure XFS with reflink supportsudo mkfs.xfs -b size=4096 -m reflink=1 /dev/sdb1
sudo mount /dev/sdb1 /mnt/veeam-repo
# Create dedicated Veeam user with limited permissionssudo useradd -m -s /bin/bash veeamuser
sudomkdir -p /mnt/veeam-repo/backups
sudochown veeamuser:veeamuser /mnt/veeam-repo/backups
Context: A mid-size bank with 500 servers, 200TB of data, and regulatory requirements for 7-year retention must redesign backup after a peer institution was hit by ransomware. Current backups use a single Veeam repository on a Windows server joined to the production domain.
Approach:
Classify all 500 servers into three tiers: 50 Tier 1 (core banking, AD, DNS), 200 Tier 2 (email, file shares, web), 250 Tier 3 (dev, test, archive)
Deploy Veeam Hardened Linux Repository on dedicated Ubuntu 22.04 servers with XFS immutability for primary backup
Configure S3 Object Lock in Compliance mode for 30-day immutable cloud copy with Veeam Scale-Out Repository capacity tier
Establish quarterly tape rotation to Iron Mountain for 7-year regulatory retention
Remove all backup servers from the production AD domain and create isolated backup admin accounts with hardware MFA tokens
Deploy SureBackup jobs: weekly for Tier 1, monthly for Tier 2, quarterly for Tier 3
Conduct annual full recovery drill restoring AD, DNS, core banking, and dependent applications to validate documented RTO
Pitfalls:
Leaving backup admin credentials in the production AD domain where ransomware operators can compromise them via Kerberoasting or DCSync
Configuring immutable retention periods shorter than the dwell time of typical ransomware (average 21 days), allowing attackers to wait for immutability to expire
Testing only individual VM restores without testing full application stack recovery including dependencies
Forgetting to back up backup server configuration (Veeam config database, encryption keys) separately from the backup infrastructure itself
