July 19, 2017
VM backup with Hyper-V Changed Block Tracking (CBT)
When it comes to backup efficiency and copying only the data that is needed between a full backup and any incremental backups, changed block tracking technology is extremely important. We are very familiar with this in the VMware backup world as we have had changed block tracking for a while now. However, with Hyper-V changed block tracking is a technology that has not been around as long. In fact, it wasn’t until Windows Server 2016 that this functionality was built-in natively. Previous to 2016 Microsoft had some filter driver magic that happened with DPM and other solutions. Microsoft calls their CBT technology Resilient Change Tracking or RCT for short. Why is Changed Block Tracking essential for backup solutions? How is Microsoft’s Resilient Change Tracking implemented? Let’s take a look at this technology in Windows Server 2016.
Why is Hyper-V Changed Block Tracking Important?
Let us take a step back for a moment and examine why changed block tracking is important especially in the backup world. In the context of a virtualized environment, when we perform a full backup, we have a complete representation of that virtual machine block by block. The next backup that happens should be an incremental backup of that virtual machine. We don’t want it to be necessary to copy data that we have already copied to our backup repository. We only want the changed information. It would be extremely inefficient to copy the same data over and over if we already have that data in our backup repository. So, in steps changed block tracking. Changed block tracking creates a mapping of all the blocks of data used by a virtual machine. On the next backup cycle, the changed tracking information knows which blocks have changed since the last backup. Only those changed blocks are copied in the subsequent backup cycles.
While this technology has been around in the VMware world since around ESX/ESXi 4.0 and virtual machine version 7 and higher (around 2011 era), in the Hyper-V world this is a new technology. It wasn’t until the introduction of Resilient Change Tracking in Windows Server 2016 that we now have a viable way to keep track of these changed blocks in the Hyper-V world. Before 2016, Hyper-V change tracking was accomplished by proprietary filter drivers implemented by backup vendors that allowed it to create the change tracking needed to efficiently copy only changed blocks in Hyper-V virtual machines. In Nakivo Backup & Replication v7.1 you see the options for Change Tracking set to use Hyper-V RCT. Also, in the settings configuration for Change Tracking, you can also select to Double-check changed blocks provided by RCT. As the bubble tip notes, this will result in long job runs but results in additional verification of change tracking between backup cycles.
Hyper-V RCT Built for Resiliency
The resilient change tracking references Hyper-V’s ability to be able to keep track of changes even if we have a hard crash or unexpected power off of the virtual machine. Windows Server 2016 Hyper-V accomplishes this by implementing three change tracking files – (1) in memory and (2) on disk. This way if the above mentioned dirty shutdown or power off happens and the changed tracking in memory is lost, we still have the changed tracking on disk. There are two files that get created when the first full backup of a Windows Server 2016 Hyper-V is taken.
During the checkpoint creation process during the backup, you will also see an “.vhdx*” file created for the disk as well as the “.mrt” and “.rct” files. If during the backup operation, you don’t see these files created, then you have not initiated a Resilient Change Tracking backup operation. Most likely you have selected a proprietary backup solution filter driver enabled backup operation.
After the checkpoint has been rolled off and the backup job finishes, we are left with the “.vhdx” “.mrt” and “.rct” files.
What are each of the above files used for?
- The RCT or Resilient Change Tracking file is the most detailed representation of changed blocked on disk (less detailed than mapping in memory). It is written to in write back or cached mode which means that it is used during normal virtual machine operations such as migrations, startups, and shutdowns, etc.
- The MRT or Modified Region Table file is less granular and is written to in write through mode and is less granular than the RCT file, however, records all the changes on disk. If something happens – crash, power failure, etc, the MRT file will be used to reconstruct the changed blocks. This will save a tremendous amount of time and data efficiency since we still are much better off than having to go back to square one and pull a full backup of the virtual machine.
Why Do We Need Files Living on Disk for Change Tracking?
The memory mapping of changed blocks that is kept is only good for the virtual machine as long as it lives on the same host. If that host crashes or the virtual machine is migrated to a new host, the in memory changed blocks mapping is lost. As shown above, Windows Server 2016 resilient change tracking with the new RCT and MRT files resolves this issue as the changed block tracking is persisted to disk and can be referenced without dependencies on the computer and memory resources that own the virtual machine.
Microsoft is slowly but surely filling in the gaps in technology between other hypervisors such as VMware and itself when it comes to Hyper-V. Windows Server 2016 has proven to be vastly superior to previous versions of Windows in regards to Hyper-V and other related technologies. With the introduction of Resilient Change Tracking, backup vendors can now rely on the built-in technology to provide change tracking of blocks used by virtual machines between a full backup and the subsequent incremental backups. This will result in faster and more efficient backup operations as vendors no longer have to rely on proprietary filter drivers to keep track of change tracking.