How can Organizations Plan Disaster Recovery Better?
The perception that IT infrastructure is a cost centre, is gradually changing, with organizations realizing that it is, in fact, a market differentiator. Data being paramount in today’s digital age, companies have begun to focus on data recovery (DR) planning. It is no longer viable to hastily go about any data recovery plan that would inevitably result in failures and testing pitfalls.
The need of the hour is: a keen, unwavering eye on business continuity planning (BCP) and a shared vision between the business leadership and the IT management. Any DR planning should ideally begin with business impact analysis.
Most DR planning exercises require businesses to clarify the recovery point objective (RPO) – where to store the recovery data, and recovery time objective (RTO) – how fast can services be restored after a disaster.
Here are 10 key considerations for infrastructure architects and business leaders to keep in mind before they chalk out a disaster recovery plan.
Classify information systems
The key to any organization’s successful DR plan lies in classifying its rich information systems and applications. A business impact analysis should clearly define information systems as mission critical, business critical, or just business support. Classification helps define policies such as back-up, retention, archival and so on, that is crucial for business continuity.
Classify data
Today, data is not just records, in spreadsheets or computational data. Today’s evolved data represents e-mail, text messages etcetera; to acting as informational currency as in the case of the Internet of Things (IoT) applications and blockchain networks. However, not all data is mission critical, and therefore, it is crucial to classify data and prioritize it for retention, retrieval and archival.
Choose DR location
With earthquakes, floods, tsunamis, forest fires, tornadoes, hurricanes and many such disasters, Standards such as BS25999-2, ISO 22301, ISO 27001 and NIST SP 800, typically do not recommend the actual distance between primary and DR sites. This is because the distance is subjective to the type and level of disaster and companies should choose the location that suits their business models, regulatory requirements, and revenue.
For instance, for those companies that are heavy on customer-facing online applications, it is in their best interest to look at large distances between the primary and DR sites. Smaller companies can look at data recovery-as-a-service (DRaaS) to cut costs.
Be value-driven
Organizations typically don’t want to spend on DR readiness as they don’t know when a disaster would strike or have never been subject to one. However, with increased awareness and the promises that it can deliver, business owners have begun to gain more confidence to see how to rescue businesses from disasters. When the C suite sees the value that a DR readiness program can offer, they are willing to pay.
Guard
Hackers extort money from businesses through ransomware or cryptolocker techniques, resulting in major losses to organizations. Software vendor Kaspersky reported that in 2016, one in five ransomware victims who paid, never got their data back! While the best way to protect businesses against such threats is to keep systems patched and up-to-date to guard against all viruses, a comprehensive DR plan can help in a big way.
Document
A structured documented approach to DR planning is a must. It should cover all details such as physical and logical architecture, dependencies (inter, and intra-application), interface mapping, authentication etc. While recovering individual servers are documented, a holistic technical recovery plan for each application/service with the sequence of all activities is crucial to avoid disasters.
Test
An untested DR plan is only a strategy. Though most organizations have a DR plan and feel guarded, the plans are not often tested to identify gaps or challenges. Thoroughly testing the DR plan is the only way to unearth issues such as hard-coded IP addresses, host file entries, license files, configurations, dependencies etc., which will necessitate updating the DR plan. While all key business applications cannot be tested during a DR drill, it is important to focus on recovering applications and services, and not just servers.
Evaluate
Subscribing to the number one DR product in the market doesn’t mean that it will fit an organization’s unique needs. While it might seem wasteful to invest in a passive data centre, distributing the workload, and having an active data centre strategy might work well depending on the location of users.
Another smart way is for organizations to consider DRaaS solutions that bill according to usage.
Trying it out will help better judge the needs. Before finalizing a DR solution, a proof of concept is advised.
Set expectations
Before embarking upon a DR plan, it is important to get an official sign-off from the business owners and other key stakeholders. It is important to have a meeting to explain an overview of the plan, and the scope of applications and services covered, to help business owners decide better on the DR plan and approach. An in-depth discussion also helps in early course correction and better management of costs.
Like with other business initiatives, it always makes sense to start small at the application level and then build the entire picture when it comes to DR planning. The initial focus could be in developing a technical recovery plan for a particular business application. When the organization successfully completes a few of them, a clear DR plan would unfold.
In many ways, a functional DR plan serves as an organization’s insurance plan to eliminate costly downtime, maintain market share, and guard their reputation. Though painstaking, a well thought out and implemented DR plan is the wonder shield that protects any company’s digital assets against disasters and uncertainties.
-- Venu Lambu, Global Markets Leader, Cognizant Infrastructure Services.
