All who have been vSphere administrators for any amount of time will tell you, snapshots for the most part are evil! However, snapshots play a vital role in most vSphere infrastructures. When using them as designed and in a way that is not meant to be a permanent fixture on a virtual machine, they can be a great tool when used properly. It is important to realize that while VMware snapshots are not backups in and of themselves (never look at them as such!), they do play a vital role in taking backups of virtual machines when used by most VMware backup solutions out there today. Let’s take a look and see how VMware backup uses snapshots to allow data to be successfully backed up and data to be flushed appropriately.
VMware Snapshot Best Practices
Before we delve into the realm of how VMware backup uses snapshots, let’s take a look at a few VMware snapshot best practices to cover the bases a bit. In case you didn’t know, VMware has a great KB article that lays out the best practices for using VMware snapshots: https://kb.vmware.com/s/article/1025279.
A few of the notables:
- Snapshots are not backups!
- Snapshot disks are only “delta” of the base disk. In other words if the base disk is deleted, the snapshot (erroneously viewed backup) is no longer good enough to restore any data.
- While 32 snapshots per VM is a supported maximum, VMware recommends that no more than 2 or 3 snapshots exist on a virtual machine.
- Snapshots should be viewed as short term mechanisms. Do not leave a snapshot in place for more than 72 hours.
- Snapshots are thin provisioned disks that grow in size. They can potentially fill up an entire LUN if left in place unchecked.
- If using backup software that utilizes snapshots, make sure to check for orphaned snapshots. This can happen if communication is somehow broken on a backup run and the command to delete the snapshot was not received.
- You can’t increase the size of a virtual disk that has a snapshot in place
How VMware Backup Uses Snapshots
So how do VMware backup solutions use snapshots? If snapshots are not backups, isn’t it counter intuitive to use them in any kind of backup process? The way most VMware backkup solutions use snapshots is in a safe way and the snapshot is created for a purpose. What purpose?
Generally, the first step that a VMware backup solution does is take a snapshot of the running virtual machine that is included in the backup job. This serves a few purposes.
- Flush application aware data from memory to disk
- Redirect virtual disk writes/changes to the delta disk
- Provides a way to record any changes during backup
Flushing Application Data from Memory to Disk
When taking snapshots, VMware backup solutions utilize the snapshot creation process that is equivalent to the Quiesce guest file system (Needs VMware Tools installed) option that you find when you manually create a snapshot on a VM. Using this type of snapshot allows VMware backup solutions to leverage VMware Tools to quiesce the file system in the virtual machine. Quiescing the file system brings the on-disk data into a state that is suitable for backup. This includes flushing in memory buffers, etc. VMware backup’s can go further and use application aware processes with hooks into Microsoft VSS that allow bringing all application data into a consistent state such as Microsoft Exchange Server or Microsoft SQL Server. This ensures application consistency. Note the option below to Quiece guest file system using VMware Tools.
Note how if we choose the Snapshot the virtual machine’s memory option the option to Quiesce guest file system is greyed out. Why is this? Well, because quiescing is not necessary for memory snapshots since the in memory buffers, etc will be intact with the memory snapshot.
Below, we have an example of a backup solution taking a snapshot after the backup process starts running on a virtual machine. Note, most VMware backup solutions will note in the snapshot name, the snapshot is “temporary”.
Redirect virtual disk writes/changes to the delta disk
The next purpose for creating the snapshot is so the virtual disk writes and changes are redirected to the delta disk. If you try to simply copy a virtual disk from a datastore browser, you will note an error stating the file is in use. To get around this problem, VMware backup solutions create the snapshot to redirect the writes and changes to the delta disk. A delta disk is created for every disk that is assigned to the virtual machine. Once the snapshot disk is created, the VM virtual disks are place in a read-only state so they can be copied down by the VMware backup solution. Any changes that are made to the virtual machine are recorded in the delta disk(s).
Changed Block Tracking, introduced with vsphere 4.X, is typically used and for good reason. CBT allows a way for only the changes between backups to be copied over. The CBT file that is created maps out the blocks in the VMDK that have changed. VMware backup solutions can read the CBT file and know exactly which blocks of data to copy over. This makes the backup of the virtual machine MUCH more efficient.
Below, we see a delta virtual disk highlighted in red and the changed block tracking file in yellow.
After, the backup job has completed, which generally is a quick process once the first full backup has been taken and changed block tracking is used on subsequent runs, the snapshot created for backup purposes is then deleted.
For the most part, snapshots can be a bad thing. However, generally it is because they are being used in a way they were never designed to be used. Hopefully, this short primer on how VMware backup uses snapshots helps show that snapshots are a good thing when used in the right way and can bring many benefits to VMware backup. Without the snapshot, many things that are now possible with hot VM backups might not be as easy or even possible at all without a different technology to bring the same advantages the snapshots bring to VMware backup.