1 00:00:00,000 --> 00:00:01,400 Welcome to another Knowledge Nugget. 2 00:00:01,400 --> 00:00:05,520 Today's topic is one that every IT person has thought about at least once. 3 00:00:05,520 --> 00:00:09,800 Imagine your company's server crashes, your VM is gone, your data is gone, what do you do? 4 00:00:09,800 --> 00:00:13,240 20 years ago, the answer meant digging out backup tapes or external drives, 5 00:00:13,240 --> 00:00:15,720 or finding that backup server sitting in a closet somewhere, 6 00:00:15,720 --> 00:00:18,680 you'd rotate media, label boxes, and hope nothing went wrong. 7 00:00:18,680 --> 00:00:22,520 And here's the thing, you only knew your backup worked when you actually tried to restore it. 8 00:00:22,520 --> 00:00:27,600 As your backup changes that equation, no tapes, no on-prem servers, no crossed fingers. 9 00:00:27,600 --> 00:00:30,880 By the end of this episode, you'll understand exactly what as your backup is, 10 00:00:30,880 --> 00:00:34,200 what it protects, and how it works behind the scenes. 11 00:00:34,200 --> 00:00:36,520 Let's start with the simplest definition. 12 00:00:36,520 --> 00:00:38,560 What Azure backup actually is. 13 00:00:38,560 --> 00:00:41,760 Azure backup is Microsoft's built-in backup service for the cloud, 14 00:00:41,760 --> 00:00:44,320 but that simple answer hides something bigger. 15 00:00:44,320 --> 00:00:45,640 It's not a single tool at all. 16 00:00:45,640 --> 00:00:50,520 It's a connected platform that protects virtual machines, databases, file shares, 17 00:00:50,520 --> 00:00:53,440 and even machines sitting in your own office. 18 00:00:53,440 --> 00:00:55,960 Instead of managing backup hardware and software yourself, 19 00:00:55,960 --> 00:00:59,000 as your handles the storage, the scheduling, and the security. 20 00:00:59,000 --> 00:01:01,920 You tell it what to protect and how often, and it does the rest. 21 00:01:01,920 --> 00:01:03,960 Think of it like a safety deposit box at a bank. 22 00:01:03,960 --> 00:01:08,080 You drop your valuables in, and the bank handles the security, the fireproofing, the vault. 23 00:01:08,080 --> 00:01:10,040 When you need something back, you go get it. 24 00:01:10,040 --> 00:01:12,200 You don't build your own vault in your basement. 25 00:01:12,200 --> 00:01:13,880 Azure backup works the same way. 26 00:01:13,880 --> 00:01:16,840 You don't buy backup servers or manage tape rotations. 27 00:01:16,840 --> 00:01:19,920 You just decide what matters, and let Azure store it safely. 28 00:01:19,920 --> 00:01:21,920 That's the real difference from traditional backup. 29 00:01:21,920 --> 00:01:25,400 No more tape rotations or off-site storage management or fingers crossed. 30 00:01:25,400 --> 00:01:26,880 Hoping it works when you need it. 31 00:01:26,880 --> 00:01:30,720 Behind the scenes, Azure backup uses something called an agent for most workloads. 32 00:01:30,720 --> 00:01:33,440 It's a small piece of software that installs on your machines, 33 00:01:33,440 --> 00:01:35,760 whether they're in Azure or sitting in your office. 34 00:01:35,760 --> 00:01:39,400 That agent coordinates the backup process, telling Azure when to take a snapshot, 35 00:01:39,400 --> 00:01:41,960 what data has changed, and where to send the copy. 36 00:01:41,960 --> 00:01:43,000 Now, here's the thing. 37 00:01:43,000 --> 00:01:46,080 You don't have to install anything manually for Azure virtual machines. 38 00:01:46,080 --> 00:01:48,280 When you enable backup on a VM through the portal, 39 00:01:48,280 --> 00:01:50,720 Azure installs that extension automatically. 40 00:01:50,720 --> 00:01:51,960 One click and it's done. 41 00:01:51,960 --> 00:01:53,760 Azure backup is really a managed service. 42 00:01:53,760 --> 00:01:56,560 You define the policy, it handles the execution. 43 00:01:56,560 --> 00:01:59,320 No backup server to patch, no storage array to expand, 44 00:01:59,320 --> 00:02:01,920 and no wondering if you're weak and full backup actually ran. 45 00:02:01,920 --> 00:02:03,560 But what exactly can you backup? 46 00:02:03,560 --> 00:02:05,160 That's what we'll look at next. 47 00:02:05,160 --> 00:02:06,680 What Azure backup protects? 48 00:02:06,680 --> 00:02:08,560 So what can you actually backup with Azure backup? 49 00:02:08,560 --> 00:02:09,800 Let's go through the main workloads. 50 00:02:09,800 --> 00:02:12,160 Azure VMs are the most common use case by far. 51 00:02:12,160 --> 00:02:13,840 You enable backup on a virtual machine, 52 00:02:13,840 --> 00:02:15,360 and Azure takes a full copy of it, 53 00:02:15,360 --> 00:02:18,960 including the operating system, the applications, and the data disks. 54 00:02:18,960 --> 00:02:21,800 If that VM gets corrupted or accidentally deleted, 55 00:02:21,800 --> 00:02:23,800 you can restore the entire thing from your backup, 56 00:02:23,800 --> 00:02:26,240 and that's the safety net for your compute workloads. 57 00:02:26,240 --> 00:02:27,640 VMs are just a start though. 58 00:02:27,640 --> 00:02:29,880 What about the databases running inside those VMs? 59 00:02:29,880 --> 00:02:32,800 SQL Server and SAP HANA aren't just files on a disk. 60 00:02:32,800 --> 00:02:34,880 They have complex structures, transaction logs, 61 00:02:34,880 --> 00:02:36,720 and specific recovery requirements. 62 00:02:36,720 --> 00:02:38,400 And as your backup understands that, 63 00:02:38,400 --> 00:02:41,280 when you backup a SQL Server database running in an Azure VM, 64 00:02:41,280 --> 00:02:43,040 as your backup coordinates with SQL 65 00:02:43,040 --> 00:02:45,400 to make sure the backup is application consistent, 66 00:02:45,400 --> 00:02:46,640 that means when you restore, 67 00:02:46,640 --> 00:02:49,000 the database comes back clean with no corruption, 68 00:02:49,000 --> 00:02:51,000 no missing transactions and no surprises. 69 00:02:51,000 --> 00:02:52,800 You can even set recovery point objectives 70 00:02:52,800 --> 00:02:55,640 as low as 15 minutes for your most critical databases. 71 00:02:55,640 --> 00:02:57,600 Here's something a lot of people don't realize, 72 00:02:57,600 --> 00:03:00,280 Azure backup isn't just for things running inside Azure. 73 00:03:00,280 --> 00:03:02,320 It can also backup on premises servers, 74 00:03:02,320 --> 00:03:04,480 physical machines, VMware virtual machines. 75 00:03:04,480 --> 00:03:06,080 You send their backups directly to Azure 76 00:03:06,080 --> 00:03:09,080 using the Microsoft Azure backup server or the Mars agent. 77 00:03:09,080 --> 00:03:10,720 That means you can retire your tape library 78 00:03:10,720 --> 00:03:12,720 and use Azure as your off-site storage 79 00:03:12,720 --> 00:03:15,000 with no more shipping hard drives to evolve somewhere. 80 00:03:15,000 --> 00:03:16,760 Azure file shares are another workload. 81 00:03:16,760 --> 00:03:19,520 Think of them as cloud-based shared folders, 82 00:03:19,520 --> 00:03:21,840 the kind your team uses to collaborate on documents. 83 00:03:21,840 --> 00:03:23,440 Azure backup protects those file shares, 84 00:03:23,440 --> 00:03:25,280 so if someone accidentally deletes a folder 85 00:03:25,280 --> 00:03:27,480 or a ransomware attack encrypts your files, 86 00:03:27,480 --> 00:03:29,400 you can roll back to a clean version. 87 00:03:29,400 --> 00:03:31,800 Azure blobs cover your unstructured data. 88 00:03:31,800 --> 00:03:33,960 Images, logs, backups of other systems. 89 00:03:33,960 --> 00:03:36,240 Azure backup can protect your blob containers too. 90 00:03:36,240 --> 00:03:37,760 And then there are Azure disks. 91 00:03:37,760 --> 00:03:40,360 Sometimes you don't need to back up the entire VM. 92 00:03:40,360 --> 00:03:42,680 Maybe you just need to protect a specific data disk. 93 00:03:42,680 --> 00:03:44,360 Azure backup supports that as well. 94 00:03:44,360 --> 00:03:45,600 Here's a real world scenario. 95 00:03:45,600 --> 00:03:48,080 Imagine a company running their infrastructure in Azure 96 00:03:48,080 --> 00:03:50,960 with a few production VMs, SQL server databases 97 00:03:50,960 --> 00:03:52,600 for their line of business applications, 98 00:03:52,600 --> 00:03:55,120 and an old file server still sitting in their office 99 00:03:55,120 --> 00:03:57,200 that they haven't migrated yet. 100 00:03:57,200 --> 00:03:59,680 With Azure backup, they protect all of it from one vault. 101 00:03:59,680 --> 00:04:02,400 The VMs, the databases, the on-prem file server, 102 00:04:02,400 --> 00:04:04,440 one backup strategy, one place to manage it, 103 00:04:04,440 --> 00:04:05,840 one set of policies. 104 00:04:05,840 --> 00:04:07,400 That's the power of a unified platform. 105 00:04:07,400 --> 00:04:09,160 So Azure backup supports a lot, 106 00:04:09,160 --> 00:04:11,720 but the real question is, how does it actually work? 107 00:04:11,720 --> 00:04:14,440 Let's find out how backup actually works, 108 00:04:14,440 --> 00:04:15,920 the two-phase process. 109 00:04:15,920 --> 00:04:18,200 When a backup triggers, two things happen. 110 00:04:18,200 --> 00:04:20,040 And understanding this distinction is the key 111 00:04:20,040 --> 00:04:23,000 to knowing why Azure backup is both fast and safe. 112 00:04:23,000 --> 00:04:25,240 Phase one is the snapshot. 113 00:04:25,240 --> 00:04:28,920 Azure takes a point in time, read only copy of your data. 114 00:04:28,920 --> 00:04:31,840 For a virtual machine, that means it captures the state 115 00:04:31,840 --> 00:04:33,560 of the disks at that exact moment. 116 00:04:33,560 --> 00:04:35,760 This happens quickly because it's a snapshot. 117 00:04:35,760 --> 00:04:38,440 It's not copying every byte of data yet. 118 00:04:38,440 --> 00:04:40,000 Think of it more like taking a photograph. 119 00:04:40,000 --> 00:04:43,040 The snapshot is stored locally, right alongside your VM, 120 00:04:43,040 --> 00:04:45,280 so it's available for fast recovery. 121 00:04:45,280 --> 00:04:47,400 Phase two is the transfer to the vault. 122 00:04:47,400 --> 00:04:50,240 That snapshot data gets moved to your recovery services vault 123 00:04:50,240 --> 00:04:52,640 or backup vault for long term storage. 124 00:04:52,640 --> 00:04:54,800 This takes longer because the data is actually being copied 125 00:04:54,800 --> 00:04:57,080 and transferred, but it gives you that off-site safety. 126 00:04:57,080 --> 00:04:59,120 If your entire Azure region goes down, 127 00:04:59,120 --> 00:05:01,600 your backup data is safe inside the vault. 128 00:05:01,600 --> 00:05:04,720 This two-phase approach makes instant restore possible. 129 00:05:04,720 --> 00:05:07,560 Because the snapshot is stored locally, you can restore a VM 130 00:05:07,560 --> 00:05:10,360 from the last few days worth of snapshots almost immediately 131 00:05:10,360 --> 00:05:12,600 without waiting for data to come back from the vault. 132 00:05:12,600 --> 00:05:13,840 For older recovery points 133 00:05:13,840 --> 00:05:15,600 that have already been moved to the vault, 134 00:05:15,600 --> 00:05:18,360 the restore takes longer, but the data is still there. 135 00:05:18,360 --> 00:05:21,000 After the first backup, things get even more efficient. 136 00:05:21,000 --> 00:05:23,360 Azure backup uses incremental backups. 137 00:05:23,360 --> 00:05:26,200 After the initial full backup, only the changes get sent, 138 00:05:26,200 --> 00:05:27,960 not the entire VM each time. 139 00:05:27,960 --> 00:05:31,040 If you change a few files, only those change blocks are transferred, 140 00:05:31,040 --> 00:05:33,480 which saves both time and storage space. 141 00:05:33,480 --> 00:05:34,880 Policies control everything. 142 00:05:34,880 --> 00:05:37,640 You define the frequency like daily, hourly or weekly. 143 00:05:37,640 --> 00:05:40,120 You define the retention like how many days, weeks, months, 144 00:05:40,120 --> 00:05:42,160 or years to keep each recovery point. 145 00:05:42,160 --> 00:05:44,960 And you define when to move older backups to call that cheaper storage, 146 00:05:44,960 --> 00:05:47,760 a typical policy might back up a VM once daily, 147 00:05:47,760 --> 00:05:49,680 keep the last 30 daily points, 148 00:05:49,680 --> 00:05:52,280 and move anything older than that to the archive tier, 149 00:05:52,280 --> 00:05:54,200 where it costs a fraction to store. 150 00:05:54,200 --> 00:05:55,200 Here's a concrete example. 151 00:05:55,200 --> 00:05:58,040 Say you have a production VM running a web application, 152 00:05:58,040 --> 00:06:01,120 and you set a policy that backs it up every night at 2am. 153 00:06:01,120 --> 00:06:05,040 You keep 30 daily backups, and also 12 monthly backups for compliance. 154 00:06:05,040 --> 00:06:07,280 After the first full backup, every subsequent backup 155 00:06:07,280 --> 00:06:08,520 only transfers the changes. 156 00:06:08,520 --> 00:06:10,280 If your VM has 100 GB of data, 157 00:06:10,280 --> 00:06:14,000 but only changes 2 GB per day, each nightly backup is roughly 2 GB. 158 00:06:14,000 --> 00:06:15,320 That's efficient. 159 00:06:15,320 --> 00:06:17,360 Now you know the mechanics, but there's one thing 160 00:06:17,360 --> 00:06:19,840 that makes Azure backup different from everything else. 161 00:06:19,840 --> 00:06:21,880 How secure it actually is. 162 00:06:21,880 --> 00:06:24,600 The security layer, why Azure backup is hard to attack? 163 00:06:24,600 --> 00:06:27,240 Let's talk security because this is where Azure backup really stands 164 00:06:27,240 --> 00:06:29,000 apart from the old way of doing things. 165 00:06:29,000 --> 00:06:31,600 Every backup you create gets encrypted by default. 166 00:06:31,600 --> 00:06:35,720 At rest inside the vault, it uses AES 256-bit encryption. 167 00:06:35,720 --> 00:06:37,240 That's the industry standard. 168 00:06:37,240 --> 00:06:39,040 While data moves from your machine to the vault, 169 00:06:39,040 --> 00:06:42,680 it's protected with HTTPS and TLS 1.2 or higher. 170 00:06:42,680 --> 00:06:45,440 Even if someone grabbed the data stream, they couldn't read a thing. 171 00:06:45,440 --> 00:06:46,800 But that's just the starting point. 172 00:06:46,800 --> 00:06:48,520 Every backup tool does encryption. 173 00:06:48,520 --> 00:06:50,680 What makes Azure backup different is what happens 174 00:06:50,680 --> 00:06:52,400 when someone tries to delete your backups. 175 00:06:52,400 --> 00:06:53,520 First, there's soft delete. 176 00:06:53,520 --> 00:06:56,760 If a backup gets deleted accidentally or on purpose, it doesn't vanish. 177 00:06:56,760 --> 00:06:58,800 It stays hidden inside the vault for 14 days. 178 00:06:58,800 --> 00:07:00,040 You can recover it. 179 00:07:00,040 --> 00:07:01,920 That gives you a chance to undo the damage 180 00:07:01,920 --> 00:07:03,320 before it becomes permanent. 181 00:07:03,320 --> 00:07:05,640 Think of it like a trash can with a recovery period. 182 00:07:05,640 --> 00:07:07,000 You still have the option to empty it, 183 00:07:07,000 --> 00:07:09,560 but you have to explicitly confirm that you want to, 184 00:07:09,560 --> 00:07:10,760 then you have immutability. 185 00:07:10,760 --> 00:07:12,040 And this is a bigger deal. 186 00:07:12,040 --> 00:07:14,160 Once you set a retention period for a backup, 187 00:07:14,160 --> 00:07:16,440 that recovery point cannot be deleted early. 188 00:07:16,440 --> 00:07:18,960 Not by an administrator, not by someone who compromises 189 00:07:18,960 --> 00:07:19,880 an admin account. 190 00:07:19,880 --> 00:07:21,080 Not even by Microsoft. 191 00:07:21,080 --> 00:07:24,040 The data stays until the retention period expires. 192 00:07:24,040 --> 00:07:24,640 Period. 193 00:07:24,640 --> 00:07:27,120 If your policy says keep daily backups for 30 days, 194 00:07:27,120 --> 00:07:30,120 every single one of those 30 recovery points is locked tight. 195 00:07:30,120 --> 00:07:32,280 An attacker could delete your production VMs, 196 00:07:32,280 --> 00:07:34,240 but they cannot touch the backup data. 197 00:07:34,240 --> 00:07:35,800 Now here's where it gets interesting. 198 00:07:35,800 --> 00:07:38,920 Azure backup supports something called multi-user authorization 199 00:07:38,920 --> 00:07:39,800 or MUA. 200 00:07:39,800 --> 00:07:42,640 Critical operations like disabling soft delete 201 00:07:42,640 --> 00:07:47,080 or turning off immutability require approval from two separate people. 202 00:07:47,080 --> 00:07:49,040 One person cannot compromise the backup. 203 00:07:49,040 --> 00:07:50,160 Not even a global admin. 204 00:07:50,160 --> 00:07:52,200 You need two authorized users to agree 205 00:07:52,200 --> 00:07:53,800 before those security settings change. 206 00:07:53,800 --> 00:07:56,160 That's a serious defense against insider threats. 207 00:07:56,160 --> 00:07:58,560 For organizations with strict network rules, 208 00:07:58,560 --> 00:08:01,440 you can use private endpoints that roots all backup traffic 209 00:08:01,440 --> 00:08:04,640 through your Azure virtual network using private IP addresses. 210 00:08:04,640 --> 00:08:06,640 The data never touches the public internet. 211 00:08:06,640 --> 00:08:09,240 If your compliance team demands network isolation, 212 00:08:09,240 --> 00:08:10,320 this is how you get it. 213 00:08:10,320 --> 00:08:12,920 But here's the real evolution that most people don't know about. 214 00:08:12,920 --> 00:08:15,920 Azure backup now integrates with Microsoft Defender for Cloud. 215 00:08:15,920 --> 00:08:18,160 That means your backup restore points can be scanned for malware 216 00:08:18,160 --> 00:08:19,440 before you restore them. 217 00:08:19,440 --> 00:08:22,000 Imagine a ransomware attack hits your company. 218 00:08:22,000 --> 00:08:23,800 Your production systems are encrypted. 219 00:08:23,800 --> 00:08:25,320 You plan to restore from backup. 220 00:08:25,320 --> 00:08:27,480 But what if the backup itself contains malware? 221 00:08:27,480 --> 00:08:28,880 That's the nightmare scenario. 222 00:08:28,880 --> 00:08:30,000 With this integration, 223 00:08:30,000 --> 00:08:31,960 Defender scans your restore points and flags 224 00:08:31,960 --> 00:08:33,600 any that show signs of infection. 225 00:08:33,600 --> 00:08:35,240 You can then choose a clean recovery point 226 00:08:35,240 --> 00:08:36,880 instead of restoring the problem. 227 00:08:36,880 --> 00:08:38,040 In a real ransomware attack, 228 00:08:38,040 --> 00:08:40,560 attackers almost always try to delete backups first. 229 00:08:40,560 --> 00:08:41,600 That's their playbook. 230 00:08:41,600 --> 00:08:43,080 Immutability stops that. 231 00:08:43,080 --> 00:08:45,160 MUA prevents a single compromised account 232 00:08:45,160 --> 00:08:46,680 from disabling protection. 233 00:08:46,680 --> 00:08:48,680 Soft delete gives you a recovery window 234 00:08:48,680 --> 00:08:51,720 and Defender scanning ensures the data you restore is actually clean. 235 00:08:51,720 --> 00:08:53,120 So as your backup is secure, 236 00:08:53,120 --> 00:08:56,040 but how does it compare to the tools you might already be using? 237 00:08:56,040 --> 00:08:58,240 As your backup versus the alternatives, 238 00:08:58,240 --> 00:09:00,760 let's talk about alternatives because you have options. 239 00:09:00,760 --> 00:09:02,760 And the right choice depends on your situation. 240 00:09:02,760 --> 00:09:06,240 Traditional on-premises backup is what most companies have done for decades. 241 00:09:06,240 --> 00:09:08,640 You buy a backup server, you buy storage, 242 00:09:08,640 --> 00:09:10,200 you buy backup software licenses, 243 00:09:10,200 --> 00:09:12,240 you manage tape rotations or disc arrays, 244 00:09:12,240 --> 00:09:13,960 you handle off-site storage yourself. 245 00:09:13,960 --> 00:09:15,800 The upfront cost is significant. 246 00:09:15,800 --> 00:09:18,760 Servers, storage, software, and the people to run it. 247 00:09:18,760 --> 00:09:21,800 And you have to refresh that hardware every three to five years. 248 00:09:21,800 --> 00:09:23,640 The operational overhead adds up fast. 249 00:09:23,640 --> 00:09:25,960 As your backup flips that model, you pay a subscription. 250 00:09:25,960 --> 00:09:28,880 No hardware, no software to install on a backup server, 251 00:09:28,880 --> 00:09:29,680 no tapes. 252 00:09:29,680 --> 00:09:32,640 The cost is predictable and scales with what you actually protect. 253 00:09:32,640 --> 00:09:34,560 Then there are third party tools like Veeam. 254 00:09:34,560 --> 00:09:36,080 Veeam is excellent at what it does. 255 00:09:36,080 --> 00:09:37,680 It supports complex environments, 256 00:09:37,680 --> 00:09:39,720 multi-cloud, hybrid, on-prem, and cloud, 257 00:09:39,720 --> 00:09:41,120 advanced recovery scenarios. 258 00:09:41,120 --> 00:09:43,200 It offers features like instant Veeam recovery 259 00:09:43,200 --> 00:09:44,880 and deep ransomware defenses. 260 00:09:44,880 --> 00:09:46,800 If your environment is a mix of Azure, 261 00:09:46,800 --> 00:09:48,920 on-prem, Veeamware, and even AWS, 262 00:09:48,920 --> 00:09:51,480 Veeam gives you a single platform to manage all of it. 263 00:09:51,480 --> 00:09:52,440 That's powerful. 264 00:09:52,440 --> 00:09:53,440 But there's a trade-off. 265 00:09:53,440 --> 00:09:56,040 Veeam is more expensive, especially at smaller scales. 266 00:09:56,040 --> 00:09:59,080 A small Azure Veeam with 50 gigabytes of disc costs 267 00:09:59,080 --> 00:10:01,560 about $10 a month with Azure backup. 268 00:10:01,560 --> 00:10:03,360 The same protection with a third party tool 269 00:10:03,360 --> 00:10:04,960 could be two to three times that. 270 00:10:04,960 --> 00:10:07,000 And you still need to manage the backup infrastructure, 271 00:10:07,000 --> 00:10:09,680 the Veeam server, the repositories, the proxies. 272 00:10:09,680 --> 00:10:11,480 So where does Azure backup win? 273 00:10:11,480 --> 00:10:12,760 Simplicity and integration. 274 00:10:12,760 --> 00:10:13,880 It's built into Azure. 275 00:10:13,880 --> 00:10:15,520 You don't provision a backup server. 276 00:10:15,520 --> 00:10:17,160 You don't manage separate storage. 277 00:10:17,160 --> 00:10:19,160 You set policies from the Azure portal 278 00:10:19,160 --> 00:10:21,560 that works with your existing Azure RBAC roles. 279 00:10:21,560 --> 00:10:23,600 It integrates with Azure Policy for governance 280 00:10:23,600 --> 00:10:25,200 for a pure Azure environment. 281 00:10:25,200 --> 00:10:27,480 It's the most cost-effective and simplest option. 282 00:10:27,480 --> 00:10:29,200 Where do third party tools win? 283 00:10:29,200 --> 00:10:30,320 Complex environments. 284 00:10:30,320 --> 00:10:32,360 If you have workloads across multiple clouds 285 00:10:32,360 --> 00:10:34,320 or a significant on-prem footprint, 286 00:10:34,320 --> 00:10:36,400 a tool like Veeam justifies its cost 287 00:10:36,400 --> 00:10:38,240 by giving you unified management. 288 00:10:38,240 --> 00:10:40,960 And for organizations with stringent ransomware requirements, 289 00:10:40,960 --> 00:10:43,920 third party tools often offer deeper immutability 290 00:10:43,920 --> 00:10:45,560 and air-gabbed architectures. 291 00:10:45,560 --> 00:10:46,760 The honest take is this. 292 00:10:46,760 --> 00:10:48,680 If your workloads are primarily in Azure, 293 00:10:48,680 --> 00:10:50,040 start with Azure backup. 294 00:10:50,040 --> 00:10:53,000 It's simple, cost-effective, and deeply integrated. 295 00:10:53,000 --> 00:10:54,360 If your environment is complex, 296 00:10:54,360 --> 00:10:57,360 multi-cloud, heavy on-prem, or requiring advanced DR, 297 00:10:57,360 --> 00:10:59,040 evaluate third party tools. 298 00:10:59,040 --> 00:11:01,560 They cost more but deliver more in those scenarios. 299 00:11:01,560 --> 00:11:03,600 You've seen what it protects and how it works. 300 00:11:03,600 --> 00:11:06,120 But let's talk about the part nobody wants to discuss. 301 00:11:06,120 --> 00:11:07,960 What does it cost? 302 00:11:07,960 --> 00:11:09,400 The cost of Azure backup. 303 00:11:09,400 --> 00:11:10,600 Let's talk money. 304 00:11:10,600 --> 00:11:12,640 Azure backup uses a two-part pricing model 305 00:11:12,640 --> 00:11:14,080 and it's pretty straightforward. 306 00:11:14,080 --> 00:11:16,520 You pay an instance fee for each protected resource, 307 00:11:16,520 --> 00:11:18,600 plus a storage cost for the vault itself, 308 00:11:18,600 --> 00:11:21,400 the instance fee scales with the size of what you're protecting. 309 00:11:21,400 --> 00:11:24,440 A small Veeam under 50 gigabytes, that's about $5 a month. 310 00:11:24,440 --> 00:11:28,080 A medium Veeam up to 500 gigabytes runs around $10. 311 00:11:28,080 --> 00:11:31,320 For databases like SQL Server, the per instance fee is higher. 312 00:11:31,320 --> 00:11:34,760 Roughly $30 a month for a database under 500 gigabytes. 313 00:11:34,760 --> 00:11:38,640 Storage cost depends on how redundant you want your backups to be. 314 00:11:38,640 --> 00:11:42,120 Locally redundant storage or LRS is the cheapest option. 315 00:11:42,120 --> 00:11:44,280 Your backup data gets replicated three times 316 00:11:44,280 --> 00:11:45,960 inside a single data center. 317 00:11:45,960 --> 00:11:49,320 Georeadundant storage or GRS replicates your data 318 00:11:49,320 --> 00:11:52,120 to a paired region in a different geographic location. 319 00:11:52,120 --> 00:11:54,720 That protects you if an entire Azure region goes down. 320 00:11:54,720 --> 00:11:57,240 It also costs about twice as much as LRS. 321 00:11:57,240 --> 00:11:59,000 Here's a real world example. 322 00:11:59,000 --> 00:12:02,480 Say you have a 200 gigabyte Veeam with LRS storage. 323 00:12:02,480 --> 00:12:05,200 Your total cost, instance fee plus storage, 324 00:12:05,200 --> 00:12:07,520 runs roughly $15 to $20 per month. 325 00:12:07,520 --> 00:12:12,520 For a 10Veeam environment, you're looking at about $150 to $250 a month. 326 00:12:12,520 --> 00:12:14,760 Compare that to buying a dedicated backup server, 327 00:12:14,760 --> 00:12:16,760 storage array and software licenses, 328 00:12:16,760 --> 00:12:19,760 and suddenly the cloud option starts looking very reasonable. 329 00:12:19,760 --> 00:12:21,200 But there are ways to save money. 330 00:12:21,200 --> 00:12:22,720 Selective disk backup is a big one. 331 00:12:22,720 --> 00:12:26,120 If your Veeam has multiple disks but only two hold critical data, 332 00:12:26,120 --> 00:12:27,440 you can exclude the rest. 333 00:12:27,440 --> 00:12:29,720 Fewer disks backed up means lower instance fees 334 00:12:29,720 --> 00:12:31,360 and less storage consumed. 335 00:12:31,360 --> 00:12:32,800 Enhanced policy is another lever. 336 00:12:32,800 --> 00:12:34,600 Instead of taking daily full backups, 337 00:12:34,600 --> 00:12:37,400 you can use a policy that takes more frequent incremental backups 338 00:12:37,400 --> 00:12:38,480 and fewer full ones. 339 00:12:38,480 --> 00:12:39,880 The first backup is always full. 340 00:12:39,880 --> 00:12:42,720 After that, only changes our transfer over time 341 00:12:42,720 --> 00:12:45,320 that dramatically reduces storage consumption. 342 00:12:45,320 --> 00:12:48,160 The archive tier is where long term retention gets cheap. 343 00:12:48,160 --> 00:12:49,840 If you need to keep backups for years, 344 00:12:49,840 --> 00:12:51,720 for compliance or regulatory reasons, 345 00:12:51,720 --> 00:12:53,960 moving older recovery points to the archive tier 346 00:12:53,960 --> 00:12:57,160 can be 10 times cheaper than keeping them in standard storage. 347 00:12:57,160 --> 00:12:58,880 The tradeoff is slower restore times, 348 00:12:58,880 --> 00:13:01,400 but for data you almost never access, that's fine. 349 00:13:01,400 --> 00:13:03,360 Reserve capacity is available too. 350 00:13:03,360 --> 00:13:05,760 If you commit to a predictable volume of backup storage 351 00:13:05,760 --> 00:13:06,960 for one or three years, 352 00:13:06,960 --> 00:13:10,360 you can get up to a 40% discount compared to pay as you go. 353 00:13:10,360 --> 00:13:11,960 The hidden risk is over retention. 354 00:13:11,960 --> 00:13:14,080 It's easy to set a policy that keeps seven years 355 00:13:14,080 --> 00:13:15,880 of daily backups for everything. 356 00:13:15,880 --> 00:13:17,400 But most of that data is never needed. 357 00:13:17,400 --> 00:13:19,600 You only need long retention for compliance data. 358 00:13:19,600 --> 00:13:22,760 Everything else can be trimmed, review your policies regularly. 359 00:13:22,760 --> 00:13:24,880 If a workload changed from production to dev, 360 00:13:24,880 --> 00:13:25,960 adjust its retention. 361 00:13:25,960 --> 00:13:28,720 If a VM was decommissioned, remove its backup items. 362 00:13:28,720 --> 00:13:31,560 Every recovery point you don't need is money you're burning. 363 00:13:31,560 --> 00:13:32,720 Now that you know what it costs, 364 00:13:32,720 --> 00:13:34,640 let's talk about the biggest pitfall 365 00:13:34,640 --> 00:13:35,760 and how to avoid it. 366 00:13:35,760 --> 00:13:39,760 The biggest mistake, not testing your backups. 367 00:13:39,760 --> 00:13:42,480 Here's a hard truth that most organizations learn the hard way. 368 00:13:42,480 --> 00:13:44,880 The only good backup is one you've actually restored 369 00:13:44,880 --> 00:13:45,720 and validated. 370 00:13:45,720 --> 00:13:48,160 People get really good at backing up every day. 371 00:13:48,160 --> 00:13:50,440 They configure policies, they monitor jobs, 372 00:13:50,440 --> 00:13:53,560 they feel great when the dashboard shows all green checkmarks. 373 00:13:53,560 --> 00:13:55,640 But they almost never practice restoring 374 00:13:55,640 --> 00:13:57,480 and that's where the disaster happens. 375 00:13:57,480 --> 00:13:58,800 When a real incident strikes, 376 00:13:58,800 --> 00:14:00,800 a corrupted database, a ransomware attack, 377 00:14:00,800 --> 00:14:03,320 an accidental deletion, you discover the truth. 378 00:14:03,320 --> 00:14:04,760 Maybe the backup was corrupt, 379 00:14:04,760 --> 00:14:06,200 maybe the wrong data was captured, 380 00:14:06,200 --> 00:14:08,480 maybe the restore process fails halfway through. 381 00:14:08,480 --> 00:14:09,880 You don't know until you try 382 00:14:09,880 --> 00:14:12,280 and by then production is down in the clock is ticking. 383 00:14:12,280 --> 00:14:14,440 Common pitfalls are surprisingly predictable, 384 00:14:14,440 --> 00:14:17,400 restoring the entire server when you only needed the database, 385 00:14:17,400 --> 00:14:18,840 restoring the VM but forgetting 386 00:14:18,840 --> 00:14:21,320 that applications need to be reconfigured afterward. 387 00:14:21,320 --> 00:14:22,520 Restoring to a different network 388 00:14:22,520 --> 00:14:25,160 and discovering the IP addresses don't match. 389 00:14:25,160 --> 00:14:26,120 These are the kind of problems 390 00:14:26,120 --> 00:14:28,840 that turn a recovery operation into a multi-day crisis. 391 00:14:28,840 --> 00:14:30,760 The fix is simple but uncomfortable. 392 00:14:30,760 --> 00:14:33,920 Schedule regular restore drills, quarterly is a good cadence. 393 00:14:33,920 --> 00:14:37,120 Pick a test VM, restore it from backup, verify the data is intact, 394 00:14:37,120 --> 00:14:39,640 check that applications start properly then deleted. 395 00:14:39,640 --> 00:14:41,200 The first time will take longer, 396 00:14:41,200 --> 00:14:42,600 the second time will be faster. 397 00:14:42,600 --> 00:14:46,080 By the third drill, your team will have a documented repeatable process 398 00:14:46,080 --> 00:14:48,520 as your backup makes this easier than it sounds. 399 00:14:48,520 --> 00:14:50,960 The instant restore feature lets you restore 400 00:14:50,960 --> 00:14:52,760 from a local snapshot almost immediately. 401 00:14:52,760 --> 00:14:55,040 You don't have to wait for data to come back from the vault. 402 00:14:55,040 --> 00:14:58,080 You can spin up a restored VM, verify it and tear it down 403 00:14:58,080 --> 00:14:59,120 in under an hour. 404 00:14:59,120 --> 00:15:00,600 The takeaway is blunt but necessary. 405 00:15:00,600 --> 00:15:04,080 A backup strategy without a restore test is just an expensive hope. 406 00:15:04,080 --> 00:15:06,800 You're paying for protection, you haven't confirmed works. 407 00:15:06,800 --> 00:15:09,400 Schedule your first drill this month, not next quarter, 408 00:15:09,400 --> 00:15:12,760 this month, getting started, your first three steps. 409 00:15:12,760 --> 00:15:15,240 You need to test your backup, but where do you begin? 410 00:15:15,240 --> 00:15:17,360 Let me walk you through three simple steps. 411 00:15:17,360 --> 00:15:20,040 Step one, figure out what you can't afford to lose. 412 00:15:20,040 --> 00:15:23,240 Your critical VMs, your databases, your file shares, 413 00:15:23,240 --> 00:15:25,120 don't try to backup everything at once. 414 00:15:25,120 --> 00:15:27,960 Start with the workload that would hurt most if it disappeared. 415 00:15:27,960 --> 00:15:29,200 That's your top priority. 416 00:15:29,200 --> 00:15:31,760 Step two, create a recovery services vault. 417 00:15:31,760 --> 00:15:33,200 Think of it as a safe for your backups, 418 00:15:33,200 --> 00:15:36,560 make sure you create it in the same region as your resources. 419 00:15:36,560 --> 00:15:38,200 That's the number one mistake people make. 420 00:15:38,200 --> 00:15:39,800 The vault ends up in the wrong region. 421 00:15:39,800 --> 00:15:41,240 If your VM runs in West Europe, 422 00:15:41,240 --> 00:15:44,040 your vault must be in West Europe too, keep them together. 423 00:15:44,040 --> 00:15:46,280 Step three, set your backup policy. 424 00:15:46,280 --> 00:15:47,880 How often should backups run? 425 00:15:47,880 --> 00:15:49,640 Daily is standard, how long should you keep them? 426 00:15:49,640 --> 00:15:51,480 30 to 90 days is a good starting point. 427 00:15:51,480 --> 00:15:52,600 What about redundancy? 428 00:15:52,600 --> 00:15:55,400 LRS keeps copies in one data center and saves money. 429 00:15:55,400 --> 00:15:58,160 GRS copies to a second region for extra safety. 430 00:15:58,160 --> 00:16:01,080 Once your policy is ready, enable backup on your first VM. 431 00:16:01,080 --> 00:16:03,400 Azure backup installs the extension automatically. 432 00:16:03,400 --> 00:16:06,280 Start with one VM, confirm the first backup completes, 433 00:16:06,280 --> 00:16:07,560 then expand from there. 434 00:16:07,560 --> 00:16:10,960 Azure backup center gives you one dashboard to monitor everything. 435 00:16:10,960 --> 00:16:11,880 So that's Azure backup. 436 00:16:11,880 --> 00:16:13,160 It's not just a backup tool. 437 00:16:13,160 --> 00:16:14,920 It's a safety net you set once and trust. 438 00:16:14,920 --> 00:16:18,160 You don't need tapes or servers and you never have to wonder if it worked. 439 00:16:18,160 --> 00:16:21,360 You set your policy, you enable protection, you test your restore. 440 00:16:21,360 --> 00:16:24,080 Simple, start with your most critical VM this week. 441 00:16:24,080 --> 00:16:26,800 That one step already puts you ahead of most organizations. 442 00:16:26,800 --> 00:16:29,080 Subscribe for more plain English Cloud breakdowns.