CloudCasa: More Than Backup, Powering Seamless Migrations

CloudCasa, the software-as-a-service solution for backup and recovery of Kubernetes and cloud native database workloads, has come a long way since its early days. With unique and intuitive features like Full Stack recovery (aka Any2Cloud) where we can provision an entirely new cluster on the fly to our ability to provide customizations during restore like remapping storage classes and renaming namespaces, users of CloudCasa have quickly begun adopting its capabilities for more than just the insurance of having a backup during a disaster, but also a means to migrate cloud native workloads between on-premise and cloud hosted Kubernetes environments while testing your application on different versions of Kubernetes or completely different CPU architectures entirely.

One use case in particular that is catching the attention of users of Microsoft Azure Kubernetes Services (AKS) is the ability to migrate from Ubuntu to Azure Linux as the default operating system for nodes deployed within the cluster. Combine this with being able to migrate between storage classes and take advantage of Azure Container Storage, CloudCasa can now make this entire process much simpler and less stressful process.

Ubuntu and Azure Linux

With your Kubernetes nodes running on Azure Linux, both you and Microsoft can take full advantage of all the OS optimization and customizations within your cluster and not be restricted to using an Ubuntu Linux distribution. But if you think you about all the work that needs to take place in recreating a cluster using Azure Linux worker nodes, I don’t blame users for opting to stick with the cluster configuration from how their cluster was initially deployed. This does not bode well for that whole code portability selling point of Kubernetes. Additionally, having such a hurdle would discourage  upgrade their version of Kubernetes or potentially take advantage of more affordable hosting options available.

But with CloudCasa, we can become that easy button and remove these hurdles entirely. Such is the case with users now planning a migration of Kubernetes clusters from Ubuntu to Azure Linux. Just by simply backing up your Kubernetes cluster, you’ll be able to perform a Full Stack Recovery while also upgrading the version of Kubernetes deployed to the cluster. 

The First Step (Take a Backup)

The first step is to take backup through CloudCasa. This can be done very easily by defining and scheduling a backup job in CloudCasa. It doesn’t matter whether you are using CloudCasa Pro and/CloudCasa for Velero as the restore will be accomplished in a similar manner. Upon the completion of the backup, we have everything that we would need to perform a Full Stack recovery to a new Microsoft AKS Cluster.

Restoring from the snapshot

During the backup of your Kubernetes cluster, CloudCasa is not only collecting the resource/configuration data and persistent volume data for your cluster, but it is also collecting cluster configuration data as well. Having this data, allows CloudCasa to provision a new cluster in AKS using the original cluster configuration or new cluster configuration of your choosing.

Here are the steps that you can perform to create a new cluster in AKS when defining a restore job. CloudCasa can create a destination cluster for you on the fly – a little something that we call “Full Stack Recovery” (formerly “Any2Cloud”). When doing a Full Stack Recovery Restore, you can specify the destination as the Microsoft AKS service that you previously configured in your CloudCasa enterprise.

(The screenshot below shows selecting a target destination creating an AKS cluster on the fly)