averylarry wrote:There's no way a sequential method will keep all phases (source, destination, target, CPU, ram, network, WAN) saturated.
Thing is, you do not need to have ALL phases saturated - as soon as the "weakest" phase is saturated, it will become the bottleneck for the job - and as soon as this happens, it no longer matters that other phases are not saturated. Because there is a bottleneck for the job already, it is pointless to start processing of another VM in parallel within the same job.
You are making main assumption, that backup of one machine should saturate at least one phase in any case. That's not right at all. As it was said in low-budget installations you may have the example of different storage targets. In high-budget installations you have storage and network multipathing, many independent datastores (even storage-drs managed in vsphere 5), high performance network and storage which with CBT can even make data transmission time shorter than preparing to backup VM.
When you are trying to prevent saturation for specific phases you use phase-specific concurrency limits - for proxy servers, for repository servers. These methods are already implemented. Really, i was very surprised after reading pre-v6 infos, that backup jobs still runs sequentially. And really disappointed. Even free vmware Data Recovery has concurrency as one of base features.
Nowdays despite of all new features of v6 we still can't optimize performance of backups without splitting jobs - the concurrence features are almost useless.
It's no way to present jobs as method of managing backup queues - any new instance of any object should be created only when it's properties are different from existing ones. For jobs these are storage policies (expiration, incremental/reserve incremental etc), application processing settings, schedule, proxy/destination, all settings you specify when creating the job. There is no reasons to create different jobs with same settings - expect of software limitations, which force you to manually micromanage things that should not require management at all and add a huge overhead when you should continually inspect job logs to distribute VM's.
Traditional backup software sometimes has sequential approach to processing data because of being tape-orientated - and that is not veeam case again.
I usually don't write any suggestions in support forums, as it has a little to no effect, but in case if veeam, which, as i think, is not a very big company, i hope these opinions can somehow reach the decision makers in veeam...