2 August, 2017
On the Edge... of Disaster
The need for disaster recovery and the testing of these mechanisms has become a pertinent issue for every small, medium and large organisation, who are increasingly reliant on technology.
What is a Disaster Recovery Plan?
Disaster Recovery Plan (DR) is an area of security planning that aims to protect an organisation from the effects of significant negative events. DR allows an organisation to maintain or quickly resume mission-critical functions following a disaster.
A disaster can be anything that puts an organisation's operations at risk, from a cyberattack, website failure to equipment failures and even natural disasters. Anything that can affect the organisation’s IT. The goal with DR is for a business to continue operating as close to normal as possible. The disaster recovery process includes both planning and testing.
When it comes to business, there’s no point in having a plan A unless you’ve got a plan B. While plan A might be the route to profits, plan B is the means of surviving, whatever challenges you come up against.
Every business is at risk of potential natural or man-made disasters. Despite our wishful thinking, sometimes the dreaded ‘what if’ scenarios become a harsh reality. While we all hope for the best, it’s essential to prepare for the worst. Then there are minor interruptions which, with adequate forethought, can be circumnavigated completely.
How to Test Your Disaster Recovery Plans
Disaster recovery testing helps ensure that an organisation can really recover data, restore business critical applications and continue operations after an interruption of services. In many organisations, however, DR testing is neglected simply because creating a plan for disaster recovery can tie up resources and the plan itself, once completed, is seen as the solution.
If an organisation doesn't invest time and resources into testing its disaster recovery plan, however, there’s a very real chance that the plan will fail to execute as expected when it's really needed. Communications, data recovery and application recovery are typically a focus of all disaster recovery testing. Other areas for testing vary, depending on the organisation's recovery point (RPO) and recovery time (RTO) objectives. This should include testing the process (manually or automated) to recreate lost transactions.
Disaster recovery tests should be conducted regularly throughout the year and be incorporated into all planned maintenance and staff training. Once a test has been completed, audit logs and other data should be analysed to determine what worked as expected, what didn't work as expected, what changes need to be made to the DR plan's design and what tasks need to be scheduled for re-testing. The details relating to tests should be well documented. This will allow you to analyse properly and modify your plan accordingly.
The DR needs to be reviewed, revised and re-tested if significant changes are implemented in business processes or infrastructure.
There are several ways to perform disaster recovery tests, these are detailed below:
Paper test: Individuals read and annotate recovery plans.
Walkthrough test: Groups walk through plans to identify issues and changes.
Simulation: Groups go through a simulated disaster to identify whether emergency response plans are adequate.
Parallel test: Recovery systems are built/set up and tested to see if they can perform actual business transactions to support key processes. Primary systems still carry the full production workload.
Cutover test: Recovery systems are built/set up to assume the full production workload. You disconnect primary systems.
The importance of disaster recovery and the testing of these procedures is paramount for all businesses large and small. The cost of implementing a robust disaster recovery plan is a major factor for many smaller businesses and this is often outsourced to specialised companies. In summary, complex IT systems do fail from time to time, but smart organisations have the people and processes in place to recover quickly.
By Alan Duncan and Sharon Robertson, Senior Test Analysts at Edge Testing
Back to Blog