Backup Exec 2012 - Job Failure V-79-57344-38260

[mmosier88]

We are currently using Backup Exec 2012 V- Ray Edition to back up a cluster of VMs running on vCenter 5  Everything was going great until a couple of weeks ago, when two of my VMs: A CVS/File Server and a SQL Server started failing with the error:

V-79-57344-38260 - Unable to create a snapshot of the virtual machine. The virtual machine may be to...

Since this seems to be a fairly common issue, I did some research on the symantec knowledgebase, and applied proposed fixes such as Removing/Upgrading VMware tools, Uninstalling the VMware vss provider, testing snapshots in vCenter, rebooting the media server and guests...etc.  all to no avail.  The backup job still fails with this error.

What is odd is that everything seems to back up normally, and then the job fails at the tail end when it is "post-processing"

 After running a test backup on one of the VMs I watched the vCenter console and saw that It took the snapshot, completed the backup AND verified the backup, all with no errors.  It then went to post processing cleanup, deleted the snapshot and then proceeded to take ANOTHER snapshot AFTER the job was done, which immediately caused the job to fail with this error code.

The only thing these two VMs have in common is: Both were P2V conversions and both have virtual disks are partitioned into 2 Logical drives using the Windows Disk Management, however they are NOT dynamic disks, just 1 vmdk file with 2 partitions... 1 for the OS and 1 for data. but as I said earlier, they were backing up fine two weeks ago.

If anyone has any insight, it would be much appreciated as I've now wasted days banging my head against the wall with no real progress.  I've attached a sample backup log that I got today.  It does not have real ip addresses/servers...etc. because I've blacked all of that out for security reasons.

 

[Backup_Exec1]

Hi

1) Try taking a snapshot by hand using the vSphere client  (quiesce checked, snap memory unchecked) and check for logs. You can continue to test this way. No need to run backups. Logs are in RAWS install folder under VSS Provider\logs subfolder.

2)  If no logs then look down in the system tray for the VMware icon and make sure there is no yellow warning sign. This would indicate the VMware Tools are out-of-date and need to be upgraded. If they are in this condition they will not run our scripts. You can also look in the Summary tab of the virtual machine in the vSphere client and it will tell you whether the VMware Tools are up-to-date or not. This has been the biggest reason for the provider not running to date.

3)  If still no logs found try running the C:\Windows\pre-freeze-script.bat followed up right away by C:\Windows\post-freeze-script.bat by hand. Make sure these ran ok and you had logs produced. If they ran then you should have logs and the problem is why isn’t the VMware Tools running our provider.

Thanks

[mmosier88 · Accepted solution]

I've determined the root cause of the issue was due to a corrupted backup job that was looking for a folder in vCenter that does not exist anymore. Both VMs were moved to a different folder under the VM and Templates view last week. 

Once I discovered this, I deleted and recreated the backup job.  Last night the new job completed without errors, and I can browse the tape and see the .vmdk files.