Most organisations, even small ones, have some kind of plans in place to help their operations recover from disasters, whether that be system failure, power outage or the loss of a building.
Yet few have fully documented plans that have been tested.
And in the majority of cases, even when measures have been taken IT disaster recovery (DR) tends to cover only the most important, mission-critical applications and services.
But with users and business processes now heavily dependent on IT systems, isn’t it time to think about extending DR to a much wider range of applications?
Developments in the IT landscape over the past few years could mean it is now possible for organisations to broaden the scope of the systems they protect with disaster recovery capabilities (see figure below).
Advances in networking and virtualisation, coupled with a growing maturity of cloud and hosted services, could provide organisations, large and small, with the ability to extend disaster recovery to a much wider range of applications than previously possible.
When modern data protection and management software are added to the mix, worries about cost and complexity – the usual inhibitors of IT DR – can become controllable.
Expanding a disaster recovery plan
The starting point for any review or improvement initiative to expand DR is getting an accurate catalogue of the applications a business is running.
This sounds simple, but few organisations have an accurate understanding of the software and services they use, and even fewer know how important each is to the business, and hence in which order IT DR could or should be extended.
Download premium content on disaster recovery
With this information available, the next step is to establish the desired recovery time objectives (RTOs).
Systems running Tier 1, business-critical applications are likely to need fast recovery times in the event of any disaster, while other systems may have less rigorous requirements.
Depending on the business importance of different services, organisations may be able to use a number of "hot", "warm" or "cold" standby recovery solutions.
Modern data protection systems, network connectivity and cloud solutions combine to provide cost-effective options able to meet many, if not all, DR requirements.
It is therefore worth organisations working through their application and service portfolios and setting new objectives based on shifting cost and complexity lines, as well as the escalating demands of your users.
Implementing DR effectively depends on using the right technology, possibly in conjunction with cloud services, and implementing robust operational processes with as much automation as possible
Tony Lock, Freeform Dynamics
In addition to the RTOs mentioned above, other matters to consider include the recovery point objectives (RPOs), security and compliance matters, as well as the need to automate DR as much as possible.
This is certain to interest line of business managers charged with keeping their departments functioning at all times, who may well find themselves under pressure from external regulators to be able to demonstrate adequate business continuity and DR arrangements.
But while things have become a lot easier and cheaper, implementing DR effectively is still not a trivial matter.
Success depends on using the right technology, possibly in conjunction with cloud services, and implementing robust operational processes with as much automation as possible.
This will translate into obtaining suitable tools that are functionally capable but which also have best practices embedded in them in the form of templates, policies and so on.
Such systems should also be capable of automating both data protection workflows and, more importantly, disaster recovery processes.
When did you last look at the applications you support and the DR capabilities you have in place for them? Too long ago?
- For more on disaster recovery, see Freeform Dynamics’ report: The democratization of IT disaster recovery.
Tony Lock (pictured) is programme director at analyst group Freeform Dynamics.