Hyper-V backup modes

Veeam Backup and Replication provides two different backup modes to process Hyper-V backups, both relying on the Microsoft VSS framework.

• On-Host backup mode, for which backup data processing is on the Hyper-V node hosting the VM, leveraging non transportable shadow copies by using software VSS provider.
• Off-Host backup mode, for which backup data processing is offloaded to another non clustered participating Hyper-V node, leveraging transportable shadow copies using Hardware VSS provider provided by the SAN storage vendor.

Backup mode availability is heavily depending on the underlying virtualization infrastructure, leaving Off-Host backup mode available only to protect virtual machines hosted on SAN storage volumes.

Performance wise, since both backup modes are using the exact same Veeam transport services, the only differentiating factors will be the additional time requested to manage transportable snapshots (in favor of On-Host mode) and the balance between compute and backup resources consumption during backup windows (in favor of Off-Host mode).

Backup modes selection matrix

Limiting the impact of On-Host backup mode on the production infrastructure

While consuming production resources for backup purpose the On-Host backup mode disadvantages can be mitigated by the following guidelines.

• Spreading load across hypervisors. It should be kept in mind that the backup load, instead of being carried by a limited number of dedicated proxies, will be spread through all the hypervisors. Default Veeam setting is to limit backup to 4 parallel tasks per hypervisor, which will use a maximum of four cores and 8 GB of RAM. This can be modified in the “Managed server” section of the Veeam Console, through the “Task limit” setting. For instance, if the sizing guidelines (please refer to the resource planning section of this document) results in a total amount of 24 cores and 48 GB of RAM needed for Veeam transport services, and the infrastructure comprises 12 Hyper-V servers, each server task limit can be set to 2.

• Leveraging storage latency control. This feature allows to protect the volumes (globally for enterprise edition, and individually for enterprise plus edition) from high latency, by monitoring and adjusting backup load accordingly. Please refer to user guide proper section for further information.

Change block tracking on Hyper-V

Depending on the combination of Hyper-V OS version and the primary storage type, the mechanism for tracking changes may differ.

Microsoft Resilient Change Tracking in Hyper-V 2016

Before version 2016, Microsoft did not offer native change block tracking leading Veeam to develop a private CBT engine to drastically optimize backups process. In version 2016 of Hyper-V, Microsoft has implemented its own changed block tracking mechanism, named “Resilient Change Tracking”. To benefit RCT, the following prerequisites must be met, otherwise incremental backups or replication will have to read entirely the source virtual disks to recalculate differences:

• Hyper-V server version 2016
• Cluster functional level is upgraded to 2016
• VM configuration version is upgraded to 8.0

Change block tracking on third party SMB implementation

Since Veeam own Change Block Tracking filter driver is not compatible with third party SMB implementations (as sometimes implemented on hyper converged infrastructures) it is advised to upgrade the cluster nodes to Hyper-V 2016 to leverage Microsoft native RCT in such situations.

Mixed clusters and Change Block Tracking

As migrating Hyper-V clusters from 2012 R2 to 2016 can be done using the "rolling procedure" a Hyper-V cluster might temporary run different versions, impacting the CBT mechanism usage.

Backup of Microsoft S2D hyper converged cluster

When configuring a hyper converged infrastructure based on Microsoft Storage Spaces Direct one limitation to know about is that a volume hosting virtual machines is owned by a single node of the cluster at a given time. This implies that all IOs (including backup workload generated by all nodes) will be served by the single node owning the volume.

A good rule of thumb to avoid such potential bottleneck is to create a number of volumes equal or greater than the number of nodes composing the cluster, spreading IOs servicing across all nodes.

Guest interaction

PowerShell Direct

Introduced by Microsoft in Hyper-V 2016, PowerShell Direct is a new method allowing to interact with the guest even if no direct network connection is available between the Veeam guest interaction proxy and the guest itself.

PowerShell Direct requires the following prerequisites:

• PowerShell 2.0 or later
• Host must be Windows Server 2016
• Guest must be Windows Server 2016 or Windows 10

PowerShell Direct can be easily tested on the host, using the following command.

 Enter-PSSession -VMName VMName

Linux Integration Services and application awareness issue

It has sometimes been observed that some Built-in Linux Integration Services versions failed to communicate the guest IP address to the Hypervisor, causing the Veeam application aware processing to fail.

Please refer to the following Technet blogpost for further explanations on where to find and how to install LIS.

Guest restoration

Instant VM recovery storage requirement

When performing Instant VM recovery, Veeam will immediately pre-allocate the necessary amount of storage on the target infrastructure, even though the guest image used is residing on the backup repository.

Note : this pre-allocation is performed only for Instant VM Recovery Usage. Sure Backup processing will use a thin provisioning mechanism instead, preserving resources on the infrastructure.