To illustrate the difference between two approaches, consider the following simple Veeam Backup & Replication environment: a single Veeam Backup server, capable of running 8 jobs concurrently, and a single backup job with 4 VMs, each VM having two virtual disks.
•With the Veeam Backup & Replication 6.x architecture, it would not be possible to take full advantage advantages proxy capabilities of this server. The single job would start and work through each VM and each disk on that VM in order, one at a time, using only a single thread, and not even fully using this proxy capability — due to overhead in creating/removing snapshots and other management tasks (when no data processing would be occurring).
•With the version 7 architecture, there is a drastic change in behavior: each VM and each virtual disk from those VMs would be immediately assigned to a proxy, thus taking full advantage of all proxy CPU resources and allowing the backup to complete in the minimum possible time even with a single job.
When the parallel processing option is enabled, Veeam will always attempt to use all available resources as configured for the environment. However, there are many ways to control the total concurrency within the environment — maximum number of concurrent tasks can be configured for each proxy and repository. Recommended number is calculated automatically by Veeam in accordance with the available resources. When configuring this parameter manually, consider that each data processing task requires one CPU core. For instance, a 2-core CPU (minimum recommended for a proxy) can handle two concurrent tasks. If the specified number of tasks is exceeded, the backup proxy will not start a new task until one of the current tasks is finished.
Also, when entering the number of concurrent tasks, you should keep in mind the network traffic throughput in your virtual infrastructure, as well as additional load put on the production storage by having multiple VM snapshots opened simultaneously.
For the example described above, if you need to limit the job to a maximum of 4 tasks in parallel, you could simply limit the repository load to 4.