Geographically dispersed DR for critical databases

Question

Geographically dispersed DR for critical databases

RSingh-135921

Default port

Points: 1438
More actions
August 13, 2009 at 10:06 am

#135322

Hi,
We are a manufacturing house having offices around the globe.
Our main datacenter is in USA housing majority of the critical servers.
Some of our critically important databases are hosted on a 2-node cluster.
Our IT Director is interested in a DR plan for these databases.
He is interested in having a backup of these databases to a location somewhere in Europe so that they can be easily recovered if something happens to the datacenter in US.
He has asked us to evaluate the various options provided by SQL Server for achieving this. We have to evaluate the options on the basis of cost, amount of data loss, time to recover in the event of disaster etc.
If someone has done this exercise or has some handy links on internet, pls share.
Shall be highly grateful.
Regards

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 1

There are numerous ways this can be accomplished. You may want to google Geographically dispersed clusters. There is software that will allow you do to this, but it isn't cheap and there are specific hardware requirements. Another option would be log shipping. Depending on how frequently you ship the t-log files would play a part in how much data is lost. Another option would also be replication.

Beyond this, I can only provide speculation as I haven't had to setup servers in this fashion, yet.

Schadenfreude-Mei SSChampion Points: 14083 More actions · Answer 2

We do this (all beit only accross a city).

We have an a/p cluster on site and mirror our critical databases to our scf for dr (we have a p2p fibre, so latency isnt a problem). We cant have a 3 node cluster because our scf is on a different subnet and as yet windows clustering cant navigate this (maybe windows 7). On top of this we have an online backup solution (DataBarracks, look them up) and we also migrate our daily dump files to the scf using robocopy (we backup locally and use RC to pull the data).

I wouldnt suggest Replication unless you have used before and can do advanced config (down to the db object level), if the database wasnt designed with Replication in mind you could be in for a rough ride.

I would go for Mirroring or Log-Shipping. Mirroring is better over all (but you have to have good comms links) otherwise Log-Shipping is ok (but with latency of 1 min between schedules) its not fast enough for us. Either way you need a second tier cause the problem with Replication, Mirroring and Log Shipping is if you get a database corruption it will spread to your dr copy (and then its useless, i.e you have to fix live to fix dr).

My advice is to read up on the subject and options, speak to your network people or isp (intenational comms links) and make a decision based on that. Seriously though, look at online backup solutions (like DataBarracks (though they are UK based)).

Hope this helps and have a good weekend (unless your working in which case good luck) 😎

Adam Zacks-------------------------------------------Be Nice, Or Leave

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 3

I'm kind of with Adam here.

I might go with mirroring, perhaps using an asynchronous mirror so you don't interrupt production if you have issues with the link. However I'd also probably log ship to a 3rd location closer, even a small place in the US. It would give you more tolerance in case the overseas link dies.

RSingh-135921 Default port Points: 1438 More actions · Answer 4

Thanks Lynn, Adam and Steve.

I have also been doing some reading on this.

From what I have read on web and as you have suggested, it seems that we would have to make a choice between log shipping and DB Mirroring (High Performance mode).

Thanks