Thanks again. I guess we'll have to weigh the trade-offs internally, and decide if it's better to automatically backup-up the added VMs twice or to not back them up at all, if and when somebody forgets to do all the necessary backup job management. Hopefully with so few VMs to keep track of, we'll manage not to screw up.Hi everybody, we are getting ready to deploy our first Veeam backup installation in the next weeks, and I have a few questions about some configuration details that I couldn't quite figure out from reading the user manual and the forums. We will have a two-node Hyper-V WS2012 cluster, with 8 VMs stored on a SAS SAN, and a few Synology units as iSCSI backup targets. We intend to run Veeam in one of the VMs, and give it and the two cluster hosts access to the backup iSCSI LUNs - if I understood correctly, this is both supported as well as recommended for best performance, and Veeam will orchestrate the access to the LUNs between the backup server VM and the hosts as needed during backup.
But upon further reading of the manuals and forums, I think that I still have some question on the basic architecture, because I suspect that my understanding on how the backup repositories are managed was quite a bit flawed. My goal is to implement a backup system that does as much as possible in parallel, because we have multiple iSCSI targets, which are in themselves relatively slow, and at the same time lots of data to backup. As far as I can see, I have two main options for this (and please correct me if I am wrong):
Mount each one of the two iSCSI LUNs to each of the cluster nodes, and then add the cluster nodes themselves as backup repositories as well. This would make the backup jobs completely LAN-free with the data flow from the SAN to the host and then to the iSCSI target for each of the cluster nodes. The Veeam B&R VM would only do job scheduling & coordination, so it doesn't need to see the iSCSI LUNs, and it also doesn't need too many vCPUs, because the actual CPU intensive workload will be on the two hosts, right?
Main disadvantage I can see is that since each one of iSCSI LUNs is mapped to respectively only one of the hosts, in the case one host goes down, so will one backup repository, making the job fail.
Mount one of the iSCSI LUNs directly to the Veeam B&R VM, and create another backup repository VM where the other iSCSI LUN is mounted. Make sure these two VMs normally run on different cluster nodes, to balance the performance / iSCSI traffic. This would ensure that even in the case of a cluster node going down, both backup repositories would still be available (but with some resource contention).
Main disadvantage would be that the backups are now no longer LAN-free, right? Meaning the hosts would still do the heavy-lifting, reading in on-host proxy mode from the SAN and doing compression and deduplication, then send the data to the two VMs, which in turn will just write it out to the iSCSI LUNs. Second small disadvantage would be the additional resources (vCPUs and a WS2012 license) for the VM that will only function als backup repository.
Am I missing something obvious on how we could better implement this?