The pressure is on for companies to take advantage of cloud infrastructure for cost-savings, scalability, flexibility, and time-to-market efficiencies. With that pressure comes a lot of questions about how to get it right and adequately protect data in the process.
With all of the considerations for managing your digital transformation to the cloud, backup and recovery can be an afterthought. Here are the things to keep in mind to ensure proper data protection during your migration to the cloud.
Why do you need cloud backup at all?
There is a common misconception that cloud providers not only manage infrastructure in the cloud but your data in the cloud as well. Most cloud providers provide some level of data resiliency through use of replicated copies of stored data. However, this is insufficient and does not protect your data from a number of data loss or data corruption use cases.
As you move to the cloud, you must cloud responsibly and employ the same data discipline practices you would for critical on-premises data. If you read the End-User License Agreement you signed with any cloud service, you'll undoubtedly find the onus is on the customer to ensure your data is backed up, even if the vendor provides some form of replication. They provide infrastructure only and washed their hands of any legal liability of data loss when you signed the agreement.
How are companies migrating to the cloud?
Differences in where companies are in their cloud strategy impact how they are migrating to cloud data centers. More complex legacy environments typically face more challenges than younger companies in moving to a cloud strategy. Application migration to the cloud can be broken down into four general models.
Cloud Migration Models
- Lift and shift is a strategy used when a client uses the same application software stack used in their own data center but moves it to run on cloud infrastructure that emulates an environment the application can run on. This is typically the easiest approach to migrating existing applications to the cloud but does not fully leverage cloud capabilities.
- Application Refactoring is modification of an application to run in a cloud platform. Contingent on their design, some applications may be better suited to refactoring for the cloud (eg, applications with more of a services-oriented design). Applications may be partially or completely refactored for the cloud.
- SaaS applications are available for most common business functions. Companies that wish to stop devoting time and resources to managing applications outside of their core business often ‘migrate’ to the cloud by simply shifting to SaaS applications for specific business functions (eg, this is commonly done for email, accounting, payroll, and other business operations).
- Re-platforming involves completely embracing cloud services and making applications truly cloud native. You can think of this as refactoring the entire platform your applications run on. This often requires a major or complete rewrite of existing applications into a micro-services or perhaps container-based architecture. Consequently, re-platforming is more of a reimplementation of an application on an entirely new platform using different developer tools than a migration. Like SaaS applications, re-platformed applications can be considered to be “born in the cloud”. Re-platforming applications typically requires a large investment, but it enables the greatest leveraging of cloud efficiencies. For example, properly re-platformed applications typically have greater flexibility to run across multiple cloud providers than refactored applications.
How cloud workloads can be protected
We briefly discussed the need to protect your data as your applications migrate to the cloud. How you backup your workloads in the cloud may depend on the migration model that brought your application to the cloud.
Lift-and-shifted or refactored applications often can be effectively protected with time-proven approaches. The born-in-the-cloud SaaS and re-platformed applications may require new techniques. There are several common ways to achieve cloud workload backup and protection.
Application and file system agents sometimes get maligned due to the need to install, update, and manage potentially thousands or tens of thousands of workload clients inside virtual machines. However, for key applications, agents often provide the optimal approach for achieving the best application service levels. To this point, it is interesting to note that some “agentless” backup products actually insert agents dynamically.
One important example of the value of agents is that they provide a way for application consistent backups and recoveries. Also, agents can provide application specific integrations that improve service levels and often aren’t available with other methods (eg, transaction log backups and roll forward recoveries for databases).
Agent-based backups are a very common approach for lift-and-shifted or refactored applications. Cobalt Iron’s Compass can eliminate the management complexities of agents through analytics-based automation which greatly simplifies agent-based backups. This is certainly a powerful approach to protecting some cloud workloads.
Hypervisor level Services
Cloud providers offer various virtualization services (eg, VMware Cloud on AWS) hosted in their cloud. Applications and data in these environments can potentially be backed up using hypervisor level services (eg, VMware’s API for Data Protection). These hypervisor level backups typically enable backup of all virtual machines on the host without the need for agents in each virtual machine.
As an example, Compass use of these APIs provides mature capabilities such as incremental forever snapshots and granular recoveries from VM backups, including in the cloud.
Cloud providers often offer APIs or services for taking snapshots of cloud resources. Two common cloud snapshot services are for snapshotting cloud virtual machines and cloud storage volumes (eg, AWS provides the ability to snapshot Amazon Machine Images as well as Elastic Block Storage volumes).
Although these snapshots can be leveraged for backup, there are disadvantages to these that must be considered. For example, cloud snapshots often are poorly managed leading to high cloud bills. At one business I recently worked with, their cloud provider bill more than doubled unexpectedly in one month due to uncontrolled snapshot creation by application owners. One important consideration if using cloud snapshots is to have some means to enforce policy management of the snapshots so they are created, protected, and deleted according to business objectives.
In addition, if you want to recover across public clouds or back to on-premises, cloud snapshots may be restrictive in that regard.
Compass can also help with these challenges with policy-based lifecycle management of cloud snapshots and cross-cloud replication of data.
Cloud Application Backup Services
Cloud providers are evolving their view of backup beyond making a couple replications of data to actual backup services. A few SaaS applications are starting to also provide true backup services.
These backup services come with some disadvantages. They come at an additional cost and the backups still need to be managed by the user. Also, like cloud snapshots, cloud backups typically keep the data within the same cloud provider which limits recoverability options (eg, to another cloud provider or to on-premises) and further locks you into one cloud provider.
API Level Backups
While often overlooked, some cloud SaaS and replatformed applications may provide interfaces that allow more robust backup protection including – application consistency, incremental backups, efficient data access (eg, in memory access to application data), and more granular recovery options.
This is a nice approach but unfortunately very few cloud applications have bothered to provide robust backup APIs (eg, some SaaS APIs merely provide usage reporting information and not backup function) and very few backup products have invested in writing to the APIs that do exist. Also consider that API level backups tend to restrict recoverability options to another cloud provider or to on-premises.
Determining the next steps for your company
The most important thing to keep in mind is that your organization is unique and has unique requirements to be met. There is not one “right” cloud strategy, just the right one for your organization's current maturity and future plans. You should choose the cloud migration model(s) that is(are) right for your business. And you should choose a backup solution (not product) that provides robust, efficient protection for your cloud workloads, in conjunction with the rest of your business applications, wherever they may reside.
Cobalt Iron’s platform, Compass, for example was built for large complex environments and is the right fit for organizations that need data protection at scale and may need combinations of on-prem, cloud, multi-cloud, or cross-cloud workloads secured in an unified interface. Compass supports a variety of cloud workload backup and recovery approaches including agent-based backups, hypervisor level backups, and policy-based management of cloud snapshots. Compass provides a simplified experience to enterprise backup including for your multi-cloud workloads.
Consider the business outcomes you want to realize as you move data protection workloads to the cloud:
- Operational efficiencies
- Automate repetitive tasks
- Consolidate enterprise applications
- Realize cost savings
Interested in learning more about Compass data protection? Schedule a call with our team for a free assessment of your current environment.
< Back to Blog