Not everything changes with the cloud

You must have heard this oft-repeated expression, “Cloud changes everything”. Well, it does and it does not. While cloud gives you freedom from owning and managing your infrastructure and flexibility of usage and pricing (among other benefits), just because you move your workload to the cloud, it doesn’t mean that you no longer have to worry about “protecting” your data. To be more specific, in this article I’ll focus on what’s traditionally called backup and related use cases. I’ll focus on Disaster Recovery in a future article. There is often a misconception that the cloud infrastructure provider will automatically take care of backup and DR for your application. That is often not the case.

I was having a conversation with someone who’s responsible for building infrastructure for one of the major cloud providers and he said to me that backup was so last century and that they were doing things the “modern” way. When I asked him to elaborate, he said that they didn’t need any of the traditional backup software because they took nightly snapshots of all data and moved it to object storage. Somewhat surprised, I asked him about restore and his answer was that when something "went wrong” (whatever that means) they “automatically” restored the latest snapshot. 

Well, what if the user doesn’t want the latest snapshot to be restored? What if the restore was initiated because of a human error 2 weeks ago and was only recently discovered? The user may want to choose from a snapshot back in time. The user may not even want to restore the entire VM – majority of the restores are single file/directory restores. Even in the event of a full VM restore, the user may want to choose different snapshots for different VMs. Then there is the trivial, little matter of application consistency. The application will almost certainly need to be “quiesced” before initiating backup needing either application-specific APIs, plugins, hypervisor and/or filesystem support. Taking a nightly backup at a fixed time every night without application awareness would result in the application taking forever to recover or, worse, giving up and not recovering at all.

BTW, this challenge isn’t just limited to IaaS solutions -- the same thing applies to SaaS offerings as well. While in SaaS, application consistency would be taken care of, you still need to poke into their restore and retention policies. If your application data is corrupted because of a human error or something going wrong during migration, how would you recover the last sane copy? Be sure to check your SaaS provider’s backup/restore mechanisms/policies. Here are some questions to ask (I’m going to provide sample answers for salesforce, just for illustration, but you could do this exercise with <insert your favorite SaaS vendor here> :

• How frequently do you take the snapshots? Can I initiate a manual snapshot (after a major upload of data, for example)?
• What is being backed up? Just the user data or also the metadata? Salesforce, for example, does not include metadata in their native auto backups.
• How long do you retain those snapshots? For some compliance use cases, you may need to go back several years in case of an audit. Salesforce, for example, can go back up to 90 days.
• What is your restore mechanism? Is it included as part of the service contract or does it cost extra?  For reference, salesforce’s restore mechanism costs a flat $10,000 per request.
• Can you restore yourself or do you have to file a helpdesk ticket? If it is the latter, then how long is the turnaround time? With salesforce, this process can take minimum 6-8 weeks to complete.

To reiterate, and to be absolutely clear, my intent is NOT to highlight any flaws in salesforce. Quite the contrary, Salesforce does recommend that you take care of your backup needs yourself using one of the suggested solutions. The intent of this article is to highlight that just because you don’t have to manage your infrastructure (in case of IaaS) and your applications (in case of SaaS), doesn’t mean you also don’t have to manage backup those business-critical workloads.