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 |
| 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