Link Menu Expand (external link) Document Search Copy Copied

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


Back to top

Copyright © 2024 Solutions Architects, Veeam Software.