Today, digital data is at the core of any organisation. As such, data is a key asset that must be protected. All businesses, regardless of size, should secure their data and various technologies are available to provide solutions to such a requirement, backup being the most prevalent. However, having a backup policy is simply a means to an end; backups are performed so that data can be restored in the event of an incident resulting in data loss. These can be done manually, or by using a cloud backup software. When the need arises, it is crucial that data can be recovered in a usable, relevant state and timely manner. Therefore, a Disaster Recovery Plan (DR Plan) is essential.
What is a disaster recovery plan?
A DR Plan is a structure for how to restore systems, primarily data, to a functional state. It cannot be prescriptive; the circumstances that lead to data loss are of the moment and therefore cannot be entirely anticipated. Rather, the DR Plan is a framework consisting of information sources and procedures that state clearly and concisely the priority activities that need to be undertaken, and the stakeholders that need to be involved in the recovery process. Your disaster recovery plan should be a living document that changes over time to reflect both business strategy and the results of previous incidents – real or simulated.
Why DR plans matter
When a disaster occurs, the situation is pressurised. Depending on the extent of the damage, normal business activity could be severely disrupted. In such an atmosphere, there is a high degree of expectation on the IT Department to implement a swift resolution. Such conditions are typically not conducive to rational thinking or actions. An IT disaster recovery plan provides the focus and direction needed in these moments by guiding the response of the requisite teams to the matter at hand based on at set of objectives.
The cost of downtime
The impact of data loss can be considerable. In extreme cases, it can cause businesses to fail. That is a very high price to pay for an inadequate data protection strategy. Putting a value on data loss is challenging, but it is a worthwhile exercise for any business to consider the implications of data being unavailable at vital moments in their workflow.
There are two primary factors in quantifying the impact:
- Productivity losses – affecting individuals or groups and their ability to complete their job tasks.
- Business losses – affecting transactions and customer relationships.
You will need to consider what productivity and business losses you are likely to face in the event of a disaster, scaling them from minimal to severe losses if possible to help prepare for any level of disruption.
RPO and RTO Definitions
In data recovery scenarios, there are two decisive timelines; the maximum tolerable period of downtime and the amount of data loss expressed in time. The former is perhaps more obvious; businesses have a finite window of opportunity to restore operations before the impact becomes severe. This timeframe is widely referred to in the IT industry as the Recovery Time Objective (RTO). A business must understand the acceptable time limit within which services can be unavailable. This Recover Time Objective is what your IT disaster recovery plan should work towards, meaning that all systems should be restored to full working order before the timeframe is over.
Expressing data loss in terms of time is less apparent. However, for any organisation it is necessary to consider its tolerance to downtime. In the aftermath of an incident, data can only be restored up to the moment at which it was last captured. The extent of the gap between then and now is decisive; it represents the period within which the business most survives and is commonly referred to as the Recovery Point Objective. This means that your Recovery Point Objective is where you want to restore your systems from, instead of how long it will take you to do so.
The smaller the window of time that can be tolerated, the more sophisticated the data protection strategy needs to be.
What should disaster recovery plans consider?
There are certain key elements that should be present in any meaningful document:
- Accurate contact information – how and where the relevant participants can be reached.
- Roles and responsibilities – chain of command; who is doing what, where and when
- Supply Chain – vendors, insurers, legal
- Step-by-step guides – scripts/procedures that direct recovery actions
- Asset inventories – equipment details, including network diagrams
- Infrastructure – alternative sites, telecommunications and power requirements
- Messaging – what to tell customers and creditors and when and how to do so
Importance of testing and updating?
Perhaps as important as creating a DR Plan is ensuring it is regularly tested. Disaster Recovery Planning should not be a top-down process where attempts are made to write a definitive guide to recovery for any eventuality. The reality is that actual situations are more complex than envisaged. If a DR Plan is written and not tested there is a very real risk that it will fail when most required. In fact, failure is an essential part of the learning curve and how robust plans are derived. This may seem counterintuitive but, for Disaster Recovery Planning to be effective, it needs to be an adaptive process driven by finding and addressing fault; that means testing and refining procedures in response to the results of incidents. The implications of such an approach are that investment is required to create copies of live data and systems that can be sacrificed in mock disasters. Nevertheless, this is money well spent if it heightens the “state of readiness” to combat data loss.
To start creating your own DR plan, you can use cloud disaster recovery plan software to help align business assets and build an inventory, or you can use a disaster recovery plan template to fully understand what needs to be included. Either option will ensure that your plan contains everything it should, and then you will be ready to test it and make sure it works. If it fails, revisit the plan and note down what failed and why, and then edit the plan to show a solution to that issue and retest it. You should always keep a log of the changes made and issues faced when updating your IT disaster recovery plan to make sure you aren’t suggesting a fix that has already been tested and failed.
See how our disaster recovery services can help you.
See related articles
