Storage Disks Where did they originate from

To safely identify and clean up old Azure disks, use a combination of “attachment state” and metadata.

1. Identify whether disks are attached (in use)

Managed disks (current default):

• In the Azure portal:
  1. Go to Disks.
  2. Open each disk and check Disk state.
  3. If it shows Unattached, the disk is not currently used by any VM and is a candidate for cleanup.
• At scale, use the Azure CLI script described in the managed-disk article:
  • It checks the ManagedBy property of each disk.
  • If ManagedBy is null, the disk is unattached.
  • First run with deleteUnattachedDisks = 0 to only list disks; after review, re-run with deleteUnattachedDisks = 1 to delete them.

Unmanaged disks (older model, .vhd page blobs):

• These are VHD files stored as page blobs in storage accounts.
• Use the PowerShell script from the unmanaged-disk article:
  • It scans all storage accounts and checks the LeaseStatus of each page blob.
  • LeaseStatus = Locked → attached to a VM.
  • LeaseStatus = Unlocked → unattached.
  • The script has deleteUnattachedVHDs = $false by default so it only reports; set to $true to delete after review.

2. Check whether a VHD is attached to a specific VM

When trying to delete a storage account/container/blob and you see lease errors, Azure is protecting attached VHDs:

• In the portal:
  1. Go to the storage account → Containers → locate the VHD blob.
  2. If Lease State is Leased, open Edit metadata.
  3. Look at:
     • MicrosoftAzureCompute_VMName → name of the VM using the VHD.
     • MicrosoftAzureCompute_DiskType → OSDisk or DataDisk.
• If these metadata fields are missing but the blob is leased, it is explicitly leased and not attached to a VM; break the lease before deletion.

3. Understand “where they originated from”

For unmanaged VHDs:

• The metadata fields above (MicrosoftAzureCompute_VMName, MicrosoftAzureCompute_DiskType) tell which VM originally used the disk and whether it was OS or data.

For managed disks:

• The ManagedBy property (when not null) contains the resource ID of the VM currently using the disk.
• For disks that are now unattached, use:
  • LastOwnershipUpdateTime (via az disk show) to see when the disk was last attached/detached.
  • Naming conventions, resource group names, and tags (if used historically) to infer original purpose.

4. Safely clean up

Recommended process:

1. Enumerate all disks and classify:
   • Managed vs unmanaged.
   • Attached vs unattached.
2. For each unattached disk:
   • Confirm no current VM references it (via ManagedBy or blob metadata).
   • Optionally take a backup (for example, Azure Disk Backup or snapshot) before deletion.
3. Delete only after:
   • Verifying it is unattached.
   • Verifying it is not needed for any restore or legacy scenario.

Remember that disk deletions are permanent; data cannot be recovered once a disk or VHD is deleted unless a separate backup exists.

References:

• Find and delete unattached Azure managed and unmanaged disks - Azure portal
• Find and delete unattached Azure managed and unmanaged disks by using Azure PowerShell
• Find and delete unattached Azure managed and unmanaged disks by using the Azure CLI
• Troubleshoot storage resource deletion errors
• Restore Azure Disks using Azure Data Protection REST API