After my previous post on LAN-Free backups for VMware vSphere, here’s the (somewhat) corresponding post for Microsoft Hyper-V environments. The Background is the same, so you can skip that part if you already read the vSphere post 😉

Generally, when designing backup infrastructures, it is preferable to set up a direct connection between the data mover (“Backup Server” or “Proxy”, in Veeam terminology) and the production storage where your data resides. This is commonly referred to as “LAN-Free” configuration, because the backup traffic does not impact on your LAN. Actually, what I described is only half of the job: a direct access to the production storage ensures LAN-Free read operations – to obtain a real 100% LAN-Free backup, also the target storage (“Repository” in Veeam terms) must be directly connected.As you might already know, Veeam Backup & Replication supports both VMware vSphere and Microsoft Hyper-V environments. The backup and recovery mechanics are quite different between the two hypervisors, as well as the steps needed to configure a LAN-Free backup. The post about configuring LAN-Free backup for vSphere environments can be found here.

Veeam B&R has a “modular” architecture that allows a wide variety of choices for deployment. The building blocks of the Veeam B&R infrastructure are: Enterprise Manager, Backup Server, Proxy, Repository, WAN Accelerator. Their roles are detailed in the diagram below.

It should be noted that by default, when you install Veeam Backup & Replication, the backup server is automatically configured as a VMware backup proxy and a repository. So it is perfectly possible to have a single machine holding all roles, if you use on-host proxies for Hyper-V – this is of course suggested only in small environments.The good thing about this approach is that you can grow and scale as you like, plus you can easily adapt the backup/replication infrastructure to your needs, for example if you have a distributed infrastructure among different sites.

In Hyper-V environments, all Veeam backup operations are carried out leveraging the VSS framework and the Hyper-V VSS components. For a quick overview on how VSS works in Hyper-V environments, you can check out this video by Chris Henley or this whitepaper by Greg Shields (which also covers VSS for guest VMs in vSphere, by the way). Also of interest is this post by Rick Vanover on the Veeam blog.

Starting with Hyper-V / Windows Server 2012 it is possible to store VMs on SMB 3.0 shares. The backup mechanisms in this case are slightly different than those pertaining VMs on local storage or Cluster Shared Volumes (CSVs). In this article I’ll focus on the latter scenario, but if you’re interested in SMB 3.0-specific VM backup configuration, you can find more information in the Veeam B&R Help Center.

If you are already familiar with vSphere agentless, image-based backup methods, you will find some differences in Hyper-V… and I’ve got both good and bad news for you.

The good news is that there is no equivalent of the network transport mode: all backups, at least for the reading part, are always performed with a direct connection to the shared storage.

The bad news is that… there is no equivalent of the network transport mode 😉 By default, the Hyper-V hosts themselves are used as proxies (“on-host proxies”), with an unavoidable – but controllable – impact on their performance.

… But wait! It is possible to set up so-called “Off-host” backup proxies. Unlike their vSphere counterparts, they have some fairly specific requirements, but they can give you great benefits since the transport process is offloaded and performed at the SAN layer. The resource-intensive tasks will be performed by the off-host proxy, so there will be no impact on production hosts.

To create an off-host backup proxy, the designated machine must:

1. Be a physical machine. Well, to be really honest, it IS possible to set up a VM as an off-host backup proxy, but it is absolutely not recommended. Microsoft doesn’t support this scenario and you’ll more than likely run into issues, at least performance-wise. So, don’t say I didn’t warn you 😉
2. Be a Windows Server 2008 R2, 2012 or 2012 R2 machine, with the Hyper-V role enabled. The hypervisor itself isn’t really needed, but some very important VSS components are. The off-host proxy OS version must match that of the host(s) you’ll back up VMs from.
3. Be connected to the shared storage and access the volumes you’ll be backing up VMs from. Seems obvious, right? 🙂
4. Have a working and configured VSS hardware provider for the shared storage you’ll be backing up VMs from. Transportable volume shadow copies are only supported with hardware VSS providers. The necessary software normally can be downloaded from your storage vendor’s website.
5. NOT be part of a cluster. It may sound counterintuitive, but it is mandatory! The snapshot of the LUN containing the VMs to be backed up will have the same ID of the original LUN, so very nasty things will happen to the cluster during backup or replication if the off-host proxy takes part in it.

To add a Hyper-V off-host backup proxy you need to select the “Backup Proxies” section in the “Backup Infrastructure” and right-click it (or select the “Add proxy” button in the ribbon interface).

Veeam B&R automatically scans the infrastructure (once every 24 hours) and detects which volumes each proxy has access to. But while it is not always required, you might need to set advanced options for your off-host proxies, to manually specify connected volumes.

The off-host backup process itself is quite simple: the volume snapshot is created and mounted on the off-host proxy, where the Veeam transport service retrieves VM data and processes it. After the operation is completed, the snapshot is dismounted and deleted. Easy, huh?

The following diagram, taken from Veeam’s Help Center (where you’ll also find a ton of useful information and resources), visually explains the process:

As stated in the initial “background” section, to have a fully LAN-Free backup environment you have to set up a direct connection from the backup proxy to the backup repository, without the production LAN involved (the “grey arrow” in the diagram above).

For example, you could configure your off-host proxy also as a repository, effectively keeping the backup traffic within itself. Or you could have the off-host proxy use either local or SAN/NAS storage (not connected through the production LAN) to store backups.

You can check out if your backup job used off-host proxies and if everything is configured correctly in the job statistics.

You should see snapshots being created via hardware VSS providers on off-host proxies. Also, for each VM disk that was backed up, Veeam B&R reports the proxy it used.

That’s all guys, hope you find this post useful!

As usual, any feedback is welcome.