1
00:00:01,240 --> 00:00:03,010
There are three consistency levels.

2
00:00:03,010 --> 00:00:06,770
These basically turn out to be service‑level agreement guarantees for

3
00:00:06,770 --> 00:00:12,380
Microsoft. The one that you want is application consistent, and this is for

4
00:00:12,380 --> 00:00:18,420
Windows virtual machines when the Volume Shadow Copy writer is able to back

5
00:00:18,420 --> 00:00:22,980
up all of the still content, that is closed files, but also in‑memory

6
00:00:22,980 --> 00:00:25,610
content and pending I/O operations.

7
00:00:25,610 --> 00:00:31,440
Now Linux, of course, doesn't have Volume Shadow Copy, but you can mimic

8
00:00:31,440 --> 00:00:36,260
that behavior by injecting scripts into your backup process, and there's

9
00:00:36,260 --> 00:00:38,770
a good Microsoft Docs article on that.

10
00:00:38,770 --> 00:00:42,080
If you search Google for application‑consistent backups

11
00:00:42,080 --> 00:00:44,390
in Linux Azure VMs, you'll find it.

12
00:00:44,390 --> 00:00:46,730
You can also check the exercise files for this

13
00:00:46,730 --> 00:00:48,490
course. It'd probably a bit easier.

14
00:00:48,490 --> 00:00:52,650
But this is definitely the preferred consistency level because the SLA,

15
00:00:52,650 --> 00:00:57,070
or the contractual agreement, is that Microsoft says when you restore an

16
00:00:57,070 --> 00:01:01,240
application‑consistent snapshot, that VM will not only boot, but you can

17
00:01:01,240 --> 00:01:04,770
get right back to the memory content and pending I/O at the time the

18
00:01:04,770 --> 00:01:09,410
backup was taken. The second most preferable consistency level is called

19
00:01:09,410 --> 00:01:10,350
file‑system.

20
00:01:10,350 --> 00:01:14,640
This is the default consistency for Linux VMs if you're not using those

21
00:01:14,640 --> 00:01:19,180
scripts. The issue here is that it may require some data to fix up. In other

22
00:01:19,180 --> 00:01:23,510
words, on your Windows VM, maybe there was a problem with the VSS writer, with

23
00:01:23,510 --> 00:01:28,310
the Volume Shadow Copy writer. It wasn't able to capture all pending I/O and

24
00:01:28,310 --> 00:01:33,030
in‑memory content, so your restored disk and VM will boot, but you may have a

25
00:01:33,030 --> 00:01:34,940
little bit more work to do.

26
00:01:34,940 --> 00:01:39,270
And lastly, there's the crash‑consistent snapshot, and you

27
00:01:39,270 --> 00:01:43,580
don't want this because this consistency level has no SLA,

28
00:01:43,580 --> 00:01:45,640
or service‑level agreement.

29
00:01:45,640 --> 00:01:50,090
However, this doesn't mean necessarily that it's a bad backup.

30
00:01:50,090 --> 00:01:54,710
It's just that either there was a more intense problem during the backup if

31
00:01:54,710 --> 00:01:59,650
the Azure VM was online at the time of the backup, but just as commonly, if

32
00:01:59,650 --> 00:02:04,300
the virtual machine has stopped and deallocated, crash is the only consistency

33
00:02:04,300 --> 00:02:08,710
level you can get because how in the world can the Volume Shadow Copy service

34
00:02:08,710 --> 00:02:17,000
or the Linux equivalent work if the virtual machine has stopped and deallocated? Short answer, it can't.