Azure VM Recovery.
In the Recovery Services vault,
there are three main paths you can go down when it comes to
recovering Windows and Linux VMs running in Azure.
You can create a new VM entirely,
and this is going to restore not only the storage,
and by storage, we're talking about the system or the OS operating system disk,
as well as data disks that may be attached to that machine,
but also the virtual machines configuration.
They're two separate things.
Now you may have such a failure in your production
VM that you actually delete it, remove it out of the virtual network,
and recreate it from scratch,
but you may just as well be interested in performing
trial restores to an alternate location.
I often say that a good backup is only as good as its ability to be
successfully restored so I hope that you and your team periodically
run these fire drill exercises where you will restore an entire VM to
a different virtual network and make sure that you can get to it and
that it's functional.
That other virtual network, or a disaster recovery VNet as we could also call it,
is critical because we remember that the virtual network is an error‑gapped
environment in the Azure cloud and so we don't have to worry about
interrupting connectivity from your production VM.
You can also, in the Recovery Services vault, restore just the disks.
This will extract the storage from a backup snapshot and place it in a blob
container in a designated general purpose storage account.
And in a move that I think is pretty considerate on the
part of the Microsoft engineering team,
when you restore the disk storage to a storage account,
you'll get an ARM, Azure Resource Manager,
template that you can use to help build a VM based on that storage.
That's a pattern actually to think about.
Using the Azure portal is what I call an 80% scenario,
I think Microsoft calls it the equivalent of that anyway.
In other words, the Azure portal, the web portal,
gives you the most common options, but for instance,
if you had need to restore an entire VM using different configuration settings,
you're going to have to do that programmatically.
So that would be a case where you would restore the storage to a
blob container and then run some Azure PowerShell to create a
new VM specifying those disk restores and also any custom
configuration you want to add.
When you do a new VM restore using the Azure portal,
it will restore, it meaning Azure,
will restore the VMs configuration as it was at the time of the backup.
Alright.
And then third,
we have replace existing and this is what's called in‑place restore.
This is the case where you don't want to disturb the virtual
machine object or any of its dependencies.
After all,
that VM may have a lot of dependencies such that you don't
want to recreate IP address mappings, whatever it might be,
membership behind a load balancer or application gateway.
The in‑place restore allows you simply to swap out the disks and keep the VM
and all of its configuration in its original location.
It's a nice convenience. It's what we can call a storage swap out.