1
00:00:00,840 --> 00:00:02,940
Azure VM Recovery.

2
00:00:02,940 --> 00:00:04,760
In the Recovery Services vault,

3
00:00:04,760 --> 00:00:08,080
there are three main paths you can go down when it comes to

4
00:00:08,080 --> 00:00:12,140
recovering Windows and Linux VMs running in Azure.

5
00:00:12,140 --> 00:00:14,940
You can create a new VM entirely,

6
00:00:14,940 --> 00:00:17,400
and this is going to restore not only the storage,

7
00:00:17,400 --> 00:00:22,640
and by storage, we're talking about the system or the OS operating system disk,

8
00:00:22,640 --> 00:00:26,300
as well as data disks that may be attached to that machine,

9
00:00:26,300 --> 00:00:28,990
but also the virtual machines configuration.

10
00:00:28,990 --> 00:00:31,040
They're two separate things.

11
00:00:31,040 --> 00:00:34,570
Now you may have such a failure in your production

12
00:00:34,570 --> 00:00:38,690
VM that you actually delete it, remove it out of the virtual network,

13
00:00:38,690 --> 00:00:41,040
and recreate it from scratch,

14
00:00:41,040 --> 00:00:43,990
but you may just as well be interested in performing

15
00:00:43,990 --> 00:00:47,250
trial restores to an alternate location.

16
00:00:47,250 --> 00:00:51,500
I often say that a good backup is only as good as its ability to be

17
00:00:51,500 --> 00:00:55,110
successfully restored so I hope that you and your team periodically

18
00:00:55,110 --> 00:01:00,510
run these fire drill exercises where you will restore an entire VM to

19
00:01:00,510 --> 00:01:04,290
a different virtual network and make sure that you can get to it and

20
00:01:04,290 --> 00:01:05,640
that it's functional.

21
00:01:05,640 --> 00:01:10,540
That other virtual network, or a disaster recovery VNet as we could also call it,

22
00:01:10,540 --> 00:01:14,540
is critical because we remember that the virtual network is an error‑gapped

23
00:01:14,540 --> 00:01:18,190
environment in the Azure cloud and so we don't have to worry about

24
00:01:18,190 --> 00:01:21,840
interrupting connectivity from your production VM.

25
00:01:21,840 --> 00:01:26,680
You can also, in the Recovery Services vault, restore just the disks.

26
00:01:26,680 --> 00:01:31,050
This will extract the storage from a backup snapshot and place it in a blob

27
00:01:31,050 --> 00:01:34,500
container in a designated general purpose storage account.

28
00:01:34,500 --> 00:01:37,110
And in a move that I think is pretty considerate on the

29
00:01:37,110 --> 00:01:39,740
part of the Microsoft engineering team,

30
00:01:39,740 --> 00:01:42,820
when you restore the disk storage to a storage account,

31
00:01:42,820 --> 00:01:45,440
you'll get an ARM, Azure Resource Manager,

32
00:01:45,440 --> 00:01:49,980
template that you can use to help build a VM based on that storage.

33
00:01:49,980 --> 00:01:52,540
That's a pattern actually to think about.

34
00:01:52,540 --> 00:01:56,710
Using the Azure portal is what I call an 80% scenario,

35
00:01:56,710 --> 00:01:59,730
I think Microsoft calls it the equivalent of that anyway.

36
00:01:59,730 --> 00:02:03,130
In other words, the Azure portal, the web portal,

37
00:02:03,130 --> 00:02:06,230
gives you the most common options, but for instance,

38
00:02:06,230 --> 00:02:12,040
if you had need to restore an entire VM using different configuration settings,

39
00:02:12,040 --> 00:02:14,260
you're going to have to do that programmatically.

40
00:02:14,260 --> 00:02:18,040
So that would be a case where you would restore the storage to a

41
00:02:18,040 --> 00:02:22,250
blob container and then run some Azure PowerShell to create a

42
00:02:22,250 --> 00:02:27,590
new VM specifying those disk restores and also any custom

43
00:02:27,590 --> 00:02:29,940
configuration you want to add.

44
00:02:29,940 --> 00:02:33,330
When you do a new VM restore using the Azure portal,

45
00:02:33,330 --> 00:02:35,890
it will restore, it meaning Azure,

46
00:02:35,890 --> 00:02:40,770
will restore the VMs configuration as it was at the time of the backup.

47
00:02:40,770 --> 00:02:41,640
Alright.

48
00:02:41,640 --> 00:02:42,410
And then third,

49
00:02:42,410 --> 00:02:46,840
we have replace existing and this is what's called in‑place restore.

50
00:02:46,840 --> 00:02:50,410
This is the case where you don't want to disturb the virtual

51
00:02:50,410 --> 00:02:53,210
machine object or any of its dependencies.

52
00:02:53,210 --> 00:02:54,150
After all,

53
00:02:54,150 --> 00:02:57,790
that VM may have a lot of dependencies such that you don't

54
00:02:57,790 --> 00:03:02,190
want to recreate IP address mappings, whatever it might be,

55
00:03:02,190 --> 00:03:06,740
membership behind a load balancer or application gateway.

56
00:03:06,740 --> 00:03:12,050
The in‑place restore allows you simply to swap out the disks and keep the VM

57
00:03:12,050 --> 00:03:16,100
and all of its configuration in its original location.

58
00:03:16,100 --> 00:03:21,000
It's a nice convenience. It's what we can call a storage swap out.