Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

A Simple DR Solution Expand / Collapse
Author
Message
Posted Wednesday, July 30, 2008 10:34 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Thursday, September 11, 2014 4:44 PM
Points: 615, Visits: 443
Comments posted to this topic are about the item A Simple DR Solution


Post #544053
Posted Wednesday, July 30, 2008 10:52 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, October 16, 2014 9:06 PM
Points: 6, Visits: 140
yes DR is an interesting exercise. below are some some points from my own experience.

o management do not understand time constraints for items such as bandwidth limitations, data volumes, restore times, etc. explain these things in their language and back them up with understandable metrics.

o we were fortunate enough to have separate funding for this project. hence we were able to hire an independent consultant to prepare initial architectural recommendations. specifically, this addressed required bandwidth and the choice of replication technology, i.e. backup only [full/diff], log shipping, replication, mirroring.

o engage a project manager, at least for the initial exercise.

o document everything and keep it safe and accessible.

o test your documented procedures using alternative staff, if possible. i.e. the person writing the failover guides should not be the person testing the failover capability.

o time each task in your test sequence and communicate the results.

o script everything and keep these scripts under version control. our log shipping is set up entirely from scripts. this is much faster than 'point and click' and can be easily automated or transferred to other DBA staff.

o keep things up to date. new customers/applications come on board. don't assume that someone has added their databases to the DR site or updated the documentation. have an appropriate person in charge of this, preferably with a backup.

i'm sure there are others. i'll add anything else that comes to mind.





Post #544058
Posted Thursday, July 31, 2008 1:32 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, July 31, 2008 9:29 AM
Points: 1, Visits: 5
One product that I have found to be very useful for this type of DR is Microsofts Data Protection Manager. It does DB and file backups and is designed for low bandwidth scenarios.
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx

Post #544118
Posted Thursday, July 31, 2008 1:42 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 16, 2014 4:46 AM
Points: 5,416, Visits: 1,400
Good article...:)


Post #544127
Posted Thursday, July 31, 2008 5:00 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
Nice work! I would like to have seen a bit more technical stuff though, as to how you're going to maintain the copies across the network, using replication, log shipping etc. Seems good for a prototype but what did you do next?
Post #544266
Posted Thursday, July 31, 2008 7:04 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, September 10, 2014 2:59 PM
Points: 95, Visits: 93
Just use doubletake. If they say they can't afford it tell them they can't afford not to. Just realize the effort this guy put into all of his simple DR drill and the time wasted could have paid for a license.

http://www.doubletake.com/
Post #544350
Posted Thursday, July 31, 2008 8:09 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 12:10 PM
Points: 1,414, Visits: 4,541
we've been using EMC's SRDF for years now. we ship the data on a disk level from one SAN to another.

problem now is we have x64 at the main site and the DR servers are so old that our laptops are more powerful. no one wants to write a check to buy servers that will sit there for months or years without any use


https://plus.google.com/100125998302068852885/posts?hl=en
http://twitter.com/alent1234
x-box live gamertag: i am null
[url=http://live.xbox.com/en-US/MyXbox/Profile[/url]
Post #544404
Posted Thursday, July 31, 2008 9:01 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 9, 2013 8:32 AM
Points: 108, Visits: 166
Client from hell, huh?

Do everything you're doing, and plan and implement a DR scenario during lunch.

A lot depends on what the BO really meant by "DR". FTPing database backups to a remote site may be enough for some.

Another approach would be to explain how much he CAN have in a day or a week. Sometimes the true cost will mitigate requirements. That gets SOME protection in fast, and then s/he can decide if the cost of more is worth it.

Frankly, doing much more than FTPing the file systems with the database dumps is going to cost enough in labor that it'll be cheaper in the long run to license something like XOSoft.

But if the BO's expectations are off by an order of magnitude, and he won't hear otherwise, it's probably time to fire the client.


Roger L Reid
Post #544459
Posted Thursday, July 31, 2008 9:25 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, August 13, 2008 6:16 AM
Points: 1, Visits: 15
The article is much too simplistic in regard to changing all the places where the previous server name is hardcoded. That process is an absolute nightmare. We actually ran into a situation where we did a DR to a test server, changed the server name in our jobs everyplace we could think of (msdb, job steps, maint plans, etc.). Still we found that the jobs were running on the original server. Microsoft said it's a reported bug but there's no solution yet. LOL (meaning lots of luck!)!
Post #544481
Posted Thursday, July 31, 2008 9:28 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, January 3, 2011 12:30 PM
Points: 236, Visits: 37
Nice article. However, I had to come up with something like this as well and choose mirrorring because the client wanted to be able to swtich the app as part of DR and not have to shut everything down - and did not have the budget to cluster.

Another client asked for P2P replication as part of their DR, the problem is, they want to use it as a fail-safe as well as a way to load balance the app. Its up and running though (on some very hi- end servers :) )




Post #544483
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse