Expert analysis | Comprehensive understanding of Azure disk snapshot function

​In the process of using Azure, when you need to press the "shutter", your disk data can also be fully protected, and you can use such a snapshot to restore the disk data to the previous state when necessary.
Azure Disk Snapshot is such a convenient technology, and has even become the basis of data protection services such as Azure Backup. Different from the pointer-based approach of traditional local storage snapshots, Azure Disk Snapshots are more like clones of valid disk data, and their usage methods are also quite different.
The operation of the snapshot is very simple. You can directly create a snapshot by selecting the disk in the management portal interface, but if you study it carefully, there are still many interesting points.

​

Basic concepts of Azure snapshots

Azure disk snapshots are divided into two categories: full volume and incremental. The difference between the two and the pricing method (take the Premium Disk of East America as an example) are as follows:

As can be seen from the description:

• Snapshots are divided into full and incremental;
• Snapshots only support local copy protection: LRS or ZRS (if supported by the region);
• Full snapshots of Premium Disk can be placed in Premium storage or standard storage, and incremental snapshots can only be placed in standard storage (full and incremental snapshots of standard SSD and standard disks can only be placed in standard storage);
• The capacity of the snapshot is determined by the effective amount of data on the disk, not the size of the disk;
• The reference point of a full snapshot is the current disk; the reference point of an incremental snapshot is the last snapshot. It does not matter whether the last snapshot was full or incremental.

Snapshot experiment

Next, we will build a virtual machine to verify the snapshot function.

experimental design:

The virtual machine runs Windows 10, and a 1TB data disk is attached for the snapshot test. The overall process is as follows:

The general experimental process is as follows:

1. First put a 10GB file in the disk and make a full snapshot Snapshot1. Snapshot1 is based on the current effective amount of data on the disk, so the capacity is 10GB;
2. Then make an incremental snapshot Snapshot2. Since the incremental snapshot is based on Snapshot1 and there is no change in the disk, the capacity of Snapshot2 is 0GB;
3. Add a 20GB file to the disk, the effective data volume of the disk becomes 30GB, and make a full snapshot Snapshot3 with a capacity of 30GB;
4. Then do incremental snapshot Snapshot4, the same as the capacity of 0GB;
5. Put a 40GB file on the disk for the third time, the effective disk data volume increased to 70GB, and take incremental snapshot Snapshot5 again. The reference point of this incremental snapshot is the most recent snapshot Snapshot4, so the capacity of Snapshot5 should be 70-30 =40GB.

1. Create a snapshot:

As shown in the figure below, in the data disk (F disk) of the created virtual machine, use the fsutil command to create a 10GB file:

Then do the first full snapshot Snapshot1:

As you can see, because this disk is a Premium SSD, different storage types can be selected for full snapshots. Here, Standard HDD is selected uniformly, and then “Next” is always used to create a snapshot:

Then create an incremental snapshot Snapshot2 of the disk:

Since incremental snapshots only support standard storage (Standard HDD), there is no choice of storage type. The result of the creation is as follows:

Then follow this step to add files and create the remaining snapshots, the list is as follows:

2. Snapshot verification:

Unlike traditional storage snapshots that can be rolled back directly, Azure snapshots must be generated on disk before they can be used. Therefore, we first use Snapshot1 to generate Disk1:

Then use the same steps to create disk Disk2—Disk5 using the next few snapshots:

Since the source of these disks has not been attached to the virtual machine, there is no Owner.

Back to the OS of the virtual machine again, we created three files on the data disk: file01, file02, and file03. According to the time point when the snapshot is created, the files contained in each snapshot are as follows:

Then attach the disk generated from the snapshot to the virtual machine:

And attach these disks (G-K disk) to the OS:

Check the contents of the disk and found that it meets expectations:

Further test

As mentioned above, incremental snapshots are based on the amount of change from the previous snapshot. So what happens if the previous snapshot is deleted? It is still verified through testing.

First delete Snapshot1 (the first full snapshot):

Found that there is no Snapshot1 in the snapshot list:

Use Snapshot2 again to generate Disk 6 and attach it to the virtual machine:

Attach it to the virtual machine (L drive), and then check the contents inside:

It turns out that file01 still exists, and checking the hash shows that its hash value is consistent with the previous file:

It can be seen that even if the snapshot used as the reference point is deleted, the security of the incremental snapshot will not be affected.

About capacity

As mentioned above, the snapshot capacity is determined by the effective amount of data on the disk. For full snapshots, the effective amount of data is relatively easy to confirm; but for incremental snapshots, the use of disks is usually not simply adding files, but a series of operations such as adding, deleting, and modifying. However, Azure snapshots do not provide the capacity query function. The capacity seen here is the capacity of the corresponding disk.

However, we can confirm the snapshot capacity through a workaround, which is to reverse the capacity based on the cost of the snapshot.

To do this, please create a new virtual machine and attach two 1TB data disks:

Enter the OS, create and format the two data disks respectively (F disk and G disk):

Then create a 300GB file on the F disk and G disk respectively, the F disk is created with the fsutil tool that comes with Windows, and the G disk is created with the third-party rdfc tool:

You can see: fsutil creation speed is very fast, while rdfc speed is very slow. The reason is that fsutil will directly fill the generated sparse file with "0", and rdfc will fill it with random numbers, and a file is actually generated. After completion, the occupied space of the two disks is basically the same:

Take full snapshots SnapshotF and SnapshotG for these two disks:

After placing it for two days, check the usage cost of the snapshot. Enter the snapshot Overview, there is a View cost button:

Click to enter and select Daily costs:

It can be seen that the daily cost of G disk snapshot is about $0.19.

Using the same method to view the snapshot cost of Disk F is as follows, which is basically 0:

The comparison shows:

• Although the G disk and F disk occupy basically the same space, the cost of snapshots is quite different. The files on Disk F are basically all filled with "0", and no space is actually occupied when the snapshot is created, so the snapshot does not actually occupy space, and the cost is 0.
• The actual file size of the G disk is 300GB. The theoretical daily cost is $0.05/30*300=$0.50, but the actual cost is $0.19, indicating that a similar compression and deduplication technology is used for snapshot storage to save space.

summary

Snapshot is a very common concept, and there are different mechanisms in the cloud and locally.

Although the operation of snapshots is very simple, if you can master it, you can use them in a wide range of scenarios, such as business upgrades, data updates, etc., you can use snapshots for instant protection; in addition, you can also use snapshots in environments such as environment replication and remote migration of virtual machines. accomplish.

Hope this article is helpful to everyone.