Interaction with Hyper-V
Change Block Tracking
According to Microsoft’s lifecycle policy, extended support for Hyper-V Server 2012 R2 ended on October 10, 2023. While Veeam continues to support Hyper-V 2012, it is recommended to use Hyper-V 2016 or newer. Hyper-V 2016 introduced a native change block tracking technology known as “Resilient Change Tracking” (RCT), which enhances backup efficiency.
Mixed clusters and Change Block Tracking
As migrating Hyper-V clusters from 2012 R2 to 2016 or higher can be done using the “rolling upgrade” procedure, some Hyper-V cluster nodes might run different versions temporarily, impacting the CBT mechanism usage. Be aware that the transition time you plan for updating the cluster to 2016 or newer should be limited to days.
| Hosts OS | VM Level | Cluster Level | CBT |
|---|---|---|---|
| All 2012 R2 | lower than 8 | lower than 9 | Veeam filter driver |
| Mixed | up to 8 | lower than 9 | No CBT |
| All 2016 or higher | Lower than 8 | 9 or higher | No CBT |
| All 2016 or higher | 8 or higher | 9 or higher | Microsoft RCT |
Backup of Microsoft S2D hyper-converged cluster
For Storage Spaces direct (S2D) Clusters only On-Host proxy mode is available because of the local storage used by S2D.
Note: A cluster shared volume (CSV) hosting virtual machines is owned by one dedicated node of the S2D cluster. VMs can write directly to the CSV from any given host. But any metadata operation, which includes any filesystem based operation like backups and restores, will be served by the single node owning the volume. A rule of thumb to avoid such potential bottleneck is to create a number of CSVs that equals the number of nodes in the cluster (or even 2 times higher) to distribute load.
Considerations when using Production Checkpoints
Be aware that enabling Production Checkpoints will alter the checkpoint creation process during a Veeam backup. Even if the Veeam backup job is configured with guest processing disabled, the production checkpoint creation process will still perform in-guest VSS snapshots for each VM in the job. By default, Veeam triggers these checkpoints using the VSS_BT_FULL method to ensure all applications are in a consistent state. This differs from Hyper-V’s default production checkpoint creation (e.g., via Hyper-V Manager), which uses the VSS_BT_COPY method. For a description of these VSS methods, refer to this Microsoft documentation.
Why is this difference important? When protecting VMs running database servers (e.g., MS SQL) with this configuration, transaction logs will be truncated as part of the production checkpoint creation process. Therefore, it is crucial to ensure that this truncation does not conflict with any other log processing you have implemented outside of Veeam. For more information, refer to the Hyper-V Settings page of the user guide.
The registry key HyperV2016VSSCopyOnly controls this behavior:
| Path | HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication |
| Key Name | HyperV2016VSSCopyOnly |
| Type | REG_DWORD |
| Value |
0 → use VSS_BT_FULL method (default), will lead to transaction log truncation |
1 → use VSS_BT_COPY method; transaction logs will NOT be touched |
References
- Hyper-V Backup Modes
- Veeam Helpcenter - Hyper-V Change Block Tracking
- Rams Tech Blog - Cluster Shared Volumes
- Hyper-V Settings
- Microsoft Docs: VSS Types