Feature Request: Allow multiple transport methods in a job

[splaxco]

We have been running VB&R 9.5 U3 for a few months with no serious issues. Two of our backup jobs, each representing a different VMware cluster, have grown to the point where they need additional proxies to complete active full backups on time. These jobs use shared proxies thus the transport is NBD. I built four additional proxies and moved two of these to each of the affected VMware clusters, then configured the backup jobs to use these proxies. I thought that if the shared proxies were busy then these would be available for hotadd backups.

When the jobs ran that night, they used ONLY the proxies capable of hotadd backups and didn't touch the other proxies, despite them being selected for the backup job and sitting idle for hours. The next day I migrated the four new proxies to a totally different cluster, forcing the jobs to use NBD transport. This time the jobs used all available proxies, but it's annoying that VB&R will use only the most efficient transport available regardless of other available resources. At the very least I would like an explanation why VB&R works this way, and if possible would like to see this changed in a future release.

[foggy]

Hi Steve, here's a brief explanation of why it currently works this way:

The behavior is expected. NBD mode is used to backup a VM only if there is no proxy selected in the job that can backup that VM using one of the other transport modes. Otherwise, Veeam will wait for the proxy with either hotadd or Direct SAN access to the datastore to become available.

My understanding is that this was implemented mainly due to the fact that, when using NBD transport, technically ANY proxy can backup all VMs in the entire infrastructure, which definitely might not be a good thing. If I have a configuration with 2 sites, I don't want the proxy at Site 2 using NBD mode to backup VMs at Site 1, but there's no way for Veeam to know where that physical proxy lives, it could be anywhere in the world. Sure, we could make some assumptions about layer-2 adjacency, and we do check some of that, but even then what we can assume this is quite limited as it wouldn't work in cases of stretched layer-2.

There's some space for improvement here, for example, when proxy affinity is configured, Veeam B&R could rely on this information in proxy selection, so your feature request makes sense. Thanks.

[splaxco]

Thanks for the explanation foggy. I can appreciate why you wouldn't want this as a default setting, but it would be nice to have the choice to use all available transport modes for these jobs. Please discuss this with your team and see if it makes sense to implement.