Azure Backup - Simply Explained

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.