Storage Disks Where did they originate from

Question

I have quite a few storage disks in my account. They were created about 8-10 years ago. I suspect that they were used for backup of virtual servers.

How can i find out where they originated from and if they are being used. I just don't want to delete them and then find out out deleted a critical part of our infrastructure.

Answer 1

Hello liliheit

Thank you for reaching out Q/A. To safely identify the origin and usage of your storage disks, please follow the standard Q/A steps. These steps cover basic checks

To complement the Q/A steps, you can also perform the following actions to get a more comprehensive view:

1. List all disks across the subscription:

az resource list --resource-type "Microsoft.Compute/disks" --query "[].{Name:name, ResourceGroup:resourceGroup, ManagedBy:properties.managedBy, Location:location}" -o table

2.Check disk attachment to virtual machines

az disk list --resource-group <resource-group-name> --query "[].{Name:name, ResourceGroup:resourceGroup, ManagedBy:managedBy}" -o table

Azure PowerShell:

Get-AzDisk | Select-Object Name, ResourceGroupName, ManagedBy

The ManagedBy field indicates the VM the disk is attached to.

2.Inspect last VM attachment / ownership

For disks that are unattached, you can still check metadata for historical context:

az disk show --name <disk-name> --resource-group <rg-name> --query "{Name:name, LastOwnershipUpdate:properties.timeCreated, ManagedBy:managedBy}" -o table

Hope this helps! Please let me know if you have any queries in comments.

Answer 2

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