I think you've hit the nail on the head there Michelle, at present I am trying to persuade the "decision makers" in our buisness to make available more resources & or budget to review and complete our DR plans.
As a mainly Oracle based company the smaller SQL Server environment is seen to not be business critical, even though a number of the SQL systems are both business critical and feeder systems to the Oracle production servers. When I approached the Oracle team about "there" DR plans, they replied with "we have all that, we created it all when we implemented", this was about 4 years ago (currently they are also half way through a massive upgrade project, which has no DA plans). I have subsequently taken it on myself to begin developing a DA plan which I hope will become a continuous project with a rolling scope, i.e Phase 1 will be to develop the necessary DR plan(s) and required processes from a SQL Server standpoint, Phase 2 will incorporate .NET applications using the SQL Server db's, Phase 3 will include associated systems, i.e. Oracle, Reporting, etc.. Phase 4 will include the IT Infrastructure supporting all previous systems, then finally Phase 5 will incorporate any business processes/systems left out of the previous phases, by then it will most probably be necessary to begin at Phase 1 again and work through the DR plan(s) reviewing there correctness, scope and validity. I feel this will be the best approach to getting the "buy in" from the business. Any ideas/comments/thoughts on this proposed method of attack would be greatfully appreciated.
p.s. Is anyone aware of some good resources, i.e. articles, books, papers related to disaster recovery? I have done some limited research on the internet and have found some useful articles/documents but would appreciate any more resources.
Having your CV up to date should always be part of your DR strategy!!!! . Even if you recover things, it may not be quick enough or your boss may decide to throw you (beep beep) in front of the bus to allowing any downtime.
I don't mean to say that you shouldn't consider disasters, but the percentage of time these will happen, the true loss in $$ of downtime, etc have to be weighed. For Amazon.com, a few minutes of downtime are some serious $$, but only on the Internet for their retail systems. I'd bet that a day of downtime in their HR system wouldn't truly affect the company. Heck, their email may be down now due to the current MyDoom worm for all we know.
I think the two posts above are worth reading again. You really have to assess the true business impact. Don't let anyone tell you that a day of downtime is more serious than it is, look back, see when you've been down and the impacts and make a smart decision. For most DR plans in most companies, the cost of the solution isn't worth it.
But be sure that you do test your cheap and easy solutions, test restores, be sure you know where media is, have copies of CD keys somewhere (preferebly offsite), have phone numbers handy, vendor numbers, support contracts, etc.
As far as the Internet goes, I haven't seen much in the way of planning docuements. Like many things, companies seem to consider this proprietary (I guess it could be used for an attacK) and not enough is published. Maybe we can get James to start a discussions
Great feedback, everyone! It's true, there are lots of things to consider (setting expectations is a good example), and then again considering everything isn't always the best approach. I've seen companies go all out on a comprehensive DR/BC plan, spending hundreds of thousands of dollars to cover every angle -- even when the overall risk is fairly low.
I think Steve makes a great point -- having a DR plan that attempts to encompass every possibility just isn't practical for most companies. The key is getting everyone involved, make sure everyone understands risks and the consequencies for any given scenario.
I've got more coming on DR/BC and backup in general. I'd really like to keep the discussion going!
I think one thing that has come out of this thread is the need to prioritize your DR plan.
If your documentation is stored on an intranet then a DR plan stored on that intranet that puts restoring the intranet on day 2 is a bit of a chocolate fire guard.
The example of Amazon's e-mail going down illustrates a situation where there may be little impact on the customer (always a good thing). In my case we lost e-mail for a day and this had a massive impact on our customers and we damn near lost a few.
It is very much horses for courses.
I'm a junior IT Support and looking for DR document to learn. If anyone like to send me a copy or give some idea much appriciate.