top of page
Search

Maybe I Owe Azure Backup an Apology...

  • Writer: Shannon
    Shannon
  • 4 minutes ago
  • 8 min read

The most convincing form of technical arrogance is the kind that masquerades as experience. You spend enough years in tech, you accumulate enough scar tissue, and eventually your opinions calcify into something faster than reasoning: reflex. Someone mentions a product, and you already know what you think before they finish the sentence. No deliberate evaluation required...that's just pattern recognition, right?


Maybe. But pattern recognition trained on a snapshot of 2021 is not pattern recognition. It's just confident incorrectness. ;)


I was reminded of that recently during a conversation about backup strategy in Azure. A customer was evaluating Dell PowerProtect Data Domain in Azure versus Azure Backup. Without much deliberation, I gave my standard answer: Azure Backup is solid for cloud-native workloads, but when you start talking enterprise cyber recovery, immutability, ransomware resilience, and real administrative separation of duties, you're probably reaching for Rubrik, Cohesity, Commvault, Veeam, or something in that ecosystem.


Then several people started pushing back. And I kept having the same reaction.

"Wait. Azure Backup does that now?"


It does. And it has for a while. I just hadn't noticed. Whoops.


The Thing Nobody Tells You About Being an Expert

Your mental model of a product freezes at whatever maturity level it had when you stopped paying close attention. Know the product may very well keep shipping, but your model unfortunately doesn't update. And you walk around with an authoritative opinion that stopped being accurate somewhere around the time you moved on to the next problem.


I've watched this happen to other people on other products and I used to cringe when I was younger. I apparently did it to myself with Azure Backup, so I cringed for myself in this instance.


Let me do something uncomfortable: audit what I thought I knew against what's actually shipping today. Makes for a good blog post and reminds people NOT TO STOP LEARNING AND ABSORBING NEW TECHNOLOGY!


Immutable Vaults: Not Just a Setting, a Security Posture

For years, one of the things that drove enterprise customers toward dedicated backup platforms was the immutability story. Azure Backup existed and it worked. But "can an admin with the right permissions just delete the recovery points?" became a question with a less satisfying answer than many organizations needed.


Today, Recovery Services Vaults and Backup Vaults support immutability settings that prevent operations that would result in loss of recovery points. What actually matters here is the lock:


  • Disabled: immutability is off

  • Enabled: immutability is on, but can be reversed

  • Locked: immutability is on and cannot be reversed

That locked state matters. A lot. It shifts the threat model for credential compromise scenarios. If an attacker or a malicious insider pops a Global Admin or Backup Admin account, they can't just kick off a delete-all-recovery-points operation to make the ransomware cleanup permanent. The vault says no and actually means it.

Microsoft also supports WORM (Write Once, Read Many) storage semantics for supported regions, which is a meaningful statement to compliance teams and cyber insurance underwriters who want to see that in writing.

Checking immutability state across your environment isn't something most teams have done systematically. Start here:

# Enumerate Recovery Services Vaults and their immutability state
# across all subscriptions in the tenant

Get-AzSubscription | ForEach-Object {
    $sub = $_
    Set-AzContext -SubscriptionId $sub.Id | Out-Null

    Get-AzRecoveryServicesVault | ForEach-Object {
        $vault = $_
        $props = $vault.Properties

        [PSCustomObject]@{
            Subscription          = $sub.Name
            SubscriptionId        = $sub.Id
            VaultName             = $vault.Name
            ResourceGroup         = $vault.ResourceGroupName
            Location              = $vault.Location
            ImmutabilityState     = $props.ImmutabilitySettings.ImmutabilityState ?? "NotConfigured"
            SoftDeleteState       = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteState ?? "Unknown"
            SoftDeleteRetention   = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteRetentionPeriodInDays
        }
    }
} | Sort-Object Subscription, VaultName | Format-Table -AutoSize

Or if you're working at scale and want something faster and cross-subscription without context-hopping:

// Azure Resource Graph: vault immutability and soft delete state

resources
| where type =~ "microsoft.recoveryservices/vaults"
| extend
    ImmutabilityState = tostring(properties.immutabilitySettings.immutabilityState),
    SoftDeleteState   = tostring(properties.securitySettings.softDeleteSettings.softDeleteState),
    SoftDeleteDays    = tostring(properties.securitySettings.softDeleteSettings.softDeleteRetentionPeriodInDays)
| project
    VaultName         = name,
    ResourceGroup     = resourceGroup,
    SubscriptionId    = subscriptionId,
    Location          = location,
    ImmutabilityState,
    SoftDeleteState,
    SoftDeleteDays
| order by VaultName asc

Run that across your tenant and see how many vaults come back as NotConfigured. My guess is: more than you expect.


Multi-User Authorization: This Is the One That Got My Attention

If you've sat through enough conversations about cyber recovery strategy, you've heard some version of this concern: "What if a legitimate admin account is compromised? What prevents them from destroying the backups?"


The traditional answer involved a combination of limited backup admin scope, tight break-glass access controls, and ideally a dedicated backup platform with its own separate administrative domain. Azure Backup historically relied heavily on the first two. The third was where dedicated backup vendors had an edge.


Resource Guard changes this.

Multi-User Authorization (MUA) using Resource Guard introduces a separate administrative boundary around sensitive backup operations. The basic architecture is this:

  • A Resource Guard lives in a different subscription, ideally managed by a different team (a security team, a cloud platform team, whoever isn't the same hands doing day-to-day backup operations)

  • The Backup Vault or Recovery Services Vault is associated with that Resource Guard

  • Critical operations, including disabling immutability, deleting backups, and modifying backup policies, require the operator to have permissions on both the vault and the Resource Guard


This is real separation of duties, not just documented best practice that nobody enforces. A compromised backup admin account operating alone cannot bypass it. They need access to a resource in a different subscription, controlled by a different team, to complete the destructive operation.


You can check which of your vaults have MUA configured with Resource Graph:

// Vaults with Resource Guard (MUA) association

resources
| where type =~ "microsoft.recoveryservices/vaults"
| extend
    ResourceGuardId = tostring(properties.resourceGuardOperationRequests)
| project
    VaultName       = name,
    ResourceGroup   = resourceGroup,
    SubscriptionId  = subscriptionId,
    Location        = location,
    MUAConfigured   = iff(isnotempty(ResourceGuardId) and ResourceGuardId != "[]", "Yes", "No")
| order by MUAConfigured asc, VaultName asc

Most environments will light up with No almost everywhere. That's actionable.


Recovery Point Frequency: Still Not Log Shipping, But Better

One of the valid critiques of Azure Backup for some workload classes has been inflexible recovery point schedules. For VMs with tight RPO requirements, the conversation sometimes moved toward application-level replication rather than backup because the backup frequency wasn't granular enough.


Enhanced backup policies now support Azure VM backup every four hours. That's still not continuous replication and shouldn't be framed as a substitute for it. But it meaningfully changes the conversation for workloads that don't require sub-hour RPO and were previously being forced into more complex architectures just to get better than daily snapshots.


Soft Delete: Make Sure It's Actually Configured

Soft delete is one of those capabilities that sounds like a checkbox but has real operational and security implications. When enabled, deleted backup data is retained for an additional retention period (configurable up to 180 days), which gives you a recovery window even if a backup job or retention policy is maliciously or accidentally modified.


What I find in practice is that soft delete is often partially deployed: enabled on some vaults, off or at minimum retention on others, with no consistent standard applied across the estate.

# Find vaults where soft delete is disabled or retention is under 30 days
Get-AzSubscription | ForEach-Object {
    Set-AzContext -SubscriptionId $_.Id | Out-Null

    Get-AzRecoveryServicesVault | ForEach-Object {
        $vault = $_
        $props = $vault.Properties
        $sdState = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteState
        $sdDays  = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteRetentionPeriodInDays

        if ($sdState -ne "AlwaysOn" -or $sdDays -lt 30) {
            [PSCustomObject]@{
                Subscription     = (Get-AzContext).Subscription.Name
                VaultName        = $vault.Name
                ResourceGroup    = $vault.ResourceGroupName
                SoftDeleteState  = $sdState ?? "Unknown"
                RetentionDays    = $sdDays ?? "Unknown"
                Action           = if ($sdState -ne "AlwaysOn") { "Enable soft delete" }
                                   
		elseif ($sdDays -lt 30)       
			{ "Increase retention" }
                                   
		else                          
			{ "Review" }
            }
        }
    }
}

AlwaysOn is the state you want. It prevents administrators from disabling soft delete on the vault, which closes the "just turn it off first" attack path.


So Where Does This Leave the Enterprise Backup Conversation?

I'm not here to write a feature comparison chart or declare Azure Backup the winner of anything.


Rubrik, Cohesity, Commvault, Veeam, and Dell still have a real place in the market. Backup strategy should start with your recovery objectives, your compliance obligations, your security requirements, your operational maturity, and your business outcomes. Product loyalty doesn't belong anywhere in that conversation.


What I am saying is this: if your opinion of Azure Backup was formed more than a few years ago and you haven't revisited it, you're probably evaluating a product that doesn't exist anymore.


The questions worth asking today look different than they did then:


  • Do you have immutability locked on every vault storing production backup data?

  • Do you have Resource Guard deployed in a separate subscription with a separate administrative team?

  • Do you have soft delete configured consistently, with a retention period that reflects your actual recovery window requirements?

  • Do you have enhanced backup policies applied to VMs with non-trivial RPO requirements?

  • Do you have RBAC scoped to least privilege across your vault operations, or are you still using Backup Contributor broadly?


Most environments I see have answered "yes" to approximately none of these. Which means the gap isn't usually Azure Backup's capabilities. It's the configuration that never got applied after the initial deployment.


That's actually a more tractable problem than needing a different product.


A Starting Inventory

Before you can fix the posture, you need to see it. This pulls a cross-subscription vault inventory with the security signals that matter:

$results = Get-AzSubscription | ForEach-Object {
    $sub = $_
    Set-AzContext -SubscriptionId $sub.Id | Out-Null

    Get-AzRecoveryServicesVault | ForEach-Object {
        $vault = $_
        $props = $vault.Properties
        $immutState  = $props.ImmutabilitySettings.ImmutabilityState ?? "NotConfigured"
        $sdState     = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteState ?? "Unknown"
        $sdDays      = $props.SecuritySettings.SoftDeleteSettings.SoftDeleteRetentionPeriodInDays

        $secureScore = switch ($true) {
            ($immutState -eq "Locked" -and $sdState -eq "AlwaysOn" -and $sdDays -ge 30) { "Strong" }
            ($immutState -in @("Enabled","Locked") -and $sdState -ne "Disabled")         { "Moderate" }
            default                                                                        { "Weak" }
        }

        [PSCustomObject]@{
            Subscription      = $sub.Name
            VaultName         = $vault.Name
            ResourceGroup     = $vault.ResourceGroupName
            Location          = $vault.Location
            ImmutabilityState = $immutState
            SoftDeleteState   = $sdState
            SoftDeleteDays    = $sdDays
            PostureSignal     = $secureScore
        }
    }
}

$results | Sort-Object PostureSignal, Subscription, VaultName | Format-Table -AutoSize

# Summary by posture tier
Write-Host "`n=== Posture Summary ===" -ForegroundColor Cyan
$results | Group-Object PostureSignal | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count) vault(s)" -ForegroundColor $(
        switch ($_.Name) {
            "Strong"   { "Green"  }
            "Moderate" { "Yellow" }
            "Weak"     { "Red"    }
        }
    )
}

That gives you a quick posture tier across every vault in the environment: Strong, Moderate, or Weak, based on whether immutability is locked and soft delete is actually configured. It's not a full security assessment. It's a map of where to look next.


The Broader Problem Is Assumption Rot

The real lesson here isn't about Azure Backup specifically. It's about what happens when smart, experienced people stop questioning their own mental models.


Cloud services don't stop shipping features because you got busy. Azure Backup didn't ask my permission before adding Immutable Vaults or Resource Guard. It just kept getting built while I was focused on other things: AI, FinOps, platform engineering, you know...everything else fighting for attention in the current moment.

The dangerous thing isn't ignorance. You can fix ignorance once you notice it. The dangerous thing is confident ignorance that presents itself as expertise. It's giving authoritative answers about a version of a product that hasn't existed for several years. It's carrying a mental model that was accurate once and hasn't been stress-tested since.

I don't know how many customer conversations I've had over the past few years where I steered the backup discussion in a direction that reflected Azure Backup circa 2021 rather than what it actually is today. Probably more than I'd like to count.


So yes. Maybe I owe Azure Backup an apology.


More practically: I owe it a fresh evaluation. Sorry about that, Azure Backup!


Additional Reading


Runnable Azure Backup posture-assessment code covering cross-subscription vault discovery, immutability and soft-delete validation, Resource Guard and multi-user authorization checks, enhanced policy inventory, and overall security posture scoring can be found here: https://github.com/sbkuehn/azure-backup-posture-kit

© 2020 Shannon B. Eldridge-Kuehn

  • LinkedIn
  • Twitter
bottom of page