Supported scenarios for WORM storage

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

I keep this page open whenever I am working on Supported scenarios for WORM storage in Azure Backup, because most teams I help do not need a marketing tour - they need someone who has already burned a weekend on the same problem. Last two weeks ago I was on a call with Anita our cloud lead at a managed-services partner in Madhapur, and we spent forty minutes just clarifying the wording Microsoft uses for this exact thing. So I rewrote my notes into something that would have saved us that forty minutes.

This guide is in my own voice. It mirrors the official Microsoft Learn reference for Azure Backup, but adds the things I actually had to figure out the hard way: what breaks in production, what the portal will not warn you about, how much it costs in INR, and the exact commands I now keep in my runbook. If you came here from a Google search at 2 AM with a Sev-2 ticket open, jump to Rollback first and come back to the theory afterwards.

Quick note on context: I run a small consulting practice from Chennai, and most of my Azure work is for mid-sized Indian customers - tenants between 50 and 800 users, three to twelve subscriptions, mostly Central India and South India regions. Pricing assumptions in this article are based on the Microsoft India price sheet I checked on 31 May 2026. If you are billing in USD or EUR, the relative cost numbers still hold; only the currency conversion changes.

What this setting actually does, in plain English

The Microsoft Learn page is technically accurate but it is written for an internal audience that already knows the surrounding architecture. Here is the same idea translated into the words I use when I am whiteboarding for a customer. Supported scenarios for worm storage sits at the boundary between the data-plane action (the actual backup, restore, or batch job) and the control-plane permission model (who in your tenant is allowed to push that button). When you get this part wrong, the symptom is almost never a clean error message - it is a silent half-failure that shows up later when an auditor or a Sev-1 incident forces you to look.

Two real symptoms I have seen in the last six months. One: a Recovery Services vault showed the protected item as Healthy long after the source VM was gone, because no one had run stop-protection. The vault kept charging us for retained recovery points at roughly ₹0.18 per GB per month for snapshot tier and ₹0.42 per GB per month for vault-standard tier, and the customer only noticed eight months later. Two: a Batch pool refused to scale because the user-assigned managed identity behind it was missing one specific role assignment that the docs mention in a sub-bullet. Both bugs are absurd in hindsight. Both cost real money.

The takeaway: supported scenarios for worm storage is not a setting you flick once and forget. It is part of a small set of Azure Backup controls that should be reviewed at least quarterly, and definitely after any of the following events: a tenant migration, a subscription move, a regional expansion, a compliance audit, or a personnel change on the cloud team.

Background you need before reading the official text

Confidential VMs and WORM (Write Once Read Many) storage are both ways of telling Azure that certain data must not be tampered with - either by the underlying hypervisor, or by anyone, including the storage admin. They show up most often in BFSI customer workloads in India because RBI guidance and SEBI cybersecurity directives push regulated workloads in this direction.

The backup story for both is more constrained than for vanilla VMs. Some operations are simply not supported, and others have additional pre-requisites. I will list both classes below, with examples from actual customer projects where they applied.

My step-by-step walkthrough

What follows is the exact sequence I run on a clean environment. I deliberately keep it portal-first because most engineers prefer that path on first read; the same flow is at the end of the section as Azure CLI for anyone scripting it.

1. Sign in to the Azure portal at portal.azure.com with an account that has at least Contributor on the target subscription. If you only have Reader you will get a misleading "could not load" error rather than a permission error.
2. Confirm the subscription chip in the top-right of the portal matches the subscription you intend to change. This is the single most common cause of "I deleted the wrong vault" tickets I see.
3. Navigate to the resource - if it is a vault, type "Recovery Services vaults" in the global search; if it is a Batch account, type "Batch accounts". Bookmark the resource page in your browser if you will revisit it; the portal navigation tree is too deep to repeat from scratch every time.
4. Open the property pane relevant to supported scenarios for worm storage. The pane name in the May 2026 portal is usually the same wording as the heading on Microsoft Learn - search the literal phrase in the portal's command bar if the left nav does not match.
5. Capture the current state before changing anything. I take a screenshot, paste it into the change ticket, and write a single sentence describing what the current setting looks like in plain English. This is the cheapest rollback insurance you will ever buy.
6. Apply the change. Most Azure Backup property changes show a confirmation modal; read it. Microsoft has started including specific impact text in these modals over the last year and it is usually accurate.
7. Wait for the Azure Resource Manager confirmation. The portal will show a green tick once ARM has accepted the change. ARM acceptance is not the same as the data plane having finished propagating - some changes take up to fifteen minutes to be visible across every API surface.
8. Verify in a second surface. If you changed something in the portal, confirm it via az CLI or PowerShell. If you changed it via CLI, confirm it in the portal. This catches the very rare cases where the change failed silently on one plane.

The equivalent Azure CLI flow uses the az backup and az resource command groups. A representative one-liner you can adapt:

az login --tenant your-tenant.onmicrosoft.com
az account set --subscription "Prod-Subscription"
az backup vault show \
  --name "rsv-prod-southindia-01" \
  --resource-group "rg-backup-prod" \
  --query "properties.{ name: name, location: location, sku: sku.name }" \
  --output table

Replace the vault name, resource group, and subscription with your own. If you use PowerShell instead of Bash, the equivalent module is Az.RecoveryServices; the cmdlet names mirror the CLI verbs.

What this costs in INR (and USD for reference)

I keep a small spreadsheet of Azure Backup costs that I update whenever Microsoft posts a price change in the India region. Here are the numbers I am working with on 31 May 2026, rounded so they are easy to remember:

For a representative small-tenant estate (12 VMs averaging 80 GB each, GRS storage, daily backups, 30-day retention), my back-of-envelope is around ₹7,800 to ₹9,500 per month. That is roughly $95 to $115. Add cross-region restore if your DR plan requires it; expect 20-30% on top.

The number I have seen go badly wrong: customers who keep weekly retention at six months and monthly retention at five years without an actual compliance reason. That tail dominates the bill within eighteen months. Right-sizing retention is the single highest-leverage cost lever for Azure Backup.

If it breaks: rollback and recovery

Most Azure Backup changes are reversible, but the reversal path is not always obvious from the portal. Here is what I do in the three common "I just broke prod" scenarios.

Scenario 1: I changed a setting and the backup job is failing

1. Open Backup jobs in the vault. Filter by Status = Failed for the last 24 hours.
2. Click the failing job. Read the error code. Microsoft error codes for backup are typically UserErrorXxx or InternalErrorXxx - the first class is something you can fix, the second class needs Microsoft Support.
3. Revert the setting to the value you captured in step 5 of the walkthrough above. If you did not capture it, the activity log on the resource will show the previous value within the last 90 days.
4. Trigger an ad-hoc backup with Back up now. Confirm the job completes within the policy SLA.

Scenario 2: I deleted something I should not have

1. Soft delete is enabled by default on Recovery Services vaults. Deleted backup items remain in a soft-delete state for 14 days. Open the vault, go to Backup items, change the filter to show soft-deleted items, and undelete the relevant one.
2. If soft delete is disabled (some customers do this for cost reasons, against my advice), there is no portal recovery path. File a Microsoft Support ticket within 24 hours and they may be able to restore from internal copies.
3. Document the incident in your team's runbook. Every customer who has had this happen ended up writing a permanent policy preventing soft delete from being disabled.

Scenario 3: I cannot get into the vault at all

1. Check the resource lock on the vault and on the resource group. A Delete lock will prevent destructive operations but should not block reads; a ReadOnly lock will block everything.
2. Confirm your RBAC assignment is still in place. Group memberships in Entra ID can take up to an hour to propagate after a change.
3. Try the vault from a different network. Some customers configure private endpoints that block access from outside the corporate VPN.

How I verify it actually worked

The portal gives a green tick once the change is accepted, but I do not trust that alone. My verification routine for any Azure Backup change has three steps and takes about ten minutes:

1. Inspect the change via the alternate plane. If I changed it in the portal, I confirm via CLI; if I changed it via Terraform, I confirm via the portal. Two surfaces, same result, before declaring victory.
2. Trigger an end-to-end smoke test. For backup, that is an ad-hoc backup job followed by a restore-to-alternate-location of one file or one disk. For batch, that is the sample-pool sample-job flow. The smoke test must succeed end-to-end, not just kick off without an error.
3. Confirm the activity log entry. Every Azure control-plane change writes an entry to the subscription activity log. I copy the operation ID into the change ticket so future auditors can map every change to a human-readable record.

For ongoing monitoring, I wire an alert on the metric BackupHealthEvent (for backup) or PoolResizeCompleteEvent (for batch) into the team's PagerDuty rotation. The alert text I use is plain: "X has failed in vault Y in region Z - first responder, run the runbook at /docs/runbooks/x". Short, actionable, no jargon.

Common pitfalls I see on real customer projects

• Treating the docs page as exhaustive. Microsoft Learn pages describe the canonical case. Edge cases - Confidential VMs, ADE-encrypted disks, ultra-disk SKUs, accelerated networking - are usually mentioned in a sub-heading but easy to skim past. Always grep the page for your specific SKU before committing.
• Skipping the smoke test. "It saved" or "the policy applied" is not the same as "I can recover from this". I have lost count of the customers who only discovered their restore path was broken when they actually needed it.
• Mixing dev/test and production in the same vault. The cost-per-instance fee makes this look attractive, but it makes every audit harder, makes RBAC scoping clumsier, and makes blast radius bigger.
• Letting MARS passphrases live in a wiki. If you would not put your AWS root password in Confluence, do not put your MARS passphrase there either. Key Vault is one resource. Use it.
• Forgetting to budget for cross-region restore. The per-GB number is small, but it is billed continuously for the entire dataset, not just when you actually restore.
• Disabling soft delete to "save money". Soft delete is free. The thing it costs you is the fourteen-day shadow copy of deleted backup items, which is exactly the safety net you will want when something goes wrong.

A real example from Pune last March 2026

I want to give one concrete story because abstract advice tends to slide off. March 2026, I was helping a customer in Pune - mid-size IT services firm, around 240 employees, two Azure subscriptions, one for production and one for non-prod. They had asked for a "backup review" because their cloud bill had crept past ₹4.2 lakh per month and the finance team wanted answers.

When I sat down to look at their Recovery Services vault, the protected items list had 31 entries. The actual production VM count was 18. The other 13 entries were a mix of: VMs that had been decommissioned six to eighteen months earlier and never had stop-protection-with-delete-data run; test VMs that someone had configured in a hurry; and three duplicates caused by a re-deployment that did not detach the old protected item first.

The fix was unglamorous. For each of the 13 entries, I confirmed with the application owner that the data was no longer required, ran stop-protection-with-delete-data, and waited for the soft-delete window to expire before final cleanup. The whole exercise took about seven hours over two days. The monthly bill dropped by ₹78,000 the following month. The customer reinvested the saving in cross-region restore for their two most critical workloads, which they had been putting off because of cost.

The lesson I drew, and which I now tell every customer at kick-off: every Recovery Services vault in any tenant older than twelve months has at least one ghost entry. Sometimes a dozen. The audit takes an afternoon and pays for itself within one billing cycle.

FAQ - the questions I get asked every week

Wrap-up

Supported scenarios for worm storage is one small piece of a larger Azure Backup story. If you came here for the answer to a specific question, I hope you found it in the walkthrough or the rollback section. If you came here while planning a wider Azure Backup build, the cost table and the pitfalls list are the two parts I would re-read before writing your design doc.

The official Microsoft Learn page is linked in the References block at the bottom and is the source of record. This page exists because I wanted a version that reflected what actually happens on real customer tenants, not what the doc team had room to fit on the canonical page. Both have their place.

If you want to talk about a specific scenario, drop me an email. I usually reply within 24 hours, and I do not bill for the first conversation.

Related fixes

Related guides worth a look while you sort this one out:

• Supported scenarios for Confidential VM backup
• Restore scenarios for Azure VMs
• What operating systems are supported for backup?
• Supported configurations / migration scenarios
• Sample scenarios for Azure Storage services
• Restore the Elastic SAN backup (preview)