What Every Disaster Recovery Plan Must Include

Business continuity (BC) and disaster recovery (DR) are not the same thing, although there are some common characteristics. A BC plan is designed to include all departments in a company, but a DR plan is often focused on restoring the IT infrastructure and related data.

“A disaster recovery plan is an essential IT function and if not in place could result in company bankruptcy or severe reputational damage when data cannot be restored”, Przemysław Jarmużek, technical support specialist at SMSEagle. The financial costs involved are just another factor, he added.

What elements of a disaster recovery plan cannot be omitted? What’s the purpose?

Few company owners are psychics but things like insurance and DR plans reduce company risk, providing a framework for companies that allows rapid recovery of data and/or replacement of key hardware/software components.

Know your Network

Your company network administrator must have more than a fair idea of the software and hardware that are currently part of your network. Therefore, an ongoing inventory list is essential, most of which can be achieved by using network monitoring and auditing tools. These will allow a comprehensive list of computers connected to your network and the software on each. Note that license management is another part of this inventory control process and additional hardware is also added where appropriate. This additional hardware could include multifunction printers, hubs or routers and anything else that is needed for network functionality. Consider this inventory as your shopping list when disaster strikes. It is also worth noting which items have a long lead time (servers, for example). Creating an inventory of spare parts is a good idea and could save the day when disaster strikes.

Know your Disasters

It is pointless to instil fear in company owners about impending disasters. They are as aware of the risks as we are. Each company will have its own risks. Many of these risks are directly linked to its location, whether extreme weather conditions, risks of flooding, forest fires or loss of essential services and equipment. These are the most obvious, but to lapse into management-speak briefly, why not think outside the box?

Even the Pentagon has used a hypothetical zombie apocalypse to test their response methods and maintain a working government under these conditions. Consider alien invasions and any other scenario that could conceivably or inconceivably shut down company operations. How long would it take to resume work if each scenario happened?

If your company can continue operating during a zombie apocalypse (when essential services are down) then yours is truly a robust DR plan.

Now What?

What actions will you take for each disaster type? Obviously, if there is a flood scenario, the aim is to protect equipment again water damage. Perhaps placing all equipment high above the floor is a solution but how high is necessary? Given that you have drafted a list of possible and impossible scenarios, make sure that your solutions to each one is well documented, logical and possible at short notice. Bite the bullet and purchase or modify the equipment necessary to protect your IT infrastructure.

Unfortunately, not all water damage is caused by flooding, perhaps a water tank leaks through the ceiling of your server room and casually destroys the server, firewall and 24-port hub before you can move the server rack. How long will it take you to restore the server and network? Do you have a spare server, firewall and hub? In this scenario, a company is caught unprepared, unaware that water is stored above their equipment. Know where all water is stored and dispersed throughout your building and avoid such problems.

From this simple example, you must focus on minimising risk in as many areas as possible.

Tactical Teams

When a disaster happens, the priority is to make sure that all employees are safe and to inform them of current events.  Once this task is completed, who leads the disaster response? When a disaster occurs, it is too late to leap into action, assigning responsibilities on the spot. Responsibilities and tactical team members must be assigned as part of the DR plan. In addition, if zombies eat your designated team leader, then the backup must take over. Define employee responsibilities and have backups in place in case they are delayed or incapacitated. This last item is perhaps the most important. However, to be most effective, any interruption in network service should generate an alert to multiple DR team members. This is often achieved by cost-effective (and self-powered) network monitoring devices that utilise a GSM/3G network to send SMS messages and emails as soon as network traffic stops.

In conclusion, while the above lists the key elements of any successful disaster recovery plan, it is also worth noting that an untested plan is less than useless. Test your DR plan during off-peak hours to ensure it will work when needed. Test how long it takes to restore all your data from backup. Such activities will ensure that if the worst happens, you and your company will emerge unscathed to resume your company operations.

Is your Disaster Recovery Plan Designed to Reduce Downtime?

Numerous reports, surveys and statistics confirm that commercial entities of all sizes are woefully unprepared for unexpected events. Ivenio IT stated that 54% of companies with less than 500 employees have a disaster recovery (DR) plan in place while 74% of larger companies had one. For smaller companies in the U.S., the figures are even worse with a Nationwide 2015 press release indicating that just 25% of companies with 50 or less employees had an active DR plan. Given the cost of downtime, surely we can do better?

We must as, according to Zetta’s infographic and online survey, there is much to improve, not least of which includes usage of the hybrid cloud and the fact that only 45% who experienced downtime issues bothered to make changes to their DR plans after the event.

Before delving into the benefits of a logical DR plan, an understanding of its meaning is necessary. Firstly, business continuity (BC) and DR are not the same thing, although there is an obvious overlap in business goals. BC reflects the efforts to avoid loss of service or downtime while DR reflects the response required to resume activities after the worst has already happened.

Disasters can include cyber events, extreme weather conditions, fire, flooding, loss of a key staff member, service interruptions from third parties (most commonly electricity or broadband), hardware failure and human error.

“This list is not exhaustive, and the formulation of any disaster recovery plan must include a risk analysis step in the early stages to identify potential risks that apply to your company or industry. Once risks are identified, you can brainstorm on ways to solve them immediately or at least initiative a process that will solve them in the fastest possible time”, said Radosław Janowski, product manager at SMSEagle.

Sounds reasonable, but how about an example?

Disaster Recovery in Action

Okay, let’s take a simple example to demonstrate DR in the real world. Company X is located in a commercial district and their primary data server goes down due to water damage from a leak in the ceiling. As the smoke indicates, the server is out of commission and business activities grind to a halt along with the company network.

Fortunately, Company X has a DR plan in place. The risk of server loss was correctly identified and the solution proposed was an offsite real-time backup in the cloud (in a data center that is not impacted by local power or service outages). This means that all Company X clients are unaware of a technical issue and business continues uninterrupted. Company X employees are not connected to their local server but they can also continue working using a mobile broadband option. It’s not ideal but gives the IT team (and a plumber to fix the leak) the time necessary to repair the damaged hardware and restore everything from cloud backups.

There you have it. DR in action. The disaster occurs, the DR team (usually IT) are notified automatically and the backup solution is in play while the cause and effect of the disaster is fixed.

“Automatic notification is key as any delays only increase costs. In this example, if equipment is not moved from under the leak, then instead of a single server, perhaps an entire rack (with hubs, routers, firewalls etc.) is compromised”, said Przemysław Jarmużek, technical support specialist at SMSEagle.

Automating alerts is certainly necessary, given that disasters need not occur during office or support hours.

Strategise then Plan

When designing a DR plan, brainstorming is necessary. Think about every aspect of your business and the infrastructure that supports it. Think about your service and utility providers. Think of the unexpected. Even discussing a zombie apocalypse has implications that are of benefit in a disaster recovery process, even if it relates to building security. Once you have exhausted ‘what if…’ scenarios, you are ready to offer strategies to solve them.

“Preparing for the unexpected is not a wasted exercise but makes excellent business sense.”, said Radosław Janowski, product manager at SMSEagle.

Once you define potential threats, you can then create a prevention strategy that includes response and recovery options that evolve as needed.

In conclusion, ISO/IEC 27031, the global standard for IT disaster recovery, states that “Strategies should define the approaches to implement the required resilience so that the principles of incident prevention, detection, response, recovery and restoration are put in place.”

Do your DR (for IT disasters and others) strategies follow this approach? They should.