Been on VMware for a while, new to Hyper-V

[JoshRountree]

I've been on VMware for a while, but will probably be making the move to Hyper-V soon. I've been testing out how Veeam backs up Hyper-V and comparing it to VMware. I'll add my notes. I would like for someone to confirm/deny my findings and hopefully give me some pointers. Thanks!

-When you add a Hyper-V cluster, you just add the failover cluster virtual network name account - I guess this is similar to adding VCenter so you can discover all the hosts in the cluster?

-When using VMware I would install a Veeam virtual machine and it would reconfigure this server and "hot-add" disks to it for backup. On Hyper-V it appears that a virtual machine proxy isn't needed, the Veeam physical server talks directly to the cluster hosts?


Anything else I'm missing?

[alanbolte]

There isn't any direct equivalent to a vCenter; backup by cluster and backup by SCVMM both have certain similarities to vCenter when compared to backup through the individual host. I generally find that adding clusters to the backup infrastructure works best in small to medium environments; adding SCVMM to Veeam can make more sense in enterprise environments. One big difference here is CBT - if a VM is a cluster resource, CBT won't work if you try to back up through the host instead of the cluster, and can fail if there's a problem with any node in the cluster.

You're right that there's no equivalent to the SAN/Hotadd/NBD transport mode concept, nor to the idea of deploying VM proxies. Usually your hosts will act as proxies (meaning that we run data movers on the host to read and compress the VM data), although with some kinds of shared storage you can set up "off-host" proxies.

Low-level backup procedure is very different, but suffice to say that we're using volume shadows on the host rather than using snapshots (checkpoints). However, if you look closely you'll notice that VSS will automatically create and delete checkpoints - this works differently in each OS version. I guess the closest equivalent in our VMware backup options would be backup from storage snapshots.

Application-aware works differently too - our in-guest temporary process doesn't interact directly with in-guest VSS, instead the in-guest VSS is managed directly by the host when we request the host-level shadow copy. There is no VIX equivalent, so AAIP requires a network connection.

Hyper-V quiescence is very different from VMware Tools Quiescence; for VMs that support 'online' backup the only difference between HV quiesce and our AAIP is that with AAIP off, Veeam B&R won't inject a process to gather application and file system data. For VMs that don't support 'online' backup, the results of HV quiesce vary depending on host and guest OS.

There's no such thing as NFS datastores in Hyper-V, so there is no vPower. As a result, Instant Recovery and Surebackup work completely differently (the details are documented in the user guide). This can have some interesting consequences, like this restriction: https://www.veeam.com/kb2028. Also, there's no Surebackup for replicas in Hyper-V.

[JoshRountree]

Wow, very nice synopsis - pretty much detailed the differences. Thank You!!!

[Vitaliy S.]

Just a small tip - when you start deploying Hyper-V infrastructure, make sure it is configured according to these guidelines and best practices > Hyper-V Infrastructure Assessment

[nmdange]

If your environment isn't really small, take a look at using Scale Out File Servers and using SMB as your storage protocol. Also look at network cards that support SMB Direct (made by either Chelsio or Mellanox) which can actually beat both iSCSI and Fiber Channel in performance. You can do off-host backups via SMB with Veeam regardless of the type of backend storage being used. See https://helpcenter.veeam.com/backup/hyp ... ackup.html

[NoGoh]

Hi,

Before you go ahead and deploy, I would recommend you explore and thoroughly understand the differences and benefits between "On-Host" and "Off-Host" Proxies. This is a Hyper-V only feature and will dictate your architecture.

With a Hyper-V Off-host proxy, you require a separate server running the Hyper-V Role but it cannot be a member of the source Hyper-V cluster or a member of a Hyper-V cluster itself. It also needs to be at nearly the same OS patch level (but you cannot have a cluster at SP1 and the off-host proxy not at SP1 and vice versa) else it won't work properly or as expected. Similarly if you upgrade your cluster from 2012 to 2012 R2 or 2016 the off-host proxy needs to be at the same build level as the source cluster. It becomes exceedingly difficult to manage this especially if you need to maintain backup functionality during the upgrade process and you only have resources to deploy one off-host proxy. If you are going through an upgrade process or significant patch cycle then you will need at least two separate off-host proxies. Typically Off-host proxies are physical systems. There is also the issue of the Off-host proxy being able to access the shared storage so that it can access the VM data during backups.

On-Host proxies chew up more resources obviously and can impact the performance of the Hyper-V Cluster node, as they process the backups on the hyper-v host before sending the data to the Veeam Backup server. However you are not restricted to patch level issues and shared storage access. Just remember to add the Hyper-V cluster object name to Veeam and not each individual host and ensure your hyper-v nodes have sufficient resources to support the additional load.

I've only deployed one small Hyper-V cluster (4 nodes at one site 2 at another) without SCVMM and just manage it using the Failover Cluster Manager (FOCM) and Hyper-V Manager (with all the hosts added) and I used on-host proxies with no issues. I initially thought the off-host proxy method would have been ideal but after some discussions at VEEAMON the on-host proxy configuration was recommended. The Veeam Backup Server is a VM and the Repository server is a physical server. Hyper-V Cluster hosts were connected to Nimble iSCSI storage as CSVs not SMB, however if you can, use SMB3.0 if the file storage system supports it.

Also note that when a backup uses CBT for a VM, the data for that CBT resides on the Hyper-V host that the VM resides on and is not shared between hosts unless the VM has moved back to the same host by the next back window. There's a support article about CBT and Hyper-V somewhere which I cannot recall at present.

[JoshRountree]

Thanks for all the replies, I'm not doing the Off-Host Backup Proxy. I just had it in my head that I needed a proxy since I was used to using one with VMware.

We've got a very small cluster (2 nodes) - so I'm going to try and see if FOCM and Hyper-V manager will be sufficient for now.