Link Menu Expand (external link) Document Search Copy Copied

Interaction with Hyper-V

Change Block Tracking

Hyper-V 2016 and newer is recommended from a backup pespective. Since Hyper-V 2016 there is native change block tracking available. It is known as “Resilient Change Tracking” (RCT).

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 (introduced with Hyper-V 2016) will change the behavior of the checkpoint creation process as part of a Veeam backup: Even if the Veeam backup job is configured with guest processing disabled, the production checkpoint creation process will perform in-guest VSS snapshots for each VM in the job. Veeam triggers these checkpoints with the VSS_BT_FULL method by default to make sure all applications will be in a consistent state. Please note that this is different from Hyper-V’s default creation process of production checkpoints, e.g. via Hyper-V Manager, where the VSS_BT_COPY method is used instead. A description of these VSS methods can be found in this Microsoft documentation.

Why is this difference important? If you are protecting VMs running database servers (e.g. MS SQL) using this configuration, it leads to the situation that transaction logs will be truncated as a part of this production checkpoint creation! So you have to make sure that this truncation does not interfere with any other log processing you implement outside Veeam (see also Hyper-V Settings page of the user guide).

The HyperV2016VSSCopyOnly registry key controls this behavior:

Path HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Key Name HyperV2016VSSCopyOnly
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


Back to top

Copyright © 2023 Solutions Architects, Veeam Software.