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

DR Prep Expand / Collapse
Author
Message
Posted Thursday, January 3, 2013 9:39 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:25 AM
Points: 33,267, Visits: 15,433
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
Posted Friday, January 4, 2013 7:29 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 11:37 AM
Points: 607, Visits: 6,643
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!




-
Post #1402878
Posted Friday, January 4, 2013 8:13 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, June 20, 2014 8:23 AM
Points: 738, Visits: 1,305
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
Connect with me on LinkedIn.
Post #1402896
Posted Friday, January 4, 2013 8:17 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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!!!!!!!

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1402899
Posted Friday, January 4, 2013 8:51 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, April 25, 2014 10:27 AM
Points: 71, Visits: 671
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?
Post #1402929
Posted Friday, January 4, 2013 9:52 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, April 4, 2014 10:20 AM
Points: 56, Visits: 144
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
Posted Friday, January 4, 2013 11:09 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 11:36 AM
Points: 21,742, Visits: 15,432
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


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 »

Add to briefcase

Permissions Expand / Collapse