Does your organization need a disaster recovery plan?

Many businesses, particular those that have less than one thousand employees, think that disaster recovery planning is something that is too difficult or too expensive to undertake. Another response is that of the avoider: it won’t happen to me. These assumptions have been perpetuated to the detriment of many businesses that unnecessarily failed.

Disasters come in many forms. Most people think of massive earthquakes and hurricanes. However, there are hundreds of disasters that occur on a regular basis, but they’re too localized and small to make the news. And not all disasters are ‘acts of nature’: there are many man-caused disasters that occur on a regular basis that cripple businesses just like acts of nature do.

Disaster Recovery Planning need not be expensive, and most businesses can (and should!) get started right away with even a small amount of planning that could prove highly valuable, in case the unexpected occurs.

Get the book, build the plan!

On interim DR planning

Most organizations will immediately recognize the risks associated with the absence of a disaster recovery plan. Knowing that having a full DR plan in place and tested may be more than a year in the future, many organizations will have a strong desire to have something in place while waiting for the full DR plan to be completed.

Often the something that is needed is an interim DR plan. This is a plan that can be created quickly and with minimal effort. It will not, of course, be as comprehensive as a full DR plan. It is rather like tossing a tow rope in the back of a car, knowing that major engine work is needed.

Confidence in a DR plan

Submit:

Disaster recovery plans aren’t much good if they don’t work. And if they don’t work, then the time devoted to their development has been pretty much a waste of time.

Decision makers in businesses, especially the executives, like certainty. They want to have confidence that things will go as planned. And while no one plans a disaster, they want to know that the recovery effort after a disaster will work.

The survival of the business may depend on it.

You can take your DR plan to a fortune teller, but I wouldn’t put much stock in that. Why not just try it?

– from IT Disaster Recovery Planning for Dummies

Server consolidation and disaster recovery planning

Server consolidation has been the talk of IT departments for several years, and represents a still popular cost cutting move. The concept is simple: rather than dedicate applications to individual servers, which can result in underutilized servers, install multiple applications onto servers in order to more efficiently utilize server hardware, thereby reducing costs.

I’m all for saving money, electricity, natural resources, and so on, and consolidating servers is a smart move to undertake, as long as you abide by this principle:

Server consolidation is something to undertake during peacetime, not solely for recovery purposes.

Let me expand on this. Consider an environment that is made up of dozens of underutilized servers dedicated to applications. The DR planning team wants to consider a DR strategy that consolidates these applications onto fewer servers as a way of providing a lower-cost recovery capability.

Well, it might work, but I’d want to test it very thoroughly and carefully. Combining applications that are used to having servers all to themselves may lead to unexpected interactions that could be difficult to troubleshoot and untangle.

If you want to undertake server consolidation, do it first in your production environment, and then take that consolidated architecture and apply it to a DR architecture.

– from IT Disaster Recovery Planning for Dummies

Aligning DR planning to the org chart in large organizations

Perhaps different segments of a large organization may push forward on DR planning at different rates. One’s lack of progress should not impede another. Instead, you might think of this as a DR plan for each cog in the organizational wheel. If this is how things get done in your organization, then perhaps the DR plan gets built in pieces, asynchronously. Progress has many faces.

– from IT Disaster Recovery Planning for Dummies

DR team selection

You can’t hand pick your recovery team members. The disaster will select them for you. It is for this reason that recovery procedures must be specific enough so that anyone with the basic relevant skills can carry them out confidently and correctly.

– from IT Disaster Recovery Planning for Dummies

DRP: the job is not done until the paperwork is done

The job is not done until the paperwork is done.

Nowhere is this pithy saying more true than in disaster recovery planning. Why? Because the paperwork in DRP is about how to jump-start the business when “the big one” hits. Depending upon where your business is located, the “big one” may be an earthquake, tornado, hurricane, flood, or a swarm of locusts.

The paperwork in DRP is simply this: the procedures and other documents that business personnel must refer to in order to get things going again after a disaster. The DRP procedures are especially important because they might be read and followed by persons who are not the foremost experts with the systems that support critical business processes. Still, those people are expected to rebuild critical systems in a short period of time in order to support critical process that are probably going to be performed by people who likewise are not subject matter experts at the business process level.

And the business’s survival depends on the paperwork being right. There are no second chances.

You just love documentation, right? Thought so.

– from IT Disaster Recovery Planning for Dummies

Building replacement workstations in a disaster

Submit:

The need to build workstations on unfamiliar hardware platforms requires some out-of-the-box thinking for those who are required to build replacement workstations in a disaster. Straightaway, I recommend that workstation images be very well documented, so that they can be built from the ground up on new hardware platforms.

– from IT Disaster Recovery Planning for Dummies

Gap in PC Procedure Causes Corporate Crisis

Some years back, a colleague in another organization came to me for help. In this international organization and U.S. public company, the finance department was unable to close its quarterly financial books in time to meet a S.E.C. filing deadline.

It had missed the deadline for several days, and the matter had reached the CEO and the boardroom as an uproar.

The cause: an overseas subsidiary was unable to close its books. The reason: one of the steps to the overseas subsidiary’s completing its month and quarter-end financials was a procedure wherein a financial report was downloaded to a PC’s spreadsheet program, where a spreadsheet macro would perform some calculations that would be used in the subsidiary’s financial results.

This time, there was a problem: the macro had become corrupted and would not run.

There were no backups. A contractor had created the macro and was nowhere to be found. No one in the finance department knew what the macro did or how it worked. It was an undocumented step in this critical business process; the original software was gone, and none of this was documented.

Be certain to avoid having this kind of a scenario occurring in your organization.

– from IT Disaster Recovery Planning for Dummies

Storing production data on end user workstations?

Submit:

As I encounter cases where an employee’s workstation is, in fact, on the critical path for a critical business process, the first question I usually ask is:

Why?

Warnings go off in my head when I hear about an employee’s workstation in any process’s critical path.

– from IT Disaster Recovery Planning for Dummies

Now let me tell you why I think it’s a bad idea to store production data on end user workstations:

• Workstation hard drives are not protected from failure by any RAID or mirroring technology. When the hard drive fails, the data is gone. IT servers often have RAID or mirroring, which protects the integrity and availability of the data.
• Most users don’t back up their workstation hard drives. When the data is gone, it’s gone. IT servers are usually backed up regularly.
• Most workstations have little or no power protection (plug strips hardly count). When sags, spikes, or brownouts occur, the workstation will take the brunt of this, possibly resulting in a crash or hardware failure. Sure, it’s unlikely, but it DOES happen. IT servers are usually protected by UPS and, sometimes, generators.
• Users often tinker with workstations, which sometimes results in a disabled state and/or a reboot. This happens a lot less in most IT servers.
• User workstations, particularly if they are laptops, are stolen far more frequently than IT servers, especially when they are locked up in server rooms.

Documenting PC tasks just as important as other platforms

Submit:

When business processes include tasks that are carried out on workstations, then written procedures for those tasks must exist alongside procedures for other steps in the process that take place on other platforms. All tasks in a business process must have equal formality, regardless of whether they take place on a formal IT server platform or on a user’s workstations.

– from IT Disaster Recovery Planning for Dummies