A Simple DR Solution

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by tjaybelt » A Simple DR Solution

17 posts, Page 1 of 2

1 2 »»

A Simple DR Solution

Rate Topic

Display Mode

Topic Options

Author

Message

tjaybelt

Posted Wednesday, July 30, 2008 10:34 PM

SSChasing Mays

Group: General Forum Members
Last Login: 2 days ago @ 9:17 AM
Points: 604, Visits: 379

Comments posted to this topic are about the item A Simple DR Solution

Post #544053

mops33

Posted Wednesday, July 30, 2008 10:52 PM

Forum Newbie

Group: General Forum Members
Last Login: Sunday, September 09, 2012 5:57 PM
Points: 6, Visits: 127

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

charles.maitland-799966

Posted Thursday, July 31, 2008 1:32 AM

Forum 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

Anipaul

Posted Thursday, July 31, 2008 1:42 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 6:03 AM
Points: 4,787, Visits: 1,335

Good article...:)

Post #544127

SuperDBA-207096

Posted Thursday, July 31, 2008 5:00 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 02, 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

Mr. SQL

Posted Thursday, July 31, 2008 7:04 AM

SSC Journeyman

Group: General Forum Members
Last Login: Thursday, May 16, 2013 7:08 AM
Points: 93, Visits: 88

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

alen teplitsky

Posted Thursday, July 31, 2008 8:09 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 2:11 PM
Points: 1,409, Visits: 4,506

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

Roger L Reid

Posted Thursday, July 31, 2008 9:01 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, January 22, 2013 3:15 PM
Points: 107, Visits: 163

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

rogerss

Posted Thursday, July 31, 2008 9:25 AM

Forum 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

Mohan Raghukul

Posted Thursday, July 31, 2008 9:28 AM

SSC Veteran

Group: General Forum Members
Last Login: Monday, January 03, 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 »

17 posts, Page 1 of 2

1 2 »»

Permissions