The east coast is experiencing the tail end of a very large storm named ‘Sandy’. We all had plenty of time to prepare for the storm, but did we? Individually, we probably did, but what about our data? Those 24/7 critical processes to allow our customers to view and respond to the data our organizations provide? We were lucky—we had no issues during the storm, but now we await issues during storm clean up. So how do you prepare for such disasters? Do you move to the cloud?
Large hurricane-class storms are grounds for review of any and all disaster recovery plans as well as an opportunity to make new ones. Perhaps it is also the incentive to move to the cloud. But what type of cloud should you consider? What are the options, and why choose one over another? There are three types of clouds that make sense to use before any disaster strikes.

Move to the Cloud: Replication Receiver Clouds

These types of clouds receive replication from their customers to store the customer data remotely with multi-tenant access to the data. They also make it easy to recover anywhere from the receiver cloud. In essence, the receiver becomes the source, and a new receiver is named—perhaps your own data center once more, another cloud, or even their own cloud. Zerto, Quantum, and others have such replication receiver clouds. You pay for the storage you need. But I think they need to go one step further and provide the replication software as needed, so that those who cannot pay for the software can use it in a disaster. Granted, the cost for storage may be higher for these one-off use cases unless they convert to being a full-time user of the service. However, this allows for rental of space during a disaster and removal of said data after the disaster. I would consider this renting a short-term safety deposit box, perhaps with extendable contracts.
This approach is more ad hoc but could be part of a scenario where the user may decide, “The storm is days away; let me step up and rent the software to do the replication from the provider while paying for space as needed.” This assumes that the provider uses all those space-saving techniques to cut my costs such as deduplication, thin provisioning, etc. while encrypting the contents at rest.

Move to the Cloud: Infrastructure as a Service

The traditional cloud for remote services is Infrastructure as a Service (IaaS). Such clouds would be extremely useful during a disaster, as you could keep all your data within the cloud or use a more common hybrid approach by sharing data between your data center and the cloud. However, if you do share your data between the cloud and your data center, then during a disaster where your data center lives, you need to choose a cloud provider that is outside the reach of the disaster, perhaps far inland if you are on the coast. Even so, the problem you have is keeping all your data in sync. To do that, you may wish to look at replication tools from Veeam, Zerto, VMware, Quantum, or Quest.
Replication will be required even for IaaS, as you have the question of how to move your terabytes of data. You will either have to use replication, backup software, or direct copies to get the data to and from your cloud.

Move to the Cloud: There and Back Again

The key to using a cloud as part of your disaster recovery plans is to be able to get your data “There and Back Again”. We cannot just put our data into the cloud; we need to get it back for several reasons:

  • What if the cloud datacenter is where the disaster is taking place?
  • What if the cloud goes under?
  • What if there is a cloud outage (such as the EBS outage within Amazon?)

There are probably a few more really good reasons for getting your data “There and Back Again.” As you move to the cloud, you should realize that your organization is responsible for the safety and availability of your data, not your cloud provider. Because of this responsibility, the data owner must be able to access their data at anytime. So therefore, “There and Back Again.”

Conclusion

Storms like ‘Sandy’ should be a time to sit back and review all your disaster recovery plans. Perhaps you, like us, were relatively unaffected, but think of the worst that could happen and plan accordingly. Moving to the cloud could be the simple choice of providing as-needed DR capability, but always remember the cloud is not the data owner and therefore not responsible for your data; you must get it “There and Back Again” while maintaining security. I know we will be reviewing our DR plans, taking into account the breadth of Sandy’s onslaught.