Backup used to be an operational chore. Ransomware turned it into a security control, because modern attacks delete or encrypt backups before touching production. Azure Backup has grown a full set of countermeasures for exactly that scenario, and configuring them is the difference between a bad week and a company ending event. Let us walk through the architecture and then the hardening.

Vaults and Policy Design

Two vault types exist: Recovery Services vaults (VMs, SQL in VM, SAP HANA, Azure Files) and Backup vaults (disks, blobs, PostgreSQL flexible server, AKS). Organize vaults per environment and region, in the management subscription, in a resource group workload teams cannot touch, because the whole point is that a compromised workload subscription cannot reach its own backups.

resource "azurerm_recovery_services_vault" "prod" {
  name                         = "rsv-backup-prod-weu"
  location                     = "westeurope"
  resource_group_name          = azurerm_resource_group.backup.name
  sku                          = "Standard"
  storage_mode_type            = "GeoRedundant"
  cross_region_restore_enabled = true
  soft_delete_enabled          = true

  immutability = "Locked"
}

resource "azurerm_backup_policy_vm" "tier1" {
  name                = "policy-vm-tier1"
  resource_group_name = azurerm_resource_group.backup.name
  recovery_vault_name = azurerm_recovery_services_vault.prod.name
  policy_type         = "V2"

  backup {
    frequency = "Hourly"
    time      = "00:00"
    hour_interval = 4
    hour_duration = 24
  }

  retention_daily {
    count = 30
  }

  retention_weekly {
    count    = 12
    weekdays = ["Sunday"]
  }

  retention_monthly {
    count  = 12
    weeks  = ["First"]
    weekdays = ["Sunday"]
  }
}

Tier your policies by data criticality, not by whoever asked loudest: tier one gets the enhanced V2 policy with multiple restore points per day and long retention, tier three gets daily with thirty days. Geo redundant storage with cross region restore means you can restore in the paired region even during a regional outage, which quietly makes your backup vault part of the DR design from yesterday’s post.

The Ransomware Stack

Four features, layered. Soft delete keeps deleted backup data recoverable for 14 days (extendable to 180, and you should extend it), so deletion by an attacker is reversible. Immutability, set to Locked, makes it impossible for anyone, including Owner on the subscription, to shorten retention or disable protection; locked means locked forever on that vault, which is precisely the point. Multi user authorization puts a Resource Guard, ideally in a separate tenant or a tightly held subscription, in front of destructive operations, so disabling protection needs approval from a second identity attackers are unlikely to hold. And security alerts plus the anomaly detection in Backup center flag unusual deletion or policy modification patterns for your SOC. An attacker now needs to compromise two privileged identities across two scopes, wait out soft delete, and still cannot break immutability. That is the bar.

Restore Testing: The Only Metric That Matters

A backup you have not restored is Schrodinger’s backup. Monthly, restore a sample: a full VM into an isolated network, a file level restore, a SQL database to a point in time, and time each one, because those durations are your real recovery SLA. Automate the drill with a runbook that restores, runs a validation script, records the result, and tears down. Alongside that, monitor job failures through Backup center across all vaults and treat a failed backup job with the same severity as a failed deployment: it means your protection has a hole today, not someday.

Cheers
Osama