DR Planning - Best Practice

[Muddyfox]

Hello, we are reviewing our current DR setup and would like to expand on our current Veeam jobs.

Current:
Datacentre: 2 ESXi 5.5 host's running 14 VM's. Roles include - 2 DC's, Exchange 2010 (standaole, no DAG), ShoreTel HQ Sevrer, File Servers, App servers, Veeam B&R and Proxy (same VM).

Offsite: Direct attached (same subnet) via fibre (500m down road). 2 ESXi 5.5 host's, 1 set as Veeam Repo Server. 1 Unused.

Veeam Config: Backup jobs only for all 14 VM's running daily (out of hours) to the backup Repo. at our Offsite. Daily Veeam Configuration backup to same location.

Planned:
Continue to backup All VM's to current Repo. host but utilise replication (15min intervals) to keep a cold state of our tier 1 VM's (Exchange, ShoreTel HQ, File) on the spare ESXi host at the offsite.

Archive backup jobs to further device for true offsite backup storage.

Is it still the case that backup's of DC's are fine but replication is a bad idea? I'm assuming so.


In the event of a primary Data Centre failure how would you go about starting the restore process at the Offsite location? my thinking was to:
Build a Veeam B&R instance and restore from the config backups.
Restore and boot the DC's to the Replica target ESXi hosts
Start bringing up the replica's.

Would this work?

Thanks and sorry for the simple nature of my post, just want to make sure I have the basics down.

[csinetops]

Sounds like you are on the right track.

You have a nice pipe between sites, I would stand up a secondary DC in the DR site. That way if you lose your main site you don't have to worry about fiddling around to restore a DC, you can just bring up your replicas and worry about restoring your other DC later.

I'd also just put your Veeam management server at the DR site, no reason it can't run the jobs from there as your proxies do all the heavy lifting at your primary site. In a DR scenario you'll be ready to restore/fail over to the replicas.

You'll also need VCenter at your DR site unless you want to add and manage the ESXi hosts stand alone into Veeam to be able to restore to them.

[foggy]

I'm along the lines with these advises. Here's the KB article describing different DC recovery scenarios, you can see that having a secondary DC at the DR site will make it much easier.

[Muddyfox]

Hi csinetops and foggy.

Great! thanks for coming back to me. I like the idea of moving the management server. I look at migrating that asap.

So assuming I switch on App Aware for the replication jobs app's like Exchange should be perfectly happy in the DR site?

How would you do your DR testing? I know Veeam makes this super easy I've just never tried it 'live'

[foggy]

So assuming I switch on App Aware for the replication jobs app's like Exchange should be perfectly happy in the DR site?

Yes.

How would you do your DR testing? I know Veeam makes this super easy I've just never tried it 'live'

You can create a failover plan, cut the link to production and failover all the VMs. After making sure everything is fine, perform undo failover.

[Muddyfox]

Hey Foggy, great thanks.

One final question, ShoreTel runs on top of a MySQL database installed on Windows Server 2012. It's my understanding that mySQL doesn't support VSS and therefore can't be backed up with Veeam relying on the Application Aware Processing. Is this still the case? I see lots of things on here about mySQL and Linux but not Windows Server.

Thanks

[kilobits]

I believe the same approach for Linux can be used for a Veeam backup of MySQL on Windows Server. Using the built-in functionality of pre-freeze and post-thaw scripts execution while using VMware Tools Quiescence. Here is the whitepaper regarding MySQL backup for Linux.

Here is a thread that may be helpful to you as well. Foggy may be able to shed more light on this as well...