That annual DR test is already a failure
Being able to continue business operations in the face of disaster is of crucial importance, and IT decision-makers know it. They may not like to think about those worst-case scenarios, but it's understood that the failure of crucial infrastructure and applications can have dire consequences. That's why disaster recovery procedures need to be thorough.
A survey of 5,600 IT managers from around the world bore this out. High availability/disaster recovery was a top IT priority for 45% of the IT executives surveyed by replication-software company Syncsort -- second only to security.
An issue of such importance is surely at the forefront of daily IT operations work, right? Well, not quite.
Disaster recovery procedures tend to be worked on intermittently. Some organizations conduct only an annual test. If they are subject to particular regulations from outside authorities, they'll do just enough to stay in compliance. Otherwise, disaster planning is often relegated to get-to-it-later status.
Even when disaster recovery (DR) planning and testing is conducted, it's typically handled as a project. Start on this date, identify and work through the problems, finish by that date. Then, attention shifts elsewhere. But if DR readiness is such a crucial element to business continuity, its importance ought to be elevated. And it can be.
Now that virtualization and automation technologies are so readily available, frequent DR testing is less difficult -- and less costly -- than it once was. Applications, for example, can be isolated and tested without disruptions to the full IT infrastructure.
In this handbook's lead article, IT expert Alastair Cooke examines these issues. He suggests ways that organizations can effectively integrate disaster recovery procedures into operations teams' regular workflows.
If, after all, disaster avoidance is so crucial to business continuity, then maybe it's time for DR testing to become central to day-to-day IT operations.