Veeam Backup Essentials Deployment Advice for 3 Nodes

[Killian]

Hi there,

We're planning to implement Veeam backup essentials to replace a constantly failing and frustrating Microsoft DPM install. I have been reading through the user manual and online videos and had a query about the best deployment in this scenario.

We are a large secondary school and looking to backup somewhere around 30 VMs on a 3 Node Failover Cluster of Hyper-V. We have a suitable server with SAS disks which I plan to install the software on and I've been backwards and forwards as to whether I should install it on a VM on said machine or just have it run on the direct hardware.

A little background on our setup;

The 3 Node Failover Cluster will be deployed in our server room (we are doing this over the coming month). These 3 nodes have a dedicated iSCSI connection to a new Dell SAN SCv2020 (this is a private network and not accessible other than via the dedicated iSCSI ports of the Cluster). The Server with SAS disks (that will act as the Veeam Repository and probably all other components) is in a seperate cabinet connected to a via a team of 4 1Gb connections to a L2 switch and a 10Gb fibre backbone from said switch to the server room. The thinking behind this current setup is if we had a fire or disaster in our server room, the backups are safe on the other side of the school and, as the SAN has it's own backup mechanisms (to a degree), this affectively gives us 2 backups a good distance away. To be clear this isn't going to replace our offsite solution which I'm planning to take a full synthetic backup weekly and upload if possible.

I'd like to continue this setup but unsure of best practice with the various components, would I be better served installing an backup proxy on the failover cluster too, moving the physical Veeam server into the server room, installing hyperv on the veeam server and virtualising the whole install, etc?

I would appreciate any feedback and thoughts people may have.

Thank you.

[nmdange]

With Hyper-V, the backup proxy is either the Hyper-V host itself or another physical server with Hyper-V installed that also has direct access to the storage. For an off-host proxy to work, your SAN storage array needs to have a hardware VSS writer that supports transportable snapshots (or you need to use SMB-based file servers). In your case, I would stick with the default on-host proxy since it's a small environment.

You could run Veeam in a VM on the server with SAS disks (I do this in a much larger environment) but it would work just fine directly on the physical host. Having it in a VM lets you move it around, take VM snapshots for upgrades, etc. but those are just minor advantages. Having everything on the physical server would be the simplest/easiest setup to manage.

[Killian]

Thank you, that makes a little more sense now. I assumed I'd have to connect some other host into the SAN to access the shared storage.

Could I ask in this case, with 3 HyperV Servers making up the cluster, would I need to pick one of them to be the backup proxy or does Veeam put the role on all of the hosts in the cluster and use whoever happens to have the 'vm' at the time of the backup? They're all identical specifications you see so if I could take advantage of all 3 of them that would be ideal. Otherwise I guess I could prioritise 2 as hosts and leave more capacity in terms of RAM and CPU for the backup proxy.

With regards to the Veeam product, I am tempted to do as you say and virtualise it purely for the added protection (snapshots being one of them of course). My only concern is does it have some potential of causing problems with the Microsoft HyperV Layer being relied upon more than it would if it were a physical machine? If not then, as we're already licenced for HyperV and the Server OS, I may aswell just virtualise it for those added benefits.

[nmdange]

When using the on-host proxy, it will be the host that the VM being backed up is running on. So if you have VMs on all 3 hosts being backed up at the same time, all 3 hosts will act as a proxy.

There won't be any functional issues with Veeam running in a VM. Having it as a VM on your production cluster would be a concern in terms of recovering from a full system failure, but a VM on a standalone host won't be a problem for that. You might lose a bit of performance but since the server only has 4x1gb nics and not a 10gb nic it probably won't be noticeable.

[Killian]

I think I'll go down the route of the VM instance on a seperate server in that case.

Thanks again. Your posts were really helpful.