Ransomware operators do not just encrypt your production workloads. They encrypt your backups first. If your backup storage is writable from the network, it is not a backup — it is a target.

This is the story of how I redesigned a backup architecture for a government client after their legacy Veeam setup failed a ransomware simulation exercise. The goal was simple: make backups survivable even if the entire production network is compromised.

The attack pattern we designed against

Modern ransomware operators follow a predictable path:

  1. Compromise a single endpoint via phishing or vulnerability
  2. Move laterally to domain admin
  3. Locate and destroy backups — either by encrypting backup storage or by deleting restore points
  4. Encrypt production systems
  5. Demand payment

Steps 1–3 usually happen weeks before step 4. The backup destruction phase is often the most surgical part — they look for Veeam, NetBackup, Commvault, and any file shares that look like archives.

Critical

If your backup admin credentials are stored on the domain, your backups are already compromised. The attacker will use your own backup tool to delete your own recovery points.

Design principles

We rebuilt around four principles:

  • Immutable storage — once written, no one can modify or delete the backup for a retention window (typically 14–30 days)
  • Air-gapped admin plane — a separate identity domain for backup operations that is not reachable from production
  • Isolated recovery environment — a sandbox network to restore and validate before rejoining production
  • Time-locked deletion — even the backup admin cannot delete within the retention window

Reference architecture

We deployed Veeam Backup & Replication on hardened Windows Servers, writing to:

  1. Primary tier — Dell PowerProtect DD series with retention lock enabled
  2. Secondary tier — replicated to an isolated DR site with immutable copies
  3. Tertiary tier — cloud object storage (Azure Blob with legal hold) for off-site recovery
Trade-off · Cost vs. resilience

Immutable storage roughly doubles the per-TB cost of standard tiered backup. For a government client handling citizen data, this is non-negotiable. For smaller businesses, an isolated Veeam server with rotated credentials and offsite copies is often the pragmatic middle ground.

Configuration essentials

The critical Veeam configuration is the hardened repository on Linux XFS with immutability enabled:

code
# Enable fast clone + immutability on the XFS volume
sudo xfs_io -c "chattr +i" /mnt/backup/immutable
sudo chmod 750 /mnt/backup/immutable

Then bind the repository to Veeam (Powershell):

code
# On the Veeam server
Add-VBRBackupRepository -Name "Immutable-XFS" -Folder "vbr:///mnt/backup/immutable" -Type LinuxLocal -MountServer "backup-mount-01"

Set the retention policy to immutable for 21 days — long enough to survive a two-week dwell time, short enough that storage does not grow unbounded.

Note
Immutability does not mean "keep forever." It means "cannot be deleted by anyone during the retention window." After 21 days, the block can be reclaimed by normal retention policies.

Validation

The only backup that matters is a backup you have restored. We set up:

  • Weekly restore test on a rotating sample
  • Monthly full-system DR drill into the isolated recovery environment
  • Quarterly ransomware simulation — the red team attempts to destroy backups

The ransomware simulation is the hardest part to get right. If it succeeds too easily, your architecture is broken. If it never succeeds, the test is not real.

What I would do differently

Looking back:

Start with identity isolation first. We initially left backup admin in the main domain and had to redo the entire credential plane.

Document the immutability window in the DR runbook. Recovery operators need to know they cannot just delete a bad backup — they must wait out the retention period or use an approved break-glass process.

Watch the API layer, not just storage. Immutability is useless if the backup software's REST API can be tricked into deleting through a non-standard endpoint.

Outcome

The final architecture passed the ransomware simulation. The red team gained domain admin and destroyed production, but the isolated recovery environment — including full restore capability — was untouched. Recovery was validated end-to-end in under six hours, well inside the client's defined RTO.

If you are designing backup for a regulated environment, this architecture is not optional. It is the baseline.