Commvault with Azure Blob storage

Each break matches a real Commvault alert: “data aging didn’t free space” and “mount path offline”.

1Break it: data aging can’t prune

Commvault’s retention for this job has ended, so data aging tries to delete the chunks:

az storage blob delete --account-name $st --auth-mode login --container-name cv-library --name CV_MAGNETIC/V_101/CHUNK_2001/SFILE_CONTAINER_001

You’ll get an error like this:

This operation is not permitted as the blob is immutable due to a policy.
RequestId:...
Time:...
ErrorCode:BlobImmutableDueToPolicy

The Azure lock outlives the Commvault retention, so pruning fails and the bill keeps growing. In real libraries this shows up months later as a cloud library far bigger than the jobs it holds.

Fix it: lock periods must match retention. In Commvault, WORM is set from the storage policy so the lock follows retention plus a small buffer. In this lab, the policy is still not locked, so remove it and prune:

$etag = az storage container immutability-policy show --resource-group rg-saat-data --account-name $st --container-name cv-library --query etag -o tsv
az storage container immutability-policy delete --resource-group rg-saat-data --account-name $st --container-name cv-library --if-match $etag
az storage blob delete --account-name $st --auth-mode login --container-name cv-library --name CV_MAGNETIC/V_101/CHUNK_2001/SFILE_CONTAINER_001
az storage blob list --account-name $st --auth-mode login --container-name cv-library --query "length([])"

You should see this:

2

A locked policy can’t be removed. If one is ever set too long, you wait it out and pay for the storage; there is no undo.

2Break it: the mount path goes offline

Someone switches the storage firewall to Deny without adding the MediaAgent’s address:

az storage account update --resource-group rg-saat-data --name $st --default-action Deny -o none
Start-Sleep -Seconds 30
az storage blob list --account-name $st --auth-mode login --container-name cv-library -o table

You’ll get this error:

The request may be blocked by network rules of storage account. Please check network rule set using 'az storage account show -n accountname --query networkRuleSet'.
If you want to change the default action to apply when no rule matches, please use 'az storage account update'.

In Command Center this appears as the mount path going offline and backup jobs waiting for resources. Commvault logs show HTTP 403 with AuthorizationFailure. The fix is on the Azure side, not in Commvault.

Fix it: allow the MediaAgent’s network (a VNet rule, an IP rule, or a private endpoint with the privatelink service host). For the lab, open the account again and clean up:

az storage account update --resource-group rg-saat-data --name $st --default-action Allow -o none
az storage blob delete-batch --account-name $st --auth-mode login --source cv-library -o none
az storage container delete --account-name $st --auth-mode login --name cv-library -o none
Remove-Item C:\azure-lab\cv-chunks -Recurse

✅ Checkpoint: You traced a pruning failure to an immutability policy and an offline library to the storage firewall, and removed the lab container.