Does Your Business Document Its Disaster Recovery Processes

In previous articles on this blog, we have stressed the importance of disaster recovery planning. However diligently IT professionals try to avoid outages and account for potential failures, without a bottomless budget and infinite time it is impossible to make provisions for every potential outcome. Disaster recovery planning is planning for the unexpected, and disaster recovery infrastructure the last resort when primary systems fail.

But there is one aspect of disaster recovery that is frequently neglected: documentation. It is the role of documentation to ensure that the relevant people know what to do when disaster strikes. Comprehensive documentation helps employees to utilize disaster recovery systems and to avoid actions that may be harmful to business continuity.

Consider a case in which an employee accidentally deletes important data from a server. Human error is the leading cause of data loss. If the company uses cloud backup to replicate their servers off-site, that data is backed up and the data loss is more of an inconvenience than a disaster.

But that is only true if the employee knows where the backed-up data is stored, how to restore it, and who might be able to help them. Ensuring employees have this information is the role of disaster recovery documentation and training.

What Should Be Included In Disaster Recovery Documentation?

The contents of your company’s disaster recovery documentation depends on its processes, infrastructure, and staff, but at the very least it should include.

• Internal contact information – This should include up-to-date emails and phone numbers for managers, key decision-makers, and staff who have responsibility for disaster recovery processes.
• Service provider contact information – This should include support contact details for backup, disaster recovery, and infrastructure vendors.
• Process and engineering documentation – What is included in this depends on who the documentation’s intended audience is. It might include details such as instructions for data retrieval from backups, server reboot instructions, and process checklists for technical staff. The information to be included in disaster recovery documentation should be based on the processes and infrastructure redundancy plans developed during DR planning.

Don’t Rely On Institutional Knowledge

Institutional knowledge is a valuable asset, but it is far from infallible – especially when that institutional knowledge is in fact a single employee who was deeply involved in implementing the disaster recovery plan.

Without documentation, knowledge of disaster recovery processes depends on the availability of particular employees. With careful documentation, any qualified employee can enact the required processes and ensure that data and applications remain available.

Automate Where Possible

Automation has two key benefits: it reduces the likelihood of error, and it ensures that disaster recovery doesn’t depend on the availability of particular employees.

Automatic failover to applications and virtual machines running on disaster recovery infrastructure is the best way to ensure that DR / BC systems function as intended, minimizing disruption.

But, while automated backups and disaster recovery systems improve outcomes, they can’t completely replace comprehensive and well-written documentation.

Updating Disaster Recovery Documentation

As your business’s software and hardware evolves, so should its disaster recovery documentation. Documentation that is months or years out of date is worse than useless. Renewing DR documentation should be intrinsic to infrastructure and software planning.

Cloud backup and disaster recovery will support your business’s operations when disaster strikes, but DR documentation is an essential component of an effective disaster recovery plan.