Video Screencast Help

Backup Exec 2012: VMware Host Backups with GRT-enabled Exceptions

Created: 19 Mar 2013 • Updated: 08 Nov 2013 | 6 comments
This issue has been solved. See solution.

We recently switched from using RAW backups on our entire environment to VMware host backups backing up to Tape: 5 physical servers, 2 VMware hosts /w 10 VM's

We have 2, ESX 5.1, VMware hosts that have 5 VM's each, with a local SAN attached for storage.  

GRT is enabled for all servers File/Folder, SQL, Exchange, and Sharepoint;  Most GRT-enabled backups work great except for SQL on 2 servers, and we have 3 SQL servers, in which file/folder GRT works just fine.

Host1 has 1 SQL server which GRT-enabled SQL Backup does not work.

Host2 has 2 SQL servers which GRT-enabled SQL Backup works on 1 server, but not the other.

On the SQL servers with exceptions we get the following in the BE2012 logs:

V-79-57344-38749 - Backup Exec was unable to prepare Microsoft SQL resources for Granular Recovery Technology (GRT) operations.  Therefore you will be unable to perform GRT-enabled restores of Microsoft SQL data for '<ServerName>\MSSQLSERVER' from this backup.

Any ideas, i have been working with a BE Tech for a few weeks and I thought I would give the forums a try.

Operating Systems:

Comments 6 CommentsJump to latest comment

Gurvinder Rait's picture

ESX 5.1 is currently not supported with BE 2012. Refer SCL

Colin Weaver's picture

As yiu have stated your are going RAWS backups, what version of SQL and what operating systems are running inside the affacted VMs. Also is there anything unique about the SQL server configuration or the disk storage holding teh SQL data between the server that works and those that fail. 

shattuckk911's picture

We are using Windows Server 2008 R2 Standard and SQL 2008 R2 on all 3 of our SQL servers. The only thing different between the 1 that works and the 2 that don't are number of drives. We try to keep everything uniform:

SQL1 - C:\ - SQL resides on the C:\ drive

SQL2 and SQL3 - C:\ and D:\ - SQL resides on the D:\ drive

shattuckk911's picture

I read something about selecting uneccesary GRT resources in the VM host backup that could cause issues.  I basically setup the job and checked everything for each GRT backup instead of only selecting what is specificly running on the host.  Could that cause any type of issues in backing up the Host?  

shattuckk911's picture

Finally this issue is eplained:

1st SQL server has "offline" databases, VMwarehost-GRT backups completely skip the entire SQL instance if a single database is flagged as offline. 

    - Doing a "SQL ONLY" RAWS backup of the server since my boss wants to leave the databases on that SQL server to bring up as fast as possible when needed.

2nd SQL server is a sharepoint server, so it was basically a False Positive where my SharePoint license backed up the SQL instances, but the SQL licence wanted to back it up as well.  So it flagged an exception.

    - Diregaurding error till we move all SQL servers to 3rd VM host and edit backup scheme.

Symantec did mention a upgrade that may be in the works where you can access what data you want to be backed up when using VMwarehost-GRT backups.  We will be able to use it like a RAWS backup, which i think will be amazing because we will be able to exclude the offline databases on my 1st SQL server and get a good backup the way i want the software to work.

Hope this help the next person that receives these issues.