Disaster recovery, business continuity, backup and restore – whatever you call it, it needs to be ready for anything. A recent study from IDC found that just one third of the organisations interviewed could recover more than half their systems in real time. Worse still, only one in every nine believed they could restore ANY systems in real-time. In other words, most businesses would suffer a massive operational hit in the event of a disaster.
So, what can you do about it? Here are eight tips for designing an effective disaster recovery plan.
Do an inventory of your major hardware and systems and rank them in terms of business criticality. If your business involves logistics then keeping the pick, pack and dispatch cycle running might be more important than the executive reporting dashboard.
Work out which applications need to be restored first, document it and get executive sign-off. That way you won’t lose time arguing during the incident.
2. Assign disaster recovery managers
When an incident occurs, it’s likely that people will be scrambling to work out what works and doesn’t work and to get their systems operating. Having a designated person whose role it is to coordinate the incoming information and report to the C-Level will facilitate that coordination and communication.
If you work in a multi-site business, have a designated site recovery manager (and a backup person) at each site.
3. Assign responsibility
Assign a responsible and backup person for every application and system. Their role will be to liaise with users and the Disaster Recovery Manager to let them know what is going on.
4. Prepare a communication strategy
Every person with a role in the disaster recovery strategy needs to have a full set of contact details for the rest of the team. There are lots of ways to do this.
While it may seem a little archaic, having a card with all the names, phone numbers and email addresses is simple and will not run out of batteries at a critical time. Also, they’re easily updated and distributed.
If you have a system in place for pushing the information to the team’s mobile phones and notebooks, this is worthwhile but a contact card that fits into a wallet is less likely to let you down. Also, setting up a permanently available teleconference line that your team can use will make it easy to convene a virtual meeting if the team isn’t all in the same place at the same time.
5. Disaster recovery office
Many companies plan for system outages, keep backups offsite and test their data recovery. This is important but it presupposes that you’ll have access to your site. The recent earthquakes in Christchurch and northern Japan, while extreme events, highlight that you may not have access to your office.
Chances are that you’ll have business associates with offices not too far from your own. Look at making an arrangement where you’d have access to a large meeting room and internet connection so that you can establish a “war room” in the event that you lose access to your own office. This can be a “contra” arrangement where you’ll do the same for them.
At least a couple of times each year, practice your disaster recovery processes. Create a fictitious scenario and check that your notification and communication processes are working as planned.
Restore backups and actually test any contingency arrangements you have put in place.
7. Design for disaster
When we design and implement our systems we rarely plan for disasters but cloud-based technologies can be used as a method of risk mitigation as well as from a cost management point of view.
When building a deploying systems look at how that system can be accessed from outside the firewall, whether it works well via a web connection and whether you really need it deployed within your data centre.
8. Document everything
Once you’ve put your solution together make sure it’s all written down and distributed to all the people involved in the plan.
Like the contact details cards, print the plan out and have members of the disaster recovery team keep a copy of the plan at home and in their bag.
This was first published in April 2011