Virtual Machine and Disks

Hello @TBFG Azure Admin

Thank you for contacting us about the DR issue. We have begun looking into it and will share our suggestions with you as soon as possible.

Hello @TBFG Azure Admin

Thank you for sharing us the details.

1. Are non-OS disks independent of the VM?

Yes. In your screenshot, TBFGAZ1_DataDisk_0 and TBFGAZ1_DataDisk_1 are Azure managed disks, they're first-class Azure resources that live in Azure Storage, separate from the VM's compute.

The VM only references them.

• A managed disk can exist independently of a VM (you can even create an empty managed disk without attaching it to anything).
• Managed disks are designed for 99.999% availability and at least 99.999999999% (11 nines) durability, because your data is replicated three times automatically. If one replica becomes unavailable, Azure spawns a new copy in the background.
• Data disks (and the OS disk) persist when the VM is stopped or deallocated.

Only the temporary disk (the D: drive on Windows) is volatile and will lose its contents if the VM is moved to a new host, so never put SQL backups there.

So the disks in your list are safe even if the VM has an issue, they aren't lost with the VM.

2. How do you access those disks if the VM is unavailable?

You have a few options, depending on the situation:

a) Detach the data disk and attach it to another VM This is the standard recovery pattern.

From the Azure portal (or PowerShell / CLI), you can detach a data disk from the affected VM, detaching removes the disk from the VM but does not delete it from storage, so the data is preserved. You can then attach the same managed disk to a healthy VM in the same region, mount it, and copy off your .BAK files.

Steps (portal):

1. Go to the affected VM → Settings > Disks.
2. Next to the data disk, click the detach icon and Save.
3. Go to the healthy VM → Disks > Attach existing disk, pick the disk, and Save.
4. Inside the guest OS, bring the disk online and assign a drive letter.

b) If the VM is completely unresponsive — use Force Detach If the VM is stuck / unresponsive due to a failure in the underlying stack and a normal detach won't complete, Azure supports force-detach for managed data disks specifically for VM recovery scenarios. This lets you forcibly release the disk from the unhealthy VM and mount it on another healthy VM. It's supported for managed disks on single-instance / availability-set VMs.

c) Take a snapshot and mount a copy You can also take a snapshot of the data disk, create a new managed disk from the snapshot, and attach that to another VM. This is useful when you want to leave the original disk untouched for investigation. Snapshots are a supported way to copy a managed disk.

d) Export the disk contents via SAS If you need the .BAK files off Azure entirely (for example, to restore on-premises), you can generate a read-only SAS URI for the managed disk and use the Azure portal, Azure CLI, PowerShell, or AzCopy to copy the contents to another storage account or on-premises storage.

3. Recommendations specifically for your SQL backup setup:

Since you're now writing SQL .BAK files to DataDisk1, a few things worth doing now, not during an emergency:

• Consider ZRS (Zone-Redundant Storage) disks for the data disk holding your backups. ZRS disks synchronously replicate across all three availability zones in the region, so the disk survives a full zone outage — you can attach it to a VM in a healthy zone.
• Layer in Azure Backup / Azure Site Recovery. Managed-disk redundancy protects against hardware failure, but for full DR (including region-level failure) you should enable Azure Site Recovery on the VM — it replicates the VM (including data disks) to a target region and lets you fail over during a disaster.
• Copy .BAK files off the VM regularly. A common pattern is to have the SQL job write the .BAK to DataDisk1, and then have a scheduled task / AzCopy job push those .BAK files to an Azure Storage account (Blob) in a different region. That way, even if both the VM and the disk in Australia East had a problem, you'd still have the backup file accessible independently.
• Document a "runbook" with the exact steps for (a) detach → attach to a spare VM, and (b) force-detach if the VM is unresponsive — so you're not learning it during a real incident.
• DataDisk_0 and DataDisk_1 are independent Azure managed disks — they persist even if the VM is stopped, deallocated, or deleted.
• If the VM is unavailable, detach the data disk and attach it to another VM (use force-detach if the VM is unresponsive) or restore from a snapshot / SAS copy to get to your .BAK files.
• For real DR, pair this with ZRS disks and/or Azure Site Recovery, and ship your SQL .BAK files to a separate storage account (ideally in another region) for defense in depth.

Reference documentation:

• Detach a data disk from a Windows VM [learn.microsoft.com]
• Best practices for high availability with Azure VMs and managed disks [learn.microsoft.com]
• Reliability in Azure Disk Storage [learn.microsoft.com]
• [https://learn.microsoft.com/en-us/azure/virtual-machines/faq-for-disks](https://learn.microsoft.com/en-us/azure/virtual-machines/faq-for-disks) [[docs.azure.cn]](https://docs.azure.cn/en-us/virtual-machines/faq-for-disks)
• Set up disaster recovery for Azure VMs with Azure Site Recovery [learn.microsoft.com]

Thanks,
Suchitra.