All right.
So in our Test failover, we verify the direction East to West.
We choose our Recovery Point and what our destination virtual network is.
And I agree with this warning that's recommended that your
test failover go to a different VNet, absolutely.
And that's all there is to performing the failover operation.
And we can follow that by looking into our jobs engine.
There's a separate list of jobs for Site Recovery
jobs than there is for Backup jobs.
And we can see here step by step that Azure is following the steps of this plan.
Now at this point,
Azure is dynamically building a new VM or at least turning it
on and starting it up and verifying it.
And the idea is that this replica will subsume,
or take over, the original virtual machine.
Let me go to my other browser tab, and let's go to Virtual machines.
And we can see here, what machine is it again, is it web2?
Yes, web2.
And in this case, it's actually an Azure Virtual Machine.
Let me refresh the view.
And web2 is running now.
Let me do a hard refresh to see if that makes a difference, still running.
But we should find at the end of the process that
web2 running in the East is down,
and we'll have another web2 running in West in a
disaster recovery virtual network.
All right, what have we got?
Well, let me highlight them to make it easier for you to see.
I want you to notice that we've got our web2‑test running in the West,
and that's fine.
But the fact that web2, the original VM,
is running is actually completely expected.
I misspoke a moment ago.
We have to remember that in performing a test failover,
we don't want to perturb the production environment.
So we'll only issue the shutdown command to the source machines when
we're doing an actual honest‑to‑goodness failover.
That's an important point to consider.
So that just took two minutes or so to failover in Azure VM.
Can you expect a longer recovery time objective with on‑prem?
Well, that's going to be more variable, of course,
depending upon your internet connection,
but it should be pretty well on par because remember,
all of those VMs,
their storage and configuration from on‑prem have been enumerated.
And one of the nice things about the Hyper‑V Site Recovery Provider
and the VMware Appliance is that it helps Azure model the size of VM
that it creates in Azure in your failover environment to be on par
with what you have on‑prem.
As a matter of fact,
that's what that ASR deployment planner gives you in much more detail.
It shows you in advance what Microsoft recommends in terms of
things like Premium versus Standard storage,
VM size, and so on, and so forth.
Okay, so let's step out of this interface here.
Let's click X, whoops, took me right out of where I wanted to be.
Let's go back to our recovery‑vault in the West,
and let's go back to Protected items, Replicated items.
And let's go back here,
and notice that we've got a Cleanup test failover pending.
So if we go back to web2,
notice that we don't have an option to Change recovery
point or reverse replication direction, it's just a case of okay,
we verified that that VM to the web2‑test machine is
up and running; everything is fine.
So let's go ahead and clean it up.
Testing is complete.
Go ahead and delete.
Great.
Well, once this process finishes, we can do a real failover,
and that's going to require a bit more work.
Why?
Well, that's where these other buttons come into play.
Because when we finished the real failover,
we're going to then, once we've reestablished our source environment,
we're going to need to turn protection or turn
replication back on in the reverse direction,
resynchronize, and then do another failover in that opposite direction.
I went through all of this, I know, already, but let's face it,
a core principle of adult education sometimes is repetition.
Would you agree?
So now that that's all cleaned up, let's actually go back to Virtual machines.
Do a good old page refresh.
Yep, so our web2‑test is gone and our web2 is fine.
So now let's do a real business failover.
Again, we've got our Failover direction.
We've got our Recovery Point, Shutdown machine before beginning failover.
That's exactly what we want to see.
So once again,
we can go to the appropriate job page and we can follow this process,
which, again, remember, operates the same regardless of where those sources are.
We're following the recovery plan step by step, phase by phase.
I don't have any scripts injected, but we could if we needed them.
By the way,
I've found that the test failover is especially useful because it
gives you a safe sandbox to test those pre and/or post‑action
scripts that we've mentioned a few times.
All right, so once again, it looked about 3 minutes or so,
and that failover is complete.
So let's again go back over to Virtual Machines, do another refresh here.
And we can see, as I had mentioned,
that the original VM that's running in East is stopped and deallocated.
The replica in West is running and functional.
So at this point, our failover is complete from an infrastructure standpoint.
So the question next would be, how do we do a failback?
And as we've already learned,
it's just simply reenabling replication and failing
over in the reverse direction.
So once again, I know I'm kind of clicking around here,
let's go back into our westus vault, back to Replicated items.
Take a look at our web2 machine.
Failover is completed.
And the idea, actually, I probably should go to the Recovery Plan,
which is what I used, I think, at least I hope I did.
Come out of here and let's go down to Recovery Plans, dr‑plan.
Ah, well it looks like I did that test failover using the plan.
I cleaned up at the VM level,
so this is something that is bound to happen to most people
when you're first getting started with this.
I'm not getting started, so I don't have an excuse, by the way.
So let me come out of here, and let's go back to that single VM.
The reason I'm not concerned and why I'm not going to remove
this part of the demo is actually twofold.
One,
I want to give you the confidence that real world is
real world and mistakes happen,
unexpected events happen; it can't be perfect all the time for sure.
And number two,
I want to just underscore the fact of that difference of working
from the context of the Recovery Plan if you have a multi‑machine
workload versus the individual machines,
which you can find under Replicated items.
And in my case, it's fine because I do just have the one VM.
So let's go into web2's interface here.
And this is what I was talking about earlier.
The fact that if you do a failover of a plan or an individual VM,
you can then change the recovery point and redeploy the virtual
machine using a different synchronization snapshot.
I don't want to do that, so I will close out.
And then the idea is when you're ready to move forward then we can commit,
which would then not allow us to change the recovery point anymore.
That's fine.
We'll commit that failover.
And at that point, we go on ahead and correct our source environment.
We're going to fast forward because this is obviously a synthetic demo
environment that assuming the East US is back online,
how do we do a failback operation here?
Well, we're going to want to do, what we're going to want to do,
rather, is to re‑protect our workload, verify the settings,
which is the original environment of the workload.
That's fine.
And all of this is happening under the hood with the JSON template.
You might have seen in passing in the notification
bell it mentioned ARM templates.
All right, well, I'm waiting for synchronization to take place here in the West.
So let me select here one more time,
and let me just walk you through the rest of it.
So I completed reprotection, and now it's going through a resynchronization.
In order to finish this, to failback,
I would do once protected as my listed status.
I'll do another failover in the reverse direction,
commit that failover,
re‑protect one final time so that I'm going from the primary to the dr site, and then I think we're ready to go.