1 00:00:00,840 --> 00:00:04,690 Now when you schedule machine backup, and when I say machine, I say 2 00:00:04,690 --> 00:00:08,490 that intentionally because, of course, we can back up Azure virtual 3 00:00:08,490 --> 00:00:12,400 machines, but we can also back up physical and virtual machines in 4 00:00:12,400 --> 00:00:14,360 other clouds that are on‑premises. 5 00:00:14,360 --> 00:00:19,140 You orchestrate that process by means of backup policies. 6 00:00:19,140 --> 00:00:21,680 When you're protecting Azure workloads, 7 00:00:21,680 --> 00:00:24,940 there are four templates that you can choose from. 8 00:00:24,940 --> 00:00:27,830 The traditional VM, or virtual machine, template. 9 00:00:27,830 --> 00:00:31,340 Again, it's fine if it's Windows or Linux. It doesn't matter. 10 00:00:31,340 --> 00:00:38,000 You can protect file shares in Azure Storage. You can protect VMs running SQL 11 00:00:38,000 --> 00:00:42,690 Server. I'm not talking about Azure SQL Database or Managed Instance or 12 00:00:42,690 --> 00:00:46,400 Synapse Analytics. They have their own hosted backups. 13 00:00:46,400 --> 00:00:50,100 I'm talking about an Azure VM running SQL Server Database 14 00:00:50,100 --> 00:00:54,120 Engine. And there's also a backup policy template for SAP 15 00:00:54,120 --> 00:00:56,440 HANA, the in‑memory database. 16 00:00:56,440 --> 00:01:00,500 When you think about it, if you've ever done work with databases, 17 00:01:00,500 --> 00:01:04,180 you know that their backup is more than just backing up data files. 18 00:01:04,180 --> 00:01:06,890 You've got to think about consistency levels. 19 00:01:06,890 --> 00:01:10,440 You need to think about transaction logs. That's why 20 00:01:10,440 --> 00:01:13,430 Microsoft has those special templates, 21 00:01:13,430 --> 00:01:18,090 at least for SQL Server and SAP HANA. Another thing you specify in your 22 00:01:18,090 --> 00:01:22,020 backup policies is your backup schedule and retention range. Of course, 23 00:01:22,020 --> 00:01:27,290 the backup schedule is how often, or what is your frequency of backup, 24 00:01:27,290 --> 00:01:31,790 and what is your time zone that you want that time scheduled to hit. As 25 00:01:31,790 --> 00:01:35,960 far as retention goes, you set daily, the maximum number of daily, 26 00:01:35,960 --> 00:01:36,330 weekly, 27 00:01:36,330 --> 00:01:39,140 monthly, and yearly backup points that you want to keep. That's 28 00:01:39,140 --> 00:01:42,840 going to be in line with your compliance requirements. And a 29 00:01:42,840 --> 00:01:46,700 feature that I like an awful lot with the Recovery Services vault 30 00:01:46,700 --> 00:01:48,390 is called instant restore. 31 00:01:48,390 --> 00:01:52,200 And this is simply a way to dramatically shorten your 32 00:01:52,200 --> 00:01:55,810 restore window by keeping between one and five days' worth 33 00:01:55,810 --> 00:01:59,140 of your Azure VM snapshots local. 34 00:01:59,140 --> 00:02:04,100 The way that Azure VM backup works is that it's a two‑step process. 35 00:02:04,100 --> 00:02:08,460 There's the initial snapshot, and then asynchronously, that 36 00:02:08,460 --> 00:02:12,740 snapshot gets packed into the Recovery Services vault. 37 00:02:12,740 --> 00:02:13,070 Well, 38 00:02:13,070 --> 00:02:17,300 it's that second step from the instant restore area to the 39 00:02:17,300 --> 00:02:20,840 Recovery Services vault that's the long hop. 40 00:02:20,840 --> 00:02:25,440 And if you need to restore an entire disk or an entire virtual 41 00:02:25,440 --> 00:02:30,900 machine in Azure now, you can bypass that long first step, that is, 42 00:02:30,900 --> 00:02:34,890 unpacking the snapshot from the RS vault into the Instant Restore 43 00:02:34,890 --> 00:02:43,000 area by restoring a snapshot that's already in that Instant Restore area. Make sense?