Changed Block Tracking
When Veeam Backup & Replication performs incremental backup, it needs to know what data blocks have changed since the previous job session. To get the list of changed data blocks, Veeam Backup & Replication uses the changed block tracking mechanism, or CBT. CBT increases the speed and efficiency of incremental backups.
Veeam Backup & Replication uses CBT for the following operations:
- Entire VM restore
Veeam Backup & Replication enables CBT. You can disable it either at the host level or at the job level for troubleshooting purposes. Note that if you choose to run incremental jobs with CBT disabled, the backup window may increase dramatically, as Veeam Backup & Replication will read all VM data to detect what blocks have changed since the last job session.
To keep track of changed data blocks, Veeam Backup & Replication uses the following mechanisms:
- [For VMs on Microsoft Hyper-V Servers 2012 R2 and earlier] Veeam proprietary changed block tracking mechanism (CBT)
- [For VMs on Microsoft Hyper-V Server 2016 and later] Resilient Changed Tracking
The CBT mechanism is implemented as a file system filter driver — Veeam CBT driver. The driver is installed on every Microsoft Hyper-V host added to the backup infrastructure. The driver is activated when the host is first addressed by a job for which CBT is enabled.
The Veeam CBT driver keeps track of changed data blocks in virtual disks. Information about changed data blocks is registered in special CTP files. When a job runs, Veeam Backup & Replication uses CTP files to find out what data blocks have changed since the last run of the job, and copies only changed data blocks from the disk image.
CTP files are stored in the C:\ProgramData\Veeam\CtpStore folder on standalone Microsoft Hyper-V hosts or on every node of the Microsoft Hyper-V cluster. The CtpStore folder contains a set of subfolders — one for every processed VM, in which the following files are stored:
- CTP files. These files are used by the Veeam CBT driver to keep track of changed data blocks. For every VHD/VHDX or AVHD/AVHDX file of a VM, there is a separate CTP file.
- notes.txt file. This file contains basic information about the VM such as VM name and ID, and describes for which VHD/VHDX files changed block tracking is enabled.
If a Microsoft Hyper-V VM is registered as a cluster resource, the Veeam CBT driver operates on all cluster nodes that have access to VM disks on the CSV. When a job runs, Veeam Backup & Replication copies CTP files to the temporary folder on the backup proxy used by the backup job.
- If backup or replication is performed in the on-host backup mode, CTP files are copied to the Microsoft Hyper-V host performing the role of the on-host backup proxy. For more information, see On-Host Backup.
- If backup is performed in the off-host backup mode, CTP files are copied to the off-host backup proxy. For more information, see Off-Host Backup.
If you process VMs on a Microsoft Hyper-V cluster, make sure that all cluster nodes are online. If cluster nodes are in the Maintenance mode, have the cluster service stopped, are powered off or not accessible, CBT will not work. For more information about other requirements for VMs on clusters and SMB3 storage, see this Veeam KB article.
For VMs running on Microsoft Hyper-V Server 2016 or later, Veeam Backup & Replication uses Resilient Change Tracking, or RCT. RCT is a native Microsoft Hyper-V mechanism for changed block tracking in virtual hard disks of VMs.
- VMs run on Microsoft Hyper-V Server 2016 or later.
- [For Microsoft Hyper-V clusters] All hosts in the cluster are upgraded to Microsoft Hyper-V Server 2016 or later, and the cluster functional level is upgraded to 2016. If at least one node in a cluster is not upgraded to Microsoft Hyper-V Server 2016 or later, Veeam Backup & Replication does not use changed block tracking.
- VM configuration version is upgraded to 8.x.
For backup and replication with RCT, Veeam Backup & Replication uses the following mechanism:
- Veeam Backup & Replication triggers Microsoft Hyper-V to create a checkpoint for a processed VM. The checkpoint is used as a data source for backup and replication.
- At the end of VM processing, before a checkpoint is merged with the base VM disk, Microsoft Hyper-V converts the checkpoint to a reference point. The reference point can be thought of as a point-in-time representation of the VM disk state.
- When Veeam Backup & Replication performs incremental backup or replication, it creates a new checkpoint for the VM that is used as a data source. Veeam Backup & Replication queries Microsoft Hyper-V to get incremental changes between the reference point created during the previous job session and checkpoint created during the current job session.
- Veeam Backup & Replication copies only changed data blocks from the created checkpoint and saves them in an incremental backup file.
To guarantee persistence of CBT data, Microsoft RCT maintains 3 bitmaps with CBT data:
- In-memory bitmap contains the most granular CBT data.
- RCT file contains less granular CBT data than the in-memory bitmap. The RCT file is used if the CBT data in the in-memory bitmap is not available during normal operational situations, for example, a VM is moved to another host.
- MRT file has the coarsest granularity level. The MRT file is used if the CBT data in the in-memory bitmap is not available during abnormal operational situations, for example, power loss or host crash.
RCT and MRT files are created for every VM disk and stored at the VM disk level.
CBT Reset (Microsoft Hyper-V Server 2012 R2 and Earlier)
In some cases, CBT data may get corrupted — as a result, Veeam Backup & Replication will fail to process VMs with changed block tracking. To reset CBT data for individual VMs or specific VHD/VHDX files, you can use the Reset-HvVmChangeTracking PowerShell cmdlet. For more information, see the Veeam PowerShell Reference.
Note that CBT data is reset when you perform product upgrade. When you run a backup job for the first time after upgrade, Veeam Backup & Replication will not use changed block tracking. Instead, it will scan the VM image to learn what data blocks have changed.