Implementing and testing a disaster recovery (DR) plan is a huge undertaking. Typically, the number of people involved in developing, documenting and testing a DR plan is proportionate to the number of people at the company and the number of people in the IT group. Unfortunately, there are almost always fewer people than necessary to get the job done.
As a network professional, you need to be prepared to contribute to creating and testing the DR plan, or helping to modify it if one already exists. Non-network people rarely take the network into account when they develop a DR plan. They assume that the network will be there and be functional, even in the event of a catastrophic occurrence.
This makes your job more challenging because the expectations are already set high. To help ease that burden, you first need to make sure you get involved in DR planning. We have developed our network professional's guide to disaster recovery to assist you in this complex task.
The basics of disaster recovery
Before we go into what you, as a network professional, need to know, let's cover some basics of disaster recovery.
First off, there is always confusion between business continuity (BC) and DR. "Business continuity" means that you are just trying to get by until your business infrastructure can be repaired. "Disaster recovery" means that you want to restore the business infrastructure much more quickly. This may mean that larger organisations with critical IT infrastructure have no downtime and are instantaneously providing all business services when a disaster strikes. These terms are often combined into the acronym "BC/DR." Of course, disaster-recovery plans must take into account all business infrastructures, not just IT infrastructure.
A DR plan must be created to plan for the recovery of infrastructure and personnel. Many times, this can be done with a computerised program. For example, my company uses Strohl's LDRPS software to create and maintain our DR plan.
Part of creating that plan will be to determine the criticality of infrastructure and the acceptable amount of downtime. To do this, business impact studies and risk analysis are performed. These studies rank the criticality of infrastructure and staff to help you determine what to recover first or whether there are pieces that do not require recovery.
What can the network professional do to contribute to DR?
In general, the network professional must first be involved in the DR planning phase. The authors of the DR plan need to keep the network in mind when it comes to network applications. (Are there any non-network applications left?)
Network professionals must remind others of the importance of the network in their day-to-day business. This puts me in mind of Cisco's advertising campaign reminding us of "the power of the network."
When it comes to a DR network, obviously, the quickest way to have it available is always to have it up. I have always veered away from DR offerings that say they will "bring up your DR network when you declare an emergency." Instead, I favor a DR network that has the following traits:
- One that is always up and which you can ping any time of the day or night
- One that you can test any time the server/application people can make it happen
- One that has full connectivity to all company locations at the same speed as the production network
Of course, you have to weigh your company's budget against the cost of the ideal DR network. However, the company must take into account the business-impact and risk-analysis studies when considering how much to pay. If all senior managers say that they need email access within one hour of a catastrophe, then the money needs to be found to support the network and server resources to make that happen (or those managers must be told that the money will not be forthcoming).
Continue reading our Disaster recovery checklist for the network professional.
About the author: David Davis (CCIE #9369, CWNA, MCSE, CISSP, Linux+, CEH) has been in the IT industry for 15 years. Currently, hemanages a group of systems/network administrators for a privately owned retail company and authors IT-related material in his spare time. He has written more than 50 articles, eight practice tests, and three video courses and has co-authored one book. His Web site is HappyRouter.com.