Disaster Recovery for the masses

Most organisations, even SMBs, have some sort of plans to deal with recovery from disasters, whether system failure, power outages or loss of a building. But few have fully documented plans that have been tested. And even when measures have been taken, IT 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?

A recent report by Freeform Dynamics ‘The Democratization of IT Disaster Recovery’ looked at how developments in the IT landscape that have taken place over the past few years may well make it possible for you to broaden the scope of systems you provide with DR capabilities. (Figure 1)

Click on chart to enlarge

Figure 1

Advances in Networking, virtualisation coupled with a growing maturity of cloud and hosted services could provide your organisation, be it large or small, with the ability to extend DR to a much wider range of applications than has been possible in the past. 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.

The starting point for any review or improvement initiative to expand DR is getting an accurate catalogue of the applications you are running. This sounds simple but few organisations have an accurate understanding of the software and services used, and even fewer know how important each is to the business, and hence in which order IT DR could or should be extended.

With this information available, the next step is to establish the desired recovery time objectives (RTOs). Clearly 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 you may be able to utilize 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 working through your application and service portfolio and setting new objectives based on shifting cost and complexity lines, as well as the escalating demands of your users. 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. The paper covers all of these areas, and more, in greater detail.

This is certain to interest your 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 solutions 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?

CLICK HERE TO VIEW ORIGINAL PUBLISHED ON

Tony Lock

Click here for more posts from this author

Tony is an IT operations guru. As an ex-IT manager with an insatiable thirst for knowledge, his extensive vendor briefing agenda makes him one of the most well informed analysts in the industry, particularly on the diversity of solutions and approaches available to tackle key operational requirements. If you are a vendor talking about a new offering, be very careful about describing it to Tony as ‘unique’, because if it isn’t, he’ll probably know.