1 00:00:01,140 --> 00:00:02,170 In this demonstration, 2 00:00:02,170 --> 00:00:05,520 we're going to pick up where we left off in the first one. In the first one, 3 00:00:05,520 --> 00:00:09,050 I took you through several restore scenarios in the Recovery Services 4 00:00:09,050 --> 00:00:12,180 vault, and I'm just going to continue that trend here. 5 00:00:12,180 --> 00:00:14,440 So let's get into the middle of things here. 6 00:00:14,440 --> 00:00:19,770 We're on the Backup items blade in our Recovery Services vault, and we had 7 00:00:19,770 --> 00:00:23,540 looked at the Azure Virtual Machine restore scenario. 8 00:00:23,540 --> 00:00:26,040 What about your on‑premises machines that you've 9 00:00:26,040 --> 00:00:28,290 used, say, the Azure Backup agent, 10 00:00:28,290 --> 00:00:30,610 that's the MARS agent for single window server 11 00:00:30,610 --> 00:00:33,300 machines, or the Azure Backup Server. 12 00:00:33,300 --> 00:00:38,240 As you can see, I've got cloud‑based backups for both of those environments. 13 00:00:38,240 --> 00:00:43,940 Well, here the pattern to remember is that Azure does not handle the restore. 14 00:00:43,940 --> 00:00:49,020 We're only using the Recovery Services vault restore tools for Azure VMs, 15 00:00:49,020 --> 00:00:50,700 both Linux and Windows. 16 00:00:50,700 --> 00:00:55,550 These are our on‑premises machines, in this case, this is Azure Backup agent, 17 00:00:55,550 --> 00:00:58,790 and you'll notice that if I open the ellipsis, actually, 18 00:00:58,790 --> 00:01:02,240 it's kind of funny that there's an ellipsis, but it actually 19 00:01:02,240 --> 00:01:05,340 doesn't even open, and if I select View details, 20 00:01:05,340 --> 00:01:09,560 it's just giving us metadata about those recovery points because 21 00:01:09,560 --> 00:01:14,930 we'll need to use the Azure Backup software on the server in order 22 00:01:14,930 --> 00:01:19,670 to handle those cloud‑based restores. The same pattern exists for 23 00:01:19,670 --> 00:01:21,200 the Azure Backup Server. 24 00:01:21,200 --> 00:01:27,040 So let's go here, and I've got my database backup from my on‑premises machine. 25 00:01:27,040 --> 00:01:27,680 Once again, 26 00:01:27,680 --> 00:01:30,440 I'm madly clicking the ellipsis here and nothing is 27 00:01:30,440 --> 00:01:33,300 happening. And if I click View details, 28 00:01:33,300 --> 00:01:36,240 we get a similar collection of metadata. But again, 29 00:01:36,240 --> 00:01:40,150 the idea is we'll use the Microsoft Azure Backup Server 30 00:01:40,150 --> 00:01:42,460 in order to handle those restores. 31 00:01:42,460 --> 00:01:43,440 Okay, 32 00:01:43,440 --> 00:01:47,930 now I want to sweep up some shavings from our first demo earlier. We saw, 33 00:01:47,930 --> 00:01:51,890 unfortunately, that there's not much parallelism in Recovery Services vault. 34 00:01:51,890 --> 00:01:56,270 That is, I initiated a restore and then found that I couldn't initiate a 35 00:01:56,270 --> 00:01:59,240 second restore until the first one was finished. 36 00:01:59,240 --> 00:02:00,830 So to that point, actually, 37 00:02:00,830 --> 00:02:03,840 let's go down into our backup jobs and let me show you some 38 00:02:03,840 --> 00:02:07,000 things I've been doing in the background here in between 39 00:02:07,000 --> 00:02:09,210 the first demo and the second. 40 00:02:09,210 --> 00:02:13,750 I actually canceled the restore that I had configured in the previous demo. 41 00:02:13,750 --> 00:02:17,870 Now you might remember, the way this worked by going to View details is 42 00:02:17,870 --> 00:02:23,950 that I did a Recover VM to an alternate location of my web1 Azure VM, and I 43 00:02:23,950 --> 00:02:27,150 was going to put it in another virtual network, 44 00:02:27,150 --> 00:02:32,160 my dr‑vnet, and give it a different name. And I had made the remark, 45 00:02:32,160 --> 00:02:34,050 why is this taking so long? 46 00:02:34,050 --> 00:02:35,760 It seemed to be very slow. 47 00:02:35,760 --> 00:02:40,060 What I realized only after I stopped recording that first demo is 48 00:02:40,060 --> 00:02:44,480 that I was choosing a restore point that was not in the quick 49 00:02:44,480 --> 00:02:47,040 restore area or the instant restore area. 50 00:02:47,040 --> 00:02:49,730 Of course, it's going to take exponentially longer. 51 00:02:49,730 --> 00:02:54,750 That's the reason the instant restore area exists as far as that goes. 52 00:02:54,750 --> 00:03:00,080 So what I then did is performed a restore of web1 and web2. 53 00:03:00,080 --> 00:03:02,590 I did two different kinds of restorations. 54 00:03:02,590 --> 00:03:05,360 Let me see, for web1, let's go in here. 55 00:03:05,360 --> 00:03:09,000 This would be Recover VM to an alternate location, so we 56 00:03:09,000 --> 00:03:10,950 can actually test this really quickly. 57 00:03:10,950 --> 00:03:16,140 Let me open up another browser tab and go to portal.azure.com. 58 00:03:16,140 --> 00:03:17,640 If I can type, once again, 59 00:03:17,640 --> 00:03:24,680 I know I say that a lot, and let me dial up our virtual networks and go to my 60 00:03:24,680 --> 00:03:29,670 disaster recovery, dr‑vnet. And if I go to connected devices, 61 00:03:29,670 --> 00:03:31,770 I've got web1‑test2. 62 00:03:31,770 --> 00:03:39,040 So we can actually go to that VM here, web1‑test2. Looks like it's up 63 00:03:39,040 --> 00:03:43,400 and running, and so far so good as far as it being functional in that 64 00:03:43,400 --> 00:03:47,840 new disaster recovery net. All right, so let's go back to restore. 65 00:03:47,840 --> 00:03:49,640 Let's come out of here. 66 00:03:49,640 --> 00:03:52,760 Go back to, oops, I didn't mean to do that. 67 00:03:52,760 --> 00:03:56,550 Let's go back to this actually bleeds over into the subject 68 00:03:56,550 --> 00:03:58,850 of monitoring, anyway. It's a good thing. 69 00:03:58,850 --> 00:04:00,580 The backup jobs list. 70 00:04:00,580 --> 00:04:03,000 Let me check out web2 details. 71 00:04:03,000 --> 00:04:06,640 What I did here is I just recovered the disks. 72 00:04:06,640 --> 00:04:10,980 Remember that option, where, for instance, you want to create a new VM using 73 00:04:10,980 --> 00:04:13,770 a different configuration, and when you go that route, 74 00:04:13,770 --> 00:04:16,100 you specify a storage account name, 75 00:04:16,100 --> 00:04:23,440 drstorage, and then it tells us where the JSON is that references that blob URI. 76 00:04:23,440 --> 00:04:27,380 And actually, it looks like those go to the JSON supplemental file. 77 00:04:27,380 --> 00:04:32,890 So, long story short, we'll go in drstorage, and config‑web2 is the name of 78 00:04:32,890 --> 00:04:38,660 the JSON. I happen to have Azure Storage Explorer here, and I'm in 79 00:04:38,660 --> 00:04:52,000 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.