Backup is just good policy. You need the ability to back up data and applications someplace, so they can be restored somehow, to keep the business running in case of some natural or manmade disaster that takes the primary business-critical systems down.
We have whole industries that provide backup sites and backup technology. They can be passive, meaning that you can restore the site in a short period of time and get back to operations. Or they can be active (which costs more), meaning it can instantly take over for the disabled systems with current data and code releases—in some cases, without the users even knowing.
In the cloud, disaster recovery inolves a new set of choices that don’t look much like the ones you have for on-premises systems. The approach that you take should represent the value that the applications and data sets have for the business. I suggest that you look at the practicality of it all, and also make sure that you’re not spending more than the disaster recovery configuration is worth.
Option 1: Region-to-region disaster recovery
You can set up two or more regions in the same public cloud provider to provide recovery. So, if the Virginia region is taken out, there are other regions on the country that take over.
You can pay to have exact copies of the data and apps replicated to the backup region, so they can seamlessly take over (that’s active recovery). Or you can use more cost-effective approaches, such as scheduled backup to passive mass storage, to stand up the other region quickly (that’s passive recovery).
Option 2: Cloud-to-cloud disaster recovery
The most common question that I get is: What if the entire public cloud provider is wiped out, or in a long-term outage, how can we protect ourselves?
Using one public cloud to provide backup to another public cloud would let you, for example, use Amazon Web Services to back up Azure, go the other way around, or do some other pairing.
While this seems like the ultimate in disaster recovery—and in hedging bets—doing multicloud just to support disaster recovery means keeping around two different skill sets, having two different platfiorm configurations, and other costs and risks.
Ongoing cloud-to-cloud system replication (aka intercloud replication), increases the chance that things will go wrong. That’s not what you want when trying to replicate the primary and backup platforms. While not impossible, intercloud replication is five times more difficult than intracloud replication within the same provider. That’s why intercloud support is almost nonexistent, outside a few clever consultants.