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.
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.