BE2012 - Design/strategy - VMware based with GRT OR regular backups with periodic VMware backups

[rasmusan]

Hello

I am setting up a new environment, based on Backup Exec 2012. We have Backup Exec licensing for VMware for all hosts and application/database license for all AD, Exchange, SQL, Sharepoint servers.

Our environment is almost 100% virtual - based on VMware vSphere 4.1. Around 50 servers and roughly 2TB of data. We have Exchange 2010, Sharepoint 2010, SQL server 2005/2008/2008 R2, Active Directory (DC's running 2008 R2). We have shared storage based on Fibre Channel and the backup server is connected to the shared storage through FC HBA's

Now, I am a little unsure on how I should make this setup - should I base the setup on a pure VMware backup, and use the GRT option to allow restore of AD, exchange, SQL, sharepoint objects, OR should i perform "regular" backup of AD, exchange, SQL, sharepoint servers? What do people do and what are their experiences on the various choices for backup strategy and agents?

I have personally thought of running a GFS rutine with daily differential and weekly/monthly full backups, based on VMware backups - D2D2T

But I need some inputs on Best Practice, pros/cons as well as maybe other suggestions for strategies...

Any help is greatly appreciated !

[CraigV · Accepted solution]

Hi,

If your VC is connected to the SAN as well should definitely consider the AVVI backups with GRT enabled for the applications. The reason for this simply being a SAN-based backup is going to be a lot faster than using a RAWS agent backup.

For best practices, check the links below. They're for 2010 but there is no way for them not to relate to 2012 as well:

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

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103509...

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

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

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

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

Your backups and restores are going to be a lot faster too. The links above will clue you in pretty well as to what and how to set up your backups.

[rasmusan]

VC is connected to SAN as well.

But what about restores - wouldn't the whole backup have to be staged on disk, before it can do a restore, thus making is slower to restore?

and what about system state restore, to fx. restore AD consistency on a domain controller - is that possible from AVVI backup with GRT enabled?

(and thanks a lot for the links btw)

[RLeon]

Please refer to this thread:
https://www-secure.symantec.com/connect/forums/be2010-best-practice-virtual-ms-sql-2005-server

Please consider the above limitation when relying 100% on GRT backup for MS SQL.
A GRT backup is basically a snapshot based backup.

The problems with snapshot backups of MS SQL in Backup Exec:

1. GRT snapshots do not truncate the transaction logs, implying that all your DBs should be set to "Simple Recovery Mode" to avoid logs filling up your disks.

2. With SQL DBs in Full Recovery Mode and GRT snapshots, you may think that a workaround would be to just setup a separate Backup Exec schedule to specifically backup and truncate the transaction logs. But this workaround won't work. The backup job would error-quit because Backup Exec requires SQL transaction log backups to only run after an application-level Full/Incr SQL backup. The GRT snapshot is not considered to be one.
(Summary: You can't just run a backup job to truncate the transaction logs after a GRT snapshot backup. BUExec won't let you. You can only truncate logs after an applicatoin level backup of the DBs, which defeats the purpose of doing a VM level GRT snapshot backup of the DBs in the first place.)

3. Another workaround with the above problem is to truncate the logs manually on the SQL server instead of doing it through Backup Exec.

4. Having to have the above three workarounds just so SQL GRT backups could be done without problems, somewhat.

Not sure if Backup Exec 2012 has this fixed yet.

RLeon

[CraigV]

...if you have the ADRA agent for Active Directory you shouldn't have an issue doing a GRT restore.

Yep, it would stage to disk first, but with a SAN in place, it's going to be a lot faster than restoring to a SCSI disk or even a NAS or USB drive for instance.

[rasmusan]

OK, but I am not thinking just restore of individual objects in AD - rather if the DC for some reason stops replicating (USN rollback etc.). Can I then restore entire system state (non-authoritative) to restore AD to a previous stable state - like it si possible wiht "traditional" backup of a DC ?

[CraigV]

Using a traditional backup you'd be able to restore the System State, or any other file/application if you wanted too. To restore applications you'd obviously need the required agent!

[Dariel_Cruz]

I have not been able to get GRT to work for a domain controller vm on the new 2012, the backup says it completed successfully but I do not see any AD options to restore from, I do see the file level GRT is happening and I can restore individual files and folders so the agent is working and if I do a regular server backup using the windows BEAgent like a physical server then AD GRT works, but not thru the vm backup. has anyone actually tried to restore any AD GRT stuff successfully?