When it comes to backup efficiency and copying only the needed data between a full backup and any incremental backups, changed block tracking technology is critical. We are very familiar with this in the VMware backup world as we have changed block tracking for a while now. However, with Hyper-V changed, block tracking is a technology that has not been around as long. It wasn’t until Windows Server 2016 that this functionality was built-in natively. Before 2016, Microsoft had some filter driver magic 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 essential, 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 should be an incremental backup of that virtual machine. We don’t want it to be necessary to copy data 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. The changed tracking information on the next backup cycle shows 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 the 2011 era), this is a new technology in the Hyper-V world. 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. This 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 select Double-check changed blocks provided by RCT. As the bubble tip notes, this will result in long job runs but additional verification of change tracking between backup cycles.
backup-job-hyper-v
double-check-changed-block
Hyper-V RCT Built for Resiliency
The resilient change tracking references Hyper-V’s ability 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. Two files 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 a “.vhdx*” file created for the disk as well as the “.mrt” and “.rct” files. If you don’t see these files created during the backup operation, you have not initiated a Resilient Change Tracking backup operation. You have likely selected a proprietary backup solution filter driver-enabled backup operation.
Hyper-V RCT Built for Resiliency
After the checkpoint has been rolled off and the backup job finishes, we are left with the “.vhdx,” “.mrt,” and “.rct” files.
vhdx, mrt and rct files
What is each of the above files used for?
The RCT or Resilient Change Tracking file is the most detailed representation of changes blocked on disk (less detailed than mapping in memory). It is written in write back or cached mode, used during normal virtual machine operations such as migrations, startups, shutdowns, etc.
The MRT or Modified Region Table file is less granular, written in write-through mode, and less granular than the RCT file. However, it records all the changes on the 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 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 recent 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.
Thoughts
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 concerning 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.
Top comments (0)