Is that light you see at the end of the proverbial tunnel, or is it the headlight of an oncoming train?
The future of your professional career just might depend on your ability to successfully lead your company to the cloud. So many things to consider…
Yes, the cloud offers many advantages to your business including agility and high levels of fault tolerance, but in and of itself, the cloud does not release you from backing up your data in order to protect yourself from user error, data corruption, or data loss.
Just like provisioning new applications or scaling current applications, you need to consider every angle when protecting your data that lives in cloud.
The questions are big, but the benefits are potentially even bigger. You get agility, scalability, and you only pay for what you need, as opposed to overprovisioning for a period of time and then refreshing some time later. Just imagine, you get to tell your boss and your boss’s boss that you have a cloud presence now. Won’t that feel great?
Now, let’s take a step back and throw one more very important and critical question into the mix. “How are you going to protect your data in the cloud?”
To ensure your data is safe and secure, consider these 5 tips before you move it to the cloud.
1. Backup cloud providers care about limiting their liabilities – Not yours.
A good cloud resiliency plan will increase the reliability and availability of your applications. Be sure to look closely at how your provider measures resiliency and how it’s structured before you completely rely on a solution to protect your data
While cloud providers may be providing all the necessary services such as hardware-based snapshots, volume level replication, and limited copies of VM backups, the problem is that because backend data protection is owned and controlled by the cloud provider, you may not have direct, immediate access to restore functionality.
Your data is your interest and the protection of it needs to be in your control. So take the time to understand your cloud provider’s Service Level Agreements (SLA’s) and how they define the availability of your VM’s in their cloud.
Please do not misread this. You want your service provider to have a contingency plan to ensure your VM is just not going to go away. Hardware fails. Upgrades get botched. Outages are a fact of life. Even in the cloud. However, as part of your standard service, a good cloud provider will architect a backup plan and take the necessary steps to mitigate your risk to where it’s almost non-existent.
2. Cloud providers' measures of resiliency may not be geared towards restoring individual files.
You’ve probably seen stats that support how the majority of lost data is a result of human error. Usually, end users are not deleting, misplacing or overwriting entire VMs, instead they’re deleting, misplacing, or overwriting individual files and directories. Depending on whose blog you are reading and which analyst report they are quoting, user error accounts for as much as 47% of data loss for cloud users. (Free Aberdeen membership is required to access).
So the question you need to ask is, “Does your cloud provider’s SLA protect you from this surprisingly large component of data loss?” Probably not. Most likely your SLA is designed to protect entire systems or the volumes they are sitting on, and not file-level restores, which is the bulk of what most companies really need to adequately support their backup and recovery plans.
Ask yourself, “How much of that process do I control?” Does it meet your recovery time objective (RTO)? Maybe. But it sure sounds complicated.
What about the recovery point objective (RPO)? Do you have months or a year's worth of restore points available? Maybe. But probably not. VM or volume level protection in the cloud is not meant to provide long term retentions. You are most often limited by a single characteristic, and that is a limited number of copies maintained by the cloud provider.
3. Back to the Future: Your data still needs to be protected in the cloud as it was before.
Let’s take a ride in Dr. Emmett Brown’s DeLorean. Fire up the flux capacitor, hit 89 mph, and go back in time to 2005. Backup, the industry standard, is guided by three basic principles:
-
Backup has to protect all of your data with sound tape rotation and retention.
-
Backup has to run regularly and without error.
-
Backup tape should be taken offsite.
Ten years later, has anything changed? Well yes! We now have an alternative to tape. So we changed the media, but the rules stayed the same. You still need sound retention policies. You still need your backup to run dependably and without error. Finally, it needs to be offsite.
Let’s take a look at those dependencies and how to resolve them for the cloud.
Retention Policies
Most businesses have some sort of regulatory or compliance requirements that drive RPO and RTO retention policies. Moving to a cloud based model doesn’t change your regulatory and compliance requirements, or long-term retention policies one iota. Bottom line – your cloud provider’s SLA will not include the protection for the VMs and will not meet the retention requirements for your data.
Consistent, Error-Free Backups
Back in 2005, you got notifications and checked your error logs to ensure your backups were reconciling without errors. Chances are your cloud provider will not be able to provide that kind of “behind the curtain” access necessary to validate volume or VM level backups, as well as to address any relevant compliance issue.
Offsite Copy
For a cloud workload, what is the primary site? The cloud provider’s public or private cloud? Your entire workload lives with that provider. Even if your provider spreads your workload across multiple physical datacenters, the primary site is that of the provider. An offsite copy means another cloud provider. It means doing what you did with tape for years. Data existing as a backup should not be stored in the same location. We just have to think about cloud providers as locations.
4. Backing up your data from one cloud to another is your exit strategy.
Getting a workload and the corresponding data to the cloud is easy. But what if you want to change clouds? What if you need to leave the cloud? Many cloud providers do not offer a simple solution to make that happen. However, if you are backing up your key data to another cloud, then you have your exit strategy in place.
"If you are backing up your key data to another cloud, then you have your exit strategy in place."
By backing up your cloud data as file level backups to another cloud, you will be doing file-level backups. These backups are not meant to rebuild a server from the ground up. They are meant to repopulate a functioning server and application with the data needed for the application to perform its designated task. In doing this type of backup, you rise above the proprietary virtual environments used by your cloud provider to house your VMs.
You are going to rely on the application vendor’s APIs to restore data back into an application as opposed to restoring the entire server. For instance, your SQL server will have the same data regardless of what VM infrastructure it resides on. All you will need to do is deploy a server in your new cloud and then restore the file-level data back into it. Mobility comes from the backup and restore, and not the virtualization.
The technology is getting better, and soon you will be able to move workloads from one cloud to another without caring what platform it is on. File-level backups will enable this idea of an agnostic platform so that your data will truly be portable. Backing up your cloud data to another separate cloud not only meets the requirement of having your primary data in a different location from your backup data, but it also gives you the freedom to leave your primary cloud for another one.
5. Backing up your cloud is another workload and should be treated as such.
Using a client-based backup to protect data within one public or private cloud comes with a price. The backup client you deploy in your cloud has its own list of requirements. It is its own workload.
This new workload is going to have RAM, CPU, and storage requirements you need to account for. And don’t forget about OS licensing, bandwidth, and budget.
Another thought when choosing your cloud backup solution – you need to add bandwidth throttling to your “must have" list. Bandwidth throttling allows you to control the amount of bandwidth consumed by your cloud-to-cloud backup.
Also, OS level backups might not make a lot of sense and should be examined closely because ideally, you should only back up the data you need, and avoid paying for bandwidth and cloud storage you don’t need.
Backup the data in your cloud to another cloud
If you’re like most companies, you will be moving to the cloud at some level. Choose your backup solution wisely and be sure you consider the big picture when you start moving workloads and applications to the cloud. Getting your workload to the cloud is just part of the equation. You also need to protect your company by extending that agility to your data.
So the takeaway here is that if you want to protect your data living in the cloud, you are going to need a backup solution that gives you control and access to your data as well as a backup solution that provides file-level backups of files and applications into another cloud. There we have it. Backup the data in your cloud to another cloud.
"Backup the data in your cloud to another cloud."
What are your plans for migrating to the cloud? What specific issues did you experience that weren’t addressed in this blog article? How did you resolve them? Please share your comments in the section below and I’ll be sure to reply.
About the Author
Matthew Brady is a Senior Consultant at Daymark Solutions and manages Data Protection Services (DPS). Matthew specializes in cloud backup infrastructure and focuses on implementing cloud backup solutions for Daymark’s clients. Matthew is certified in VMWare, Cisco, Asigra, and Microsoft.