Not every business can afford a fully functional disaster recovery location, particularly if it’s a smaller environment with a tighter budget. (Indeed, I recall a company I worked for a long time ago that resented spending money on IT, and actually moved retired production systems into its disaster recovery datacentre to ‘save money’, even though this would result in a stressful business continuity process, particularly when systems had been retired due to an inability to run growing production needs.)
While larger enterprises will look at disaster recovery of servers as a function that needs to be executed in minutes, if not seconds, other businesses do not have such robust requirements, either as a result of budgetary considerations, or simply because of their scope, and customer base.
In such cases, when a full disaster recovery datacentre could not be afforded, a common approach has been to make use of a co-location facility – i.e., renting some rack space from a datacentre, and placing just enough systems in that environment to get mission critical workloads running again in the event of a disaster.
It was inevitable, perhaps, that businesses seeking to make use of public cloud might start thinking, “can we use this for our DR?” After all, if it costs the business $50,000 per month in terms of amortised equipment costs and co-location rack space, and running mission critical workloads in the cloud for a month only costs $60,000, there’s a good chance the cost profile of running DR in the cloud once a year at $60,000, vs $600,000 per annum for the co-location option presents a clear winner.
Herein lays the appeal of Cloud DR, or if you want an aaS at the end of the description, DRaaS: disaster recovery options for the budget-conscious business, without the infrastructure expenditure typically associated with it.
The good news is – if you’ve got Avamar and Data Domain in your environment today, you’ve got the essential ingredients to offer Cloud DR, or DRaaS to your business. All you need to do is add a little Cloud DR functionality on top.
The above diagram gives you a short overview of what’s involved in Cloud DR. The key thing you’ll note is that you don’t have to run an AVE and DDVE system in the public cloud to receive replicated backup data. Instead, you deploy a virtual system on-premises called the Cloud DR Appliance (CDRA). This reads backups off the Data Domain and compresses them before transmitting to AWS and storing in an S3 bucket. There’s a bit more connectivity than I’ve outlined as I want to keep the diagram simple – for instance, Avamar gets configured for connectivity to the Cloud DR environment for control and SLA adherence monitoring functionality, too.
Cloud DR allows you to create recovery plans/runbooks, making it easier to manage the DR process when you do need to pull the trigger on it – or simply just test that the DR process is going to work. (This includes network/security changes,etc.) You also get to make use of two different recovery options: standard, and rapid. In a standard recovery, the compressed VMware data stays in the S3 bucket until such time as you need to perform a DR. At that point, the CDRS (Cloud DR Server) running in AWS will read the data out of the S3 bucket and construct an EBS volume to house the data in AWS compatible format. The environment will also coordinate the creation of the AWS AMI system, and when the EBS volume is ready, attach it and boot the AMI. The ‘rapid recovery’ mode is something you’d use for systems you need to start faster than a normal Cloud DR. With rapid recovery enabled, as soon as the backup is available in the S3 bucket, an EBS image will be constructed for it, reading the data out of S3 and placing on AWS block. Obviously you’re unlikely to want to do this for all virtual machines, but having it available as an option is certainly handy.
What’s more, you can also failback a virtual machine when you’re ready to transfer back to running it on-premises.
Businesses that want really fast DR (e.g., in the minutes, or seconds), won’t want to use Cloud DR – they’ll either be running their workloads in private datacentres, or all in the cloud, where clustering options can be used. But if your DR options are more modest, and you want to avoid having to run a DR datacentre or colocation facility, Cloud DR can certainly be a great option. (If you’re under pressure to make use of public cloud, it’s also a great tick-box while providing useful functionality, too.)
For more information on Data Domain Cloud DR with Avamar, check out the support product website for it, and this high level introductory video by Alyson Langon. But, you’ll be wanting more than an introduction and the documentation – you want to see it in action, right? For that, check out the excellent videos of its deployment and use, via Eli Persin’s walkthroughs: Deploying Data Domain Cloud Disaster Recovery, Protection Demo, Recovering Protected Virtual Machines, and VM Failback.
While this is a Cloud DR product, you can see it could have other functionality, too. What if you need to temporarily move a workload out into the public cloud for more grunt, but move it back after the peak use has expired? Or you want to test how a workload will run in public cloud? Well, there’s nothing stopping you using the Cloud DR functionality for that, as well.