Hi, go to the backup infrastructure section, and add as a managed server either a windows or Linux server that you wish to use as a proxy. If you go to the backup proxy section you can add a new one from here, Veeam can automatically distribute the tasks between your different proxy servers and/or repository servers

First 2 thoughts, move the sql to a different server, this frees up some cycles and a lot of ram.

2 create a new proxy and add it do veeam and the jobs. This should free up cycles that ar evening used for the proxy services. That leaves you with pure job scheduling and repo services on the original servers.

As many have said add more Proxies to process the workload.  Check these links for design considerations and the video is older but good.

Design | Veeam Backup & Replication Best Practice Guide

Veeam Backup & Replication – Design and Deploy Best Practices

I have some tips below, but I want to let you know that you may see your topic get transferred to another space. The Automation Desk’s purpose is for leveraging Veeam PowerShell cmdlets and REST APIs to build custom tools, scripting, and automation. It sounds like you’re asking for basic Veeam architecture and optimization help. 
 

Since you are using Hyper-V, Veeam should already have installed the proxy role onto each host that you’ve added into Veeam. Dedicated proxy VMs or physical hosts under the Backup Proxies tab are for other hypervisor types.
 

I would start by editing the Hyper-V host settings in Veeam to add more concurrent tasks on each host if you have the spare CPU and RAM. Otherwise, you’ll need to looking at adding more Hyper-V hosts so you can run off-host proxy mode. https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_backup_proxies/hyperv_proxies.html
 

Either way, I would double check your network rules and repository settings to make sure you don’t have a bandwidth, IO, or concurrent task throttle in place on either as it would defeat the purpose of processing more machines at once. 
 

This of course all assumes that your jobs show the bottlenecks as source or proxy. If the bottleneck is listed as network or target it means networking or the repository is what is holding you back. 

Ah, sorry for posting in the wrong section.  I had no idea that’s where I was lol.  If this gets transferred I totally understand.  For the Bottlenecks, if I open an active job, it just kind of hangs on the Bottleneck field as “detecting”.  The job started 18 hours ago and has the “1:31:21 PM    Waiting for backup infrastructure resources availability     18:34:16” event.  The VM backup is pending as “12:16:06 PM    Resource not ready: backup proxy     19:52:03”  This is the case for many of the active jobs now.  On a few other active jobs, Bottleneck is listed as Target (this is for local backup job) so I presume that is the local Veeam server, and for Replication jobs, Bottleneck is “Network”

And for Hyper-V settings, we have 6 Hosts running in the cluster with the active VM’s.  Should I enable 1 or more of these as Backup Proxies, or should I not modify those since they are active hosts.

So the bottleneck is Proxy and you should deploy more of them so the jobs can take advantage.  The CPU core count on the system can only handle so many tasks - 1 task (one HDD) = 1 core.

Thank you all for the input!  Keep it coming if you have more ideas.  I will start adding servers (physical and virtual) to the mix and add them as Backup Proxies.  I assume that Veeam will just start using them?  Is there a way to view the utilization on a specific proxy?  As in...how do I know it’s working?   I just added a VM as a proxy, it installed all the necessary roles (installed as General Purpose) and inventory sees it.  Just wondering if it’s doing anything.  I just added it a few mins ago so it may be a little early...I have the patience of a 5 year old.

If you look at the job that is running and select a VM it will tell you in the detail pane which Proxy is being used.

Interesting.  If I look at all 30 jobs that are active, majority are in Pending state (Resource not ready), but the ones that are running are all Replica jobs using the “onhost” backup proxy of the Hyper-V server they reside on.  The Backup jobs are all waiting because their replica jobs are pending.  Replica and Backup jobs are all set to use “offhost” proxy, but to failover to onhost if no suitable offhost is available.

Yeah as things start moving the new proxies should begin to be used.  Just patience is needed.  

Keep an eye on your jobs to see if the new proxies are being used at all. If its always failing over to the onhost proxy you may be having challenges with the new proxies and their networking/access.

Other than peeling off proxies, you can also look to peel off the SQL Server (as @Epicfailing mentioned) or even moving the VBR itself to a new machine, while transforming the existing VBR to a repository only.