At InterOp this week, the point really came home to me again that most people are simply confused about how the snapshot capability works with image-based protection. It's kind of hard to appreciate the value and benefits of an image-based data protection solution like vRanger Pro unless you understand how well it is designed to work with the VM image. So, let me take a few minutes to describe how this operates and hopefully clear up some of the confusion.
I find that pictures really help, so here is my offering:
This picture illustrates the entire process of how vRanger Pro initiates, executes, and transmits a backup of a VM image on VMware systems. I'll describe the entire process and how it works in a future blog entry. For now, focus on the snapshot process which happens on the VMware system.
Here's how it works:
1) VMware uses a snapshot process to release the VMDK file for the VM so that it can be read by the vRanger Pro backup process. This happens immediately and quickly, because the snapshot is not a mirror. There is no need to wait for a mirror to be written. There is no need to find duplicate disk space for a mirror.
2) The VMDK file is then available for backup. vRanger Pro reads out the blocks required for the backup, depending on whether the backup is a full, incremental or differential. The blocks read also depend on other capabilities of vRanger Pro which may be enabled, including Active Block Mapping and Change Block Tracking.
3) During backup, end-users and applications can still operate. VMware enables this by holding any new writes in a temporary location until the backup is complete, and the VMDK file is once again available for use.
4) When the backup is complete, VMware releases the snapshot - and resolves any changes held in the cache location by updating the affected blocks in the VMDK.
A common misconception is that an image-based backup is a snapshot. There is another misconception, which is that the backup is made from a snapshot copy of the VMDK image. Neither is correct. The image backup copy is a block-by-block read from the VM file. However, the backup gains these advantages from the fact that VMware releases its VMDK file through a snapshot mechanism:
In short, the snapshot mechanism is a key advantage that helps to make Backup 2.0 image-based data collection less disruptive, more reliable, faster, and more resource-efficient than traditional methods.
Taking it a Bit Deeper for Those Who Care
On a VMware system, when a snapshot is created a number of files are created in the directory for that virtual machine:
When a backup process starts it begins by requesting the VMware system to take a snapshot through the VMware API. The virtual machine is put into read-only state and a snapshot (or delta file since storage has a different definition for snapshots) is created. This delta file collects changes to the virtual machine which are written from the end-users and applications during the backup process. Once the backup is complete, the VMware system merges the delta file to update the virtual machine to a current processing state. The detal file is then discarded.
Having snapshots open and growing is a bad thing for resources on production systems, which is why the Vizioncore data protection products including vRanger Pro and vReplicator are all optimized to reduce the time that snapshots are open.