DR Prep

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » DR Prep

DR Prep

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Thursday, January 03, 2013 9:39 PM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 3:19 PM
Points: 31,526, Visits: 13,863

Comments posted to this topic are about the item DR Prep

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #1402663

hisakimatama

Posted Friday, January 04, 2013 7:29 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 7:43 AM
Points: 172, Visits: 3,069

I'd say that, this year, my main DR plans would be teaching the next-most-technically-competent person here (who isn't a programmer, unfortunately) about basic DR principles. I might not be available at all times (though the company certainly expects me to be!), so someone else should definitely be aware of what needs to be done in an emergency. Already drafting some tutorials on how our DR process should go, and we'll take things from there.

Thankfully, my own DR prep routine seems to be fairly good; daily DBCC, backup, and restore, done in the off-hours. The practice has paid off, too, as just this week we had an incident where all of the data in a table was vaporized by accident. Thanks to practicing a restore routine every day, though, I was able to get a copy of the database restored and all of the data replaced in 15 minutes; practice is definitely key in such a situation!

----------------------------------
My journal of things I'm learning about SQL

Post #1402878

Rod at work

Posted Friday, January 04, 2013 8:13 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 1:48 PM
Points: 577, Visits: 1,019

Very timely discussion, Steve. Last year, for the first time that I'm aware of, we wrote up some DR plans, with respect to our database. (It's appalling to think we hadn't done this before.) I appreciate your bringing up the fact that we should do a drill on this, at least once a year. I think I'll bring this up at our next IT meeting, next week.

Kindest Regards,

Rod

Post #1402896

TravisDBA

Posted Friday, January 04, 2013 8:17 AM

Ten Centuries

Group: General Forum Members
Last Login: Wednesday, June 12, 2013 10:46 AM
Points: 1,290, Visits: 3,001

Backups are only half the story. The real important part of DR is how fast can you get the databases back to point in time and operational once you have all the backups covered? Your user could care less about your backups. They are however, concerned about your restore process though because that directly affects their downtime. So, automate your restore process by building a job that nightly scripts out and saves all your users database restores (FULL,DIFF,T-Log) right up to point in time including the stop at clause, so that all you have to do is bring the script up in in the Query Analyzer in case of emergency and plug in the stop at time and you are ready to go. This front work will definitely cut your down time drastically and you will sleep much better knowing that those scripts are there everyday. I have this stored procedure/job on every production SQL Server we have. Always remember this, no one appreciates what a DBA does until they cant get to their data!!!!!!! BigGrin

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ... BigGrin

Post #1402899

Dizzy Desi

Posted Friday, January 04, 2013 8:51 AM

Valued Member

Group: General Forum Members
Last Login: Monday, June 03, 2013 8:24 AM
Points: 70, Visits: 657

I'm hoping that my organization will get beyond just talking about it and do something about it. We go through several hours of meetings each year to discuss the plans, issues, etc. But we have yet to see any action come from it, including simple things like moving a couple of servers to the DR location so we have some available.... so far it's looking like it's simply an exercise so that someone can check a box saying they've done it.

And wouldn't it be nice to actually have a DR exercise to test what we have? w00t

Post #1402929

dduensing

Posted Friday, January 04, 2013 9:52 AM

Valued Member

Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:58 AM
Points: 55, Visits: 134

It is interesting to see how interconnected all of the various systems are today. We are discovering that systems considered 2nd, 3rd, even 4th priority have hooks that need to be available in the event. Duplicating/replicating databases, even AV infrastructure suddenly shows up, because other processes require that to be in place. File structures to deliver "critical" functions have to be consistent across the enterprise (DFS, replication, something!) Testing itself can be difficult, can you test around naming services, routing requirements, even MPLS availablity! Individual system testing is required, but the whole pie can be difficult to see!

Post #1402968

SQLRNNR

Posted Friday, January 04, 2013 11:09 AM

SSCoach

Group: General Forum Members
Last Login: Today @ 5:03 PM
Points: 18,853, Visits: 12,438

I will be scheduling additional testing. I also have a few more checks that I will be implementing.

Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp

Post #1403028

« Prev Topic | Next Topic »

Permissions