VMware backups greatly slowed down

OK the first server name is the folder name inside the datastore and would be the same as the VMname when it was first created - so the VMs may have been renamed if you no lomger see these names inside the vSphere Client

However the VMname also does not have to be the same as the hostname and the second reference against each section appears to be part of the FQDN so is the hostname/DNS name for the OS inside the VM and not the VMware name of the VM.

 The VMware tools make sure that the query into vCenter/ESXi for each VM does tie the VMname to the Hostname even when they are different.

For your speed issue,the GRT problem probably will slow it down as we almost certainly try more than once to get the GRT info during job processing. For GRT we have to be able to connect to the remote agent inside the VM so must  be able to name resolve and telnet on port 10000 from the Backup Exec Server into the each VM . Hoever I think the error is different is thsi does not work so tou may have a security issue, or a name resolution issue where IP address for completely different servers are being returned.

I'd suggest that you start troubleshoioting by testing to see if SQL can be backed up from these servers as a traditonal agent backup instead of a Virtual Machine backup as this will prove comms and security

The server names in the description are names of other VMs that are still active within vSphere. The server names in the error descriptions are all still active servers as well. None of our VMs have ever been renamed, so I don't think that is the problem.

I will try a traditional backup and see how that goes.

I ran an agent-less backup of the Virtual Machine (didn't select it throught the vCenter host machine) and all data backed up successfully. It also backed up at nearly 3x the speed of the Virtual Machine backup. So credentials are all good as well. Not really sure where to go from here.