Highlighted

VMware backups greatly slowed down

I've been running BE15 for a while and it started out good, but lately my VMware backups have drastically slowed down. It seems to be related to SQL and Exchange stores throwing up GRT errors:

2015-10-14_8-17-06.png

The strange thing is that the error message doesn't match the error description, the server names are totally different. All VMs have the latest agent installed. I've seen a 400GB Differential backup go from 6hrs to 12hrs, with the only difference being the job now throws out these errors.

Anyone know what is going on here?

BE15(latest patches)
Server 2012

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

In the end the I needed to

In the end the I needed to delete the job and recreate it and it fixed. Something must have broken when i deselected some VMs from the job that were previously being backed up. I created another job in an attempt to recreate the problem, but I couldn't manage to make it happen again.

View solution in original post

4 Replies

OK the first server name is

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

 

 

 

 

Highlighted

The server names in the

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.

Highlighted

I ran an agent-less backup of

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.

Highlighted
Accepted Solution!

In the end the I needed to

In the end the I needed to delete the job and recreate it and it fixed. Something must have broken when i deselected some VMs from the job that were previously being backed up. I created another job in an attempt to recreate the problem, but I couldn't manage to make it happen again.

View solution in original post