As disaster recovery automation has developed so have various viewpoints about constraints which hold back organizations when attempting to use this approach. Here Chandrasekar S highlights ‘six DR automation myths’ and explains why they are misconceptions.
Automation cannot extend up to the business process level
Traditional disaster recovery tests only cover validation of the IT infrastructure and applications in the recovery site. These tests do not provide information on which business processes have been tested and the readiness of that business process during a DR scenario. Business and CXO leaders would be more interested to see information on the readiness of the complete business process as opposed to application or infrastructure level test entities. The DR test reporting dashboard can provide dynamic reports any time for a quick status check on where the organization is heading in terms of implementing a robust business continuity program.
Recovery time objectives cannot be optimized beyond a point
There is a general misconception among IT leadership that automation can only improve your recovery time objectives by a small margin. It has been proven in multiple organizations that through proper automation and orchestration, the recovery timelines can be optimized by up to 50 percent with failovers and failbacks managed by a click of a button. When applications and their infrastructure are configured for automated failover, there is no loss of time spent on pre-requisites checks and manual failover procedures.
Integrated disaster recovery testing cannot be performed
Unless an organization performs regular recovery tests, the effectiveness of a disaster recovery program cannot be justified. Often there is a challenge to IT leadership that automation does not permit to perform selective DR tests for a subsystem of application or it doesn’t permit to perform an end to end integrated DR test. Automation has proven that DR tests can be performed without disrupting the production environment or the production data. Integrating cloud and on-premise DR solutions is also possible.
DR automation is not suitable for multiple technology environments
In today’s IT landscape there are no single platform or single vendor systems anymore. Organizations adopt multi-vendor / multi technology architectures to suit business requirements. But there is a belief among IT administrators that automation and orchestration does not cater to platform or vendor agnostic systems. Automation has bought in tools which can failover and failback between different hardware systems e.g. physical to virtual, EMC to NetApp, VMware to Hyper V. Irrespective of the type of hardware or software, replication can be configured between multiple technologies and automation bridges this gap. It is also possible to recover legacy systems on par with the latest technologies and these can be integrated together during an end to end test.
Managing recovery workflows with changing environments is difficult
Traditional disaster recovery tests involve execution of recovery procedures by each technology stack followed by validation. Workflows tend to automate the execution of these procedures across the technology stacks by configuring them in the form of a script. Workflows help to achieve speed, accuracy, avoid human error, and maintain the consistency of recovery. These workflows can be modified and changed as per the scenario of the test and the test methodology. In fact, these is also an option to integrate the automation tool with the enterprise voice and email systems to send out notification / critical communication to the appropriate stakeholders and provide a status report on the progress of the tests. These workflows are managed centrally and can be configured either completely automatic or manually. Periodic checkpoints can be configured in these workflows to report the status, issues faced, elapsed time and can ask the user for a confirmation to proceed to the next step.
DR automation results in inefficient DR documentation and governance
Disaster recovery automation helps to manage the complete area of documentation both at a process level and at an application or infrastructure level. This will help to reduce documentation man hours and remove dependency on the format, templates, and manual edits. The entire failover and failback process for an application can be configured as a workflow in the tool along with the required time. This can be extracted at any point of time and reviewed whenever required. Test and governance reports can be extracted at any point of time giving a holistic picture of the disaster recovery program. These reports in turn will help during audit and compliance programs.
The author
Chandrasekar S is Senior Technical Lead at HCL Technologies. Contact him at chandrasekars@hcl.com
