DR Prep

  • Comments posted to this topic are about the item DR Prep

  • 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!

    - 😀

  • 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.

  • 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!!!!!!!:-D

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

  • 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:

  • 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!

  • 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, MVP
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

Viewing 7 posts - 1 through 6 (of 6 total)

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