Backup repository architecture for iSCSI targets

[Amyd80]

Since the topic was split, I quote the configuration details from the original topic just to make sure all the relevant infos are here as well:

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.

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.

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):

Option 1:
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.

Option 2:

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?

[Vitaliy S.]

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.

If you have Veeam ONE deployed in your VI, then this shouldn't be a big deal, as you can automatically create report on unprotected VMs in your environment. Please take a look at the report example you can schedule to run once a day, week etc.

I think that option one is preferable, since I do not believe you will have node failures that often. Besides, creating a repository server on a VM will also be a single source of failure, unless you make this repository VM highly available via Failover Cluster snap-in, right?

Anyway, as you've correctly stated, it's the matter of weighing the trade-offs: you will get a simpler architecture if you proceed with option one, while option two will give you more "moving" parts, but better redundancy in case of a disaster.

[Amyd80]

Did you ever consider implementing the option for defining iSCSI LUNs as backup repositories? I can imagine this being relatively useful for scenarios like ours, since the backup job could dynamically mount the iSCSI LUN on the job proxy, back up and dismount it after it is finished, making it no longer dependant on a specific drive on a specific server being available. One could script something like this with PowerShell, but as I understand, there are no pre-backup scripts currently available for Veeam B&R under Hyper-V, right?

This ties in to my next question: as a second-level backup we want to use a portable Synology device which will only be connected for a short time-fenster (kinda like an external HDD, but with far larger capacity). I guess the best way to deal with such a case would be to define it as a CIFS backup repository, but unfortunately we would then run into the ext4 file size limit on the NAS for the multi-terabyte VMs, so it must be used as an a iSCSI target. If we were to create a PS script to mount the iSCSI target & LUN,start a Veeam backup job and then disconnect it upon succesful completion, would this cause any issues when the drive letter is not available for Veeam the rest of the time? Like, are there any periodical scans done by the B&R server if all repositories are available, even when there are no backup jobs?

[Gostev]

there are no pre-backup scripts currently available for Veeam B&R under Hyper-V, right?

No pre-backup scripts, however you can start both pre-backup activities, and the actual job from the same script (and schedule the script with Windows Task Scheduler, instead of scheduling actual job).

Like, are there any periodical scans done by the B&R server if all repositories are available, even when there are no backup jobs?

The B&R monitoring piece in Veeam ONE does this. On B&R side, this should not be causing any issues though.

[Amyd80]

No pre-backup scripts, however you can start both pre-backup activities, and the actual job from the same script (and schedule the script with Windows Task Scheduler, instead of scheduling actual job).

I thought about that option too, actually like mentioned in the previous message I was considering using it for the second level / disaster recovery backup, since that portable iSCSI target will not be available on-site all the time. But for a regular daily backup job, it seems to me to have a pretty important disadvantage, in that restoring files from that backup would still have the dependency on a specific drive mounted on a specific server, or not?

[Gostev]

Moved the description to the first post of the topic.

Yes - and obviously I am not expecting you to mess with backup repository used for primary local backup job. First, there is simply no reason to do this? And second, you always want your primary backup repository to be readily available for restores.

For off-site job, you can always "import" the backup file from any location at all (accessible to backup server), and perform the restore immediately. To do that, just use the "Import Backup" toolbar button, and go from there.

[Amyd80]

Well, the only "reason" (in quotes because I am of course not considering actually implementing this) would be one possible way to try and avoid the problem with the option 1 setup (described above): mounting the LUNs on the hosts themselves and using them as repositories makes the backup jobs dependant on the hosts - if one is down, the backup job targetting it as a repository will fail. As Vitaly says above, this would be exceptional circumstances, and manual intervention would be very likely anyway (cause, host down, omg!), but I am trying to think all scenarios through.

Speaking of which, I don't suppose backing up TO Cluster Shared Volumes is in any way supported, is it? Cause that would be another way to make the backup repositories failover - just mount both iSCSI LUNs on both hosts, and format them as CSVs. Can Veeam use a CSV mount point as a backup repository? Or is this overthinking it way too much?

[Gostev]

Well, why not. Any folder you see in Windows Explorer on your backup repository server can be used as a target for Veeam. If you can write data there with WIndows Explorer, Veeam can write backup files there as well.