VMware GRT backup completes, but no files visable (AVVI)

[Jonosparks]

Among all the other issues experienced after a complete redesign and rebuild of a backup exec infrastructure, I've had one detail that has me perplexed.  When running a GRT-enabled backup of a VM, only some of the VMs parse the individual file data and thus appear for individual file restore.  However, no errors are shown in the job log on the systems that do not parse the file catalog. 

I'm on BE2010R3 SP1 with all latest hotfixes, Remote Agent for Windows is installed on all VMs, and vSphere 4.1.  The VMs that are failing have had the agent uninstalled, VM rebooted, agent reinstalled, and VM rebooted again with the same failure.  All VMs are being backed up to DeDup device through an OST plugin.

I really cannot find any rhyme or reason as to why some systems work with GRT and other don't, while all are still successfully backing up and not throwing any GRT errors.

Anyone have some insight or things to try?

Thanks!

[pkh]

Are those VM's that do not parse Windows or non-Windows?  For AVVI, non-Windows VM's cannot use GRT to restore individual files/folders.  You must back them up like physical machines using a remote agent to restore individual files/folders.

[Colin_Weaver]

Do you have GPT Windows volumes/partitions inside the affected VMs as these are not supported for GRT - althoguh you should still be able to restore the comoplete VM via the VMware section of the restore selections.

[Jonosparks]

All systems are Windows 2003 to Windows 2008 R2.  Each OS that fails to parse the files has another VM with the same OS that completes successfully.

[Jonosparks]

To my knowledge, we have only MBR volumes.  Some of the VMs that are failing are Windows 2003 which don't support GPT volumes.

Thanks.

[Colin_Weaver]

Sorry but my 32 bit Windows 2003 server has GPT options inisde the DiskPart command  as such I believe 2003 can support GPT.

EDIT: Another question though - were the affected machines converted from Physcial systems and do any of them therefore contain multiple windows volumes owned by/stored in a single VMDK file as logical partitions?

[Jonosparks]

I am getting a BeVssProvider Event in the log, but it is marked as Information and has an EID of 0 (zero). Here is the description:

The description for Event ID ( 0 ) in Source ( BeVssProvider ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Service started.

Thoughts?

[Jonosparks]

That's a good point...many of our systems were P2V'd.  However, I think the volumes were all given their own drive, but some of them occured before I started here.  Let me dive into a few of them and get back with you.

[Colin_Weaver]

Ok just for info when VMware request a snapshot of a VM, and teh BackuP Exec remoet agent is installed inside the VM, then inside the a call is made to pre-freeze-script.bat (in the windows folder) which resgiters and starts the BEVSS provider.

When the snapshot is removed at the end of the job a call is made to post-thaw-script.bat which reverses the process.

Both these batch files can eb run directly if you want to see if the event log messages are generated by this - if you are going to do this test then I'd recommend looking at the services list before and after running each (making sure to refresh it) as you shodul sse a BE VSS servcie present and then a new one get cerated and start and then that new one get removed (in addtiona to anythign that might be seen inside the event logs. This is normal behaviour. Obviously when testing this make sure your run the post-thaw file last so you don't leave the server in a strange state.