VMware GRT SQL backup hangs on pre-processing

[nackros]

Hi,

I´m trying to backup a VM that is a Win2008R2 with SQL2008R2 using Backup Exec 2012 via the vCenter server. ESX is version 5.

I have enabled GRT and GRT for SQL, but everytime the backup "hangs" on pre-processing. I read some tips that you shouldn´t have AOFO enabled so I disabled that but that doesn´t help.

If I disable GRT completely I can backup the VM without errors, but ofcourse I cannot restore individual databases.

I have the lastest BE patches including SP1a and the agent on the winserver is updated

So what could be the problem here? The same BE server is backing up a Sharepoint with GRT that works as it should and also fileservers with GRT.

Any help is much appreciated.

Thanks

//Andreas..

[ZeRoC00L]

How long did you wait at the pre-processing stage ?

http://www.symantec.com/business/support/index?page=content&id=TECH78109

[nackros]

At least 1½ hours. What´s the normal time period for this?

The pre-processing time for SharePoint took a couple of minutes.

I looked at the Technote you linked to, but that suggested to deselect consistency checks for SQL, but I can´t find that option anymore since BE2012 upgrade..

Is this option still present somewhere, when using VMware backups?

[ZeRoC00L]

Option should be there, just check the BE2012 Admin manual, page816.

Do you have the SQL agent installed ?

What if you run the backup, do you see any messages in the eventlog of the SQL server?
What if you run the consistency check in SQL itself on the SQL server, does it run perfectly ?

[nackros]

When I backup the VM there is no more specific SQL options. correct me if I´m wrong.

If I should backup the database directly on the server I have that option.

But like I said I´m backup up the VM and using GRT with SQL.

I could try to backup the database directly just to see if that works, but I want to backup the whole VM.

[ZeRoC00L]

Can you also please check these questions:

Do you have the SQL agent installed ?

What if you run the backup, do you see any messages in the eventlog of the SQL server?
What if you run the consistency check in SQL Management Studio on the SQL server, does it run perfectly ?

[Colin_Weaver]

As well as ZeroCool's points:

If you watch in the vSphere Client when the jobs starts do you see a VMware snapshot request made against the SQL VM?

If you run "vssadmin list writers" inside the VM are all the writers stable

Do you have a lot of existing VMwares snapshots aginst the SQL VM (we recommend you have none)

[nackros]

Yes the BE agent is installed and is running, and we have the correct licensing for this.

I can´t see anything related to this problem in the server´s eventlog. Lots if info though about VSS starting and stopping... could have something to do with that.

BUT! As I´m writing this the backup started doing backups instead of pre-processing! It took about 2 hours before it started.

Not sure if this was triggered when I logged in to the server or if it´s normal. 2 hours sounds a bit too long.

I will investigate this more after the backup has finished to see if GRT has worked.

In the meantime, thanks four your help ZeRoC00L

[nackros]

Well, the backup has completed and verified with no errors.

But I can´t restore any SQL databases from the backup. Individual files seems to work so the basic GRT seems to work, but not the SQL GRT.

When I rightclick the server and select Restore I only have the option to restore from "files, folders and volumes", not from "Microsoft SQL".

So it didn´t work. My guess is that something is not right that caused the pre-processing to take so long until it finally gave up on SQL GRT. Although there´s nothing about this in the log.

To answer your questions:

- The SQL server does regular consistency/index checks on all the databases and all the reports says it´s fine.

- I can see in vSphere that BE takes snapshots and so on. Looks fine.

- When I list the VSS writers they all states that there are no errors.

But I did find that there were one extra older snapshot of the SQL server taken by BE in february. Could that have caused this?

Any more tips on this? Is there a way to see more of what´s happening during the pre-processing step?

[ZeRoC00L]

Does the BE service account has admin access in SQL ?

[ZeRoC00L]

Is the disk where SQL is located an extended partition ?

http://www.symantec.com/business/support/index?page=content&id=TECH181823

[nackros]

I did a testjob just backing up the databases directly with the agent, not using VMware GRT, and that worked fine. That job used the same account as the VMware GRT job does, so I guess the account has the neccessary access right?

With that backup I can also do a restore, so as far as I can tell everything works and I can workaround it, but the problem remains: VMware GRT SQL does not work.

Any more hints?

[nackros]

Nope. There all normal partitions on local drives inside the ESX host.