It must be Thursday. I never could get the hang of Thursdays.

One of the most frustrating things for me personally is the hype that surrounds cloud and the way it overshadows the true benefits and issues of a cloud model. I am sure I am not the only one who is greeted with so much eye rolling when I mention the word cloud that it feels like I stepped into bad movie about exorcism.

But that doesn’t mean that no one cares about cloud, I wouldn’t have a blog if that were true. Disaster Recovery is a perfect example of where people start to listen to talk about cloud models, after all, if you subscribe to only one cloud-based service, there is a good chance its a DR one. Disaster Recovery is one of those services that highlights the reasons that cloud isn’t going anywhere, but it also puts the complicated learning curve of cloud in the spotlight.

Disaster Recovery (DR) is becoming more and more critical, most dominantly in the SMB market where IT resources are limited. A full-fledged DR plan that leverages the cloud offers a flexible alternative to organizations bundled with a attractive usage-based model (remember, the whole point of DR is that you don’t want to have to use it except in emergencies), which means that it comes with a small pricetag. This means that aside from having an opex-based DR plan, it reduces the need for data centre space, infrastructure and IT resources to manage it, all of which help smaller (and larger) organizations save costs and gain access to leading-edge technologies that would normally be only in the financial reach of larger organizations. The conversation suddenly moves from data centre space planning to cloud capacity planning.

But like any modern service, there are concerns with adopting a cloud-based disaster recovery plan. For starters, the security around a cloud service becomes increasingly important as the resources become more business-critical. Is the provider able to prove they meet regulatory requirements? How do they control access to resources (passwords? Two-factor authentication?) and ensure the data is being transferred and stored in a secure manner? Does the customer have the right bandwith and network resources to enable all users access to the resources in the case of a disaster, while allowing your internal teams to access the data and get internal systems up and running again? Do you have the right in-house expertise to manage the restoration of systems, and how long will it take?

Ofcourse it really comes down to a single question in the mind of the customer when deciding which DR service they should subscribe to: If something happens to take my entire system down, can I trust my provider to help me get back up and running as soon as possible before significant damage is done?

Reliability, availability and the ability to keep users up and running during a disaster is the single most important benchmark a provider will be measured against. The wrong decision can cripple an organization, cause significant damage to its reputation and lead the key stakeholders in hot water.

But it isn’t as easy as signing a DR service contract to protect the organization in the case of an emergency. The key reason is that every organization is different; the types of applications, data and users are all unique. This means that each DR plan needs to be written specifically for each individual customer and need to include key processes that address and prioritize applications, data and services, and give each a time window in which to bring them online before significant organizational impact is felt. By prioritizing these resources, the customer and the DR provider can create recovery time objectives for each resources that will be included in the disaster recovery plan.

The customer is then required to ensure that all key applications and resources are covered under this plan to reduce operational impact in the event of an emergency. It is recommended that the customer also perform regular testing and reviews of the plan to ensure any changes to the business resources are captured in the document to avoid any oversights as new systems are brought online. Once the recovery time objectives are established, the customer would have a better idea of specifically what types of services should be leveraged as they relate to DR. Don’t assume that only one type of DR method will be used for all resources, as it will be more likely that depending on the criticality of the application or resource to ensuring business continuity, the resources will be grouped and its own DR method assigned.

Tomorrow I’ll cover types of cloud-based disaster recovery options, so stay tuned for part 2!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s