Contingency plan
-
Hi
I'm currently trying start building a contingency plan, in my spare time, and I would like to know what did you include in yours.
At some point, I would like to compile everything this thread got and make a document with a checklist to avoid forgetting crucial points.
It can be anything related to something that can cause the server to behave incorrectly (hdd crash or bad clusters, virus, service pack update which failed and corrupt, electrical burst, flood) and their related solutions to help prevent and cure when it happened.
Thks
-
I don't have a complete list, but here's some reading on the topic.
http://www.sqlservercentral.com/columnists/sjones/worstpracticedetaileddisasterplans.asp
http://www.sqlservercentral.com/columnists/sjones/2744.asp
http://www.sqlservercentral.com/columnists/sjones/incidentresponserespondingtoanincident.asp
You'll never keep up with specific plans. The important things are to practice restores, so you have confidence in completing them. Also, document the configuration and be sure you have it stored somewhere besides that machine. If something happens, you want to b be able to reset your configuration up properly.
-
Hi,
What's your goal with the Disaster Recovery Plan? Do you want to have a general one or a specific one for your environment?
There's no point to create a general one - there's no one-size-fits-all DRP. The DRP depends on the business needs. The money at stake determines the money you can use to ensure business continuity, otherwise everyone would use clustered/mirrored/logshipped enterprise editions in 4 separate machine rooms spread across the planet.
For a specific one, there are questions:
- How much money is at stake? The measurement unit is loss/minute - or loss/secs --> How much money can you spend on this?
- What is your current infrastructure? You may already have clusters with log shipping or other gadgets - or you may have a single server with the application and the SQL Server together.
- What is the defense level of the application itself? (That is, what's the point in a 99.999% online database with a 97% online application tier?)
- And so on...
writing a DRP is very challenging and very useful, because you should have an overview about the whole system - if you didn't have it, now you will, if you had it, now you can check it.
-- Erik http://blog.rollback.hu
-
Thanks Steve, I'll take a look at those articles, they will surely add value to my ongoing plan / list.
Erik, the questions you just posted in this thread is what I'm looking for (and they will be added in my list). What I want is a list of thing I must think /check of when making a specific contingency plan. Some peoples will encounters different issues that I might not think about. I would like this thread become a thread where those people can post that information to shared about these kind of "odd" issues and hopefully how they solved them.
The plan I'm building has only "generic" things (like reminder) in it like:
What to do in case of fire, Flood, Outage
Where's backup are located
Who must be contacted when an emergency occur
Which kind of media for backup
Who is in charge of keeping the plan up to date
Where that plan is located
Who can have access to that plan
What kind of budget is associated with the plan
What infrastructure servers depends on
etc
I'm building a list to go through when making a plan to avoid forgetting things. If it can also help others DBA or future ones my goal will be achieved.
-
Test your plan, and document the process and the results Unless you know your plan will work, and that anyone with the documented process can make it work as required by the business (you may be out of town when that flood hits) it all means nothing...
You might be surprised what you learn in the process of tresting..
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply