Thanks to the power of nature, most of the Toronto area got a bit of a taste of what our friends out in Alberta dealt with a few weeks ago. Not as extreme, but with a blackout that took out a good chunk of power to the suburbs for a few hours, and a downtown core still cleaning up all the water damage, it’s a great time to discuss disaster recovery and telecommuting.
Sadly, it looks like this kind of weather is going to be a more constant occurence. Blame it on global warming, conspiracy theory or a cranky mother nature, in either case, I can’t stress enough the importance of having a business continuity/disaster recovery plan. But when you insert cloud into the equation, things get a little tricky.
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 and ensure the data is being transferred and stored in a secure manner? Does the customer have the right bandwidth and network resources to enable all users’ access to the resources in the case of a disaster, while at the same time 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 most importantly, how long will it take?
It really comes down to a single question 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?
Choosing a DR partner based on cost is probably not going to be the wisest decision here.
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. 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. No cookie-cutter SLAs here. By prioritizing these resources, the customer and the DR provider can create recovery time objectives for each resource that will be included in the disaster recovery plan. You also don’t want to be rushing an SLA through legal when you are in the middle of a DR crisis, so planning in advance is highly suggested.
As the customer, it is your responsibility 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 you 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, you 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.