Virtual machine disk snapshot fails with 'Resource is locked' error during backup automation

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

We’re running an automated backup script using Azure CLI that creates snapshots of VM managed disks every night. The script worked fine for months, but recently started failing with this error:


ERROR: The scope '/subscriptions/.../disks/vm-prod-disk-01' cannot perform write operation
because following scope(s) are locked: '/subscriptions/.../disks/vm-prod-disk-01'.
Please remove the lock and try again.

I checked the disk in the portal and there’s a Read-only lock applied at the resource group level. The issue is, we need that lock for compliance - it prevents accidental deletion of production resources. But now our backup automation is broken because snapshots apparently require write access even though they’re creating a separate resource.

Is there a way to configure resource lock types that allow snapshots but still prevent deletions? Our compliance team requires locks on all production resource groups, but backup automation is equally critical. This is blocking our entire backup strategy.

2

Let me provide a complete solution covering all three aspects of your backup and compliance challenge:

1. Resource Lock Types: Azure provides two types of resource locks, and understanding the difference is crucial for your scenario:

  • ReadOnly Lock: Prevents all modifications to the resource, including read-write operations. This blocks snapshot creation because snapshots require write access to read the disk data and create the snapshot resource. This is what’s breaking your backup automation.

  • CanNotDelete Lock: Prevents deletion of the resource but allows all other operations including modifications, configuration changes, and snapshot creation. This is the correct lock type for your compliance requirement.

The key insight: Creating a snapshot is technically a “write” operation from Azure’s perspective because it requires reading disk data and creating a new resource. ReadOnly locks block this operation entirely.

2. Snapshot Automation: To fix your backup script, you need to:

First, remove the ReadOnly lock and replace it with CanNotDelete:


az lock delete --name readonly-lock --resource-group prod-rg
az lock create --name nodelete-lock --lock-type CanNotDelete --resource-group prod-rg

Your existing snapshot script should then work correctly:


az snapshot create --resource-group snapshots-rg --name vm-prod-disk-01-snapshot-$(date +%Y%m%d) --source /subscriptions/.../disks/vm-prod-disk-01

3. Backup Compliance: To meet compliance requirements while maintaining automation:

Lock Strategy:

  • Apply CanNotDelete locks at the resource group level for all production resources
  • This prevents accidental deletion while allowing backup operations
  • Locks inherit to all child resources (VMs, disks, NICs, etc.)
  • Document that deletion requires explicit lock removal, which creates an audit trail

Backup Best Practices:

  • Store snapshots in a separate resource group from source disks (prevents accidental deletion of backups)
  • Apply ReadOnly locks to your backup/snapshot resource group (snapshots are immutable once created)
  • Implement retention policies using Azure Automation or Logic Apps to delete old snapshots
  • Use tags to track snapshot metadata (source disk, creation date, retention period)

Compliance Documentation:

  • CanNotDelete locks satisfy most compliance frameworks (SOC2, ISO 27001, HIPAA) because they prevent unauthorized deletion
  • All lock removal operations are logged in Azure Activity Log for audit purposes
  • Consider Azure Policy to automatically apply CanNotDelete locks to new production resource groups

Alternative Approach - Azure Backup Service: If you want a more robust solution, consider migrating from custom snapshot scripts to Azure Backup:


// Pseudocode - Azure Backup setup:
1. Create Recovery Services vault in backup-rg
2. Enable backup for production VMs with daily policy
3. Configure retention: daily (7 days), weekly (4 weeks), monthly (12 months)
4. Azure Backup handles locks automatically - works with CanNotDelete locks
5. Provides additional features: cross-region restore, restore point collections
// See documentation: Azure Backup for VMs

Azure Backup is designed to work with resource locks and provides:

  • Automated backup scheduling with no custom scripts
  • Built-in retention and lifecycle management
  • Compliance reports and restore testing
  • Better integration with Azure Security Center

Verification Steps:

  1. Change lock type from ReadOnly to CanNotDelete on your production resource group
  2. Test snapshot creation manually using Azure CLI to verify it works
  3. Run your automated backup script and confirm successful execution
  4. Verify in Activity Log that lock prevents deletion attempts
  5. Document the lock strategy in your compliance runbook

The bottom line: CanNotDelete locks provide the protection your compliance team needs while allowing your backup automation to function correctly. This is the standard approach for production environments requiring both data protection and operational flexibility.

3

Worth mentioning that if you have multiple resource groups with different compliance needs, you can apply different lock types. Production RGs might use CanNotDelete while dev/test could use ReadOnly or no locks. Just document your lock strategy clearly so the team understands why certain operations work in some environments but not others.

4

Thanks, that makes sense. Before I change the lock type, I need to understand - if I use CanNotDelete at the resource group level, will it still prevent someone from accidentally deleting individual VMs or disks within that group? Our compliance requirement is specifically around preventing resource deletion.

5

Yes, CanNotDelete locks inherit down to all resources in the resource group. If you apply it at the RG level, every VM, disk, NIC, etc. in that group will be protected from deletion. The lock doesn’t prevent modifications like resizing VMs, changing configurations, or creating snapshots - only deletion operations are blocked. This is exactly what you want for backup compliance scenarios.

6

I agree with switching to CanNotDelete locks. We had the exact same issue and that solved it. The key difference: ReadOnly locks prevent writes (including snapshots), while CanNotDelete locks only prevent deletion operations. Your backup script will work with CanNotDelete locks in place.

7

Read-only locks prevent ANY modifications to the resource, including snapshot operations. You need to use CanNotDelete locks instead, which allow modifications but prevent deletion. That should satisfy your compliance requirements while allowing snapshots to work.