In this demonstration,
we're going to pick up where we left off in the first one. In the first one,
I took you through several restore scenarios in the Recovery Services
vault, and I'm just going to continue that trend here.
So let's get into the middle of things here.
We're on the Backup items blade in our Recovery Services vault, and we had
looked at the Azure Virtual Machine restore scenario.
What about your on‑premises machines that you've
used, say, the Azure Backup agent,
that's the MARS agent for single window server
machines, or the Azure Backup Server.
As you can see, I've got cloud‑based backups for both of those environments.
Well, here the pattern to remember is that Azure does not handle the restore.
We're only using the Recovery Services vault restore tools for Azure VMs,
both Linux and Windows.
These are our on‑premises machines, in this case, this is Azure Backup agent,
and you'll notice that if I open the ellipsis, actually,
it's kind of funny that there's an ellipsis, but it actually
doesn't even open, and if I select View details,
it's just giving us metadata about those recovery points because
we'll need to use the Azure Backup software on the server in order
to handle those cloud‑based restores. The same pattern exists for
the Azure Backup Server.
So let's go here, and I've got my database backup from my on‑premises machine.
Once again,
I'm madly clicking the ellipsis here and nothing is
happening. And if I click View details,
we get a similar collection of metadata. But again,
the idea is we'll use the Microsoft Azure Backup Server
in order to handle those restores.
Okay,
now I want to sweep up some shavings from our first demo earlier. We saw,
unfortunately, that there's not much parallelism in Recovery Services vault.
That is, I initiated a restore and then found that I couldn't initiate a
second restore until the first one was finished.
So to that point, actually,
let's go down into our backup jobs and let me show you some
things I've been doing in the background here in between
the first demo and the second.
I actually canceled the restore that I had configured in the previous demo.
Now you might remember, the way this worked by going to View details is
that I did a Recover VM to an alternate location of my web1 Azure VM, and I
was going to put it in another virtual network,
my dr‑vnet, and give it a different name. And I had made the remark,
why is this taking so long?
It seemed to be very slow.
What I realized only after I stopped recording that first demo is
that I was choosing a restore point that was not in the quick
restore area or the instant restore area.
Of course, it's going to take exponentially longer.
That's the reason the instant restore area exists as far as that goes.
So what I then did is performed a restore of web1 and web2.
I did two different kinds of restorations.
Let me see, for web1, let's go in here.
This would be Recover VM to an alternate location, so we
can actually test this really quickly.
Let me open up another browser tab and go to portal.azure.com.
If I can type, once again,
I know I say that a lot, and let me dial up our virtual networks and go to my
disaster recovery, dr‑vnet. And if I go to connected devices,
I've got web1‑test2.
So we can actually go to that VM here, web1‑test2. Looks like it's up
and running, and so far so good as far as it being functional in that
new disaster recovery net. All right, so let's go back to restore.
Let's come out of here.
Go back to, oops, I didn't mean to do that.
Let's go back to this actually bleeds over into the subject
of monitoring, anyway. It's a good thing.
The backup jobs list.
Let me check out web2 details.
What I did here is I just recovered the disks.
Remember that option, where, for instance, you want to create a new VM using
a different configuration, and when you go that route,
you specify a storage account name,
drstorage, and then it tells us where the JSON is that references that blob URI.
And actually, it looks like those go to the JSON supplemental file.
So, long story short, we'll go in drstorage, and config‑web2 is the name of
the JSON. I happen to have Azure Storage Explorer here, and I'm in
twdrstorage, web2, and I've got my config‑web2 JSON here. Let's open this up by downloading it and opening it in my default text editor.