Community archive

Ask something
Discussion Locked

Little things count in DR

0 helpful
7 replies

by editor's response

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Tell us what you think about Mike Talon's advice concerning the little things that can potentially put a glitch in your DR plan or SLA, as featured in the March 25 Disaster Recovery e-newsletter. Has your DR team conducted a thorough investigation of all the things that may negatively impact your organization after a disaster strikes? Let us know if this information is useful to you.

If you haven't subscribed to our free DR e-newsletter, be sure to do so today!

https://www.techrepublic.com/techmails.jhtml?repID=r001

7 replies

by jnoble

Don't forget, that in a disaster, you could lose up to 90% of your key people. If you don't have the staff, or alternate plans for immediate technical staffing, you will never be able to provide the 30 minute SLA guaranteed.

Staffing is the oft overlooked piece of DR. While no one wishes to look around a meeting table and randomly pick staff who cannot or would not survive a true disaster, we need to take the recent lessons of 9/11 and other serious disasters into account.

There are many true-life accounts available of companies who lost their "key" IT Staff during a disaster, and did not have the personnel to execute the remainder of their DR Plans. BCP - Business Continuity Planning, MUST take this into account if it is to be robust.

by miketalonnyc

Actually, previous columns have covered that topic, but thank you for brining it up again. While the editors won't let me harp on it every week, it can never be said enough that staff readiness is vital, in every respect.

One note though, I wouldn't consider loss of staff and/or life to be a "little" thing =)

Mike Talon
www.miketalon.com

by griss

Last week I stated that the flaw must be a technical issue. As it has been revealed to us this week, we see that a technical function is indeed the culprit.

What I would like some insight into is whether or not the rest of you feel it is a function of the DR/BC manager/planner to discover such technical specifications?

My view is that a DR planner is not, nor should be, a subject matter expert (SME) in all fields and subsets of technology.

The CHKDSK function presented in this scenario is something that should have, and assuredly would have, come to surface during the process of defining this recovery process and TESTING it. As the technical SMEs were defining the procedures to recover the systems, the CHKDSK timeframe should have been taken into account.

Do you as a DR/BC professional hold yourself accountable for detailed technical knowledge that could make or break your companies future?

-Brad

by miketalonnyc

You are absolutely correct, the DR manager need not be an expert on all aspects of the technology he or she is protecting. That's probably impossible in the modern heterogenous organization.

However, that manager MUST find staff that are expertsin all aspects of the technology, which means each staff member must know thier particular area inside and out. That will prevent issues such as those I point out here. Testing, also, would have caught the snafu, but a knowledgeable windows expertwould have found the issue before the solution was even designed.

As to the other part of your question, you are correct, this is a technical issue. Since this column is primarily about technology DR, I tend to throw in these things now and thento keep everyone on their toes.

Mike Talon
www.miketalon.com

by griss

All points well taken!

I also think that as a DR professional in a non-stratefied technology environment, one should attempt to gain an understanding of that technology (e.g. Windows or the particular SAN used).

We will never be the SMEs, but we should at least make a solid effort to grasp the technology that is a mainstay in our planning efforts.

by draco vulgaris

Since you managed to "stump the panel" with this one, how about some discussion of other little known or seldom considered glitches that could ruin a DR plan?

As someone else pointed out, testing the plan described in the article should have proven that the 30 minute SLA was impossible. Are there plans that cannot be tested?

Anyone with the sort of plan you described might want to test it quarterly or even monthly!

I don't know if Merrill-Lynch would be willing to talk about it but itwould be very interesting to know how, and how frequently, they tested the plan that had them up and running in four minutes on September 11, 2001!

How do you know your test is good enough to prove that things will work during a real disaster?

by barry_bogart

You are absolutely right about the Chkdsk problem. I supported an imaging system which had an extremely fragmented directory structure and about a million files, due to the way that Viewstar works. Every six months or so the dirty bit got set and itran Autochk after the weekly reboot. It always took 48 hours (yes, 2 days!) to run, although it never found any problems.

This is a well known problem and the MS Q article on it just explains over several pages why no one can predict how long itcan take. So beware.

This discussion is closed to new replies.