Azure VM recovery options

Recovery Options

When it comes to Azure VM recovery you’ve a few options available, you can:

• Create an Azure virtual machine from your backup
• Restore the disks associated with the Azure VM

Create a virtual machine from backup

The first thing I should call out with this option is that this process creates a new Azure VM attached to the disks that are being restored.  Why does that matter?  Well for starters the restored VM will get a new vNIC created during the restore and so a new IP.  Its also conceivable that you could give the new Azure VM a name different to that of the computer name in the underlying OS.

“Well for starters the restored VM will get a new vNIC created during the restore and so a new IP”

Creating a new Azure VM does have advantages, it can be very useful for troubleshooting, you can quickly create a clone of your Azure VM from the point of backup and use this to troubleshoot issues or carry out testing.  Keep in mind though if your original VM is still running then you should create the restored Azure VM on a different VNET to ensure you don’t hit issues with duplicate names and DNS entries with differing IPs.

If you’re trying to recover an Azure VM that was accidentally deleted or isn’t recoverable then you’re likely to want to get the VM back to a running state with exactly the same configuration as before.  So again calling out the new vNIC that will be created, once you have create an Azure VM from the restore you’ll need to detach its new vNIC and attach the vNIC from the original VM.  This will need to be carried out while the Azure VM is deallocated and you’ll likely need to tidy up DNS to ensure the correct IP is in DNS.  Lastly you’ll need to delete the vNIC created during the restore to keep you environment neat and tidy.

One other thing to note, restores will create new blobs for your Azure VMs disks, if the old VMs disk’s remain and you don’t need them you’re going to need to delete them or they’ll continue to incur cost.

So key takeaways from creating a virtual machine from your backup.

1. Its a new Azure VM referencing a restored copy of the backed up VMs disks.
2. The new Azure VM will get a new vNIC and a new IP.
3. Naming conventions kinda go out the window, you won’t get to select your own disk names or vNIC names.
4. Tags are restored.
5. If your old Azure VM no longer exists the new Azure VM doesn’t necessarily need to have the same Azure VM name as the original but the original computer name will persist in the OS.
6. Auto-shutdown settings will be lost, you’ll need to set these up on the restored Azure VM if your original Azure VM used these.
7. It provides a simple means to clone an Azure VM which can be restored to an isolated VNET while the original VM continues to run.

“restores will create new blobs for your Azure VMs disks, if the old VMs disk’s remain and you don’t need them you’re going to need to delete them or they’ll continue to incur cost”

Restore the disks associated with the Azure VM

As the heading suggests this option isn’t going to restore your Azure VM back to a running state, however it will give you a copy of your disks at the point of backup.  What use is that?  Well you can attach the disks to another Azure VM and these will appear as local disks, which opens up the option of OS recovery. If your original VM has failed due to a file corruption or incorrect settings in a configuration file you can carry out a repair, detach the disks and then deploy a VM using PowerShell or JSON which is attached to the restored disks.

“If your original VM has failed due to a file corruption or incorrect settings in a configuration file you can carry out a repair”

Restoring the disks and then deploying a new Azure VM using PowerShell or JSON is another approach, you’ve flexibility here, if its not in use you can attach the existing vNIC to the VM, you could go a step further and copy the restored disks/blobs to new blobs in a location of your choosing using your naming conventions for blobs.  Essentially the steps of restoring the disks and then deploying a JSON to create a new VM is the same process that creating a VM from a restore does, doing it manually gives you increased flexibility but will take more time and effort.