Kubernetes Backup and Restore for VMware Tanzu using PX-Backup

As organizations are adopting containers and Kubernetes in their production environments, one thing is clear—modern applications demand modern data protection solutions. We can’t rely on the same traditional backup solutions for our containerized applications that we once used to protect our virtual machine-based applications. Customers who are considering or already using VMware Tanzu in their datacenters need a Kubernetes-native data protection solution that will help them backup and restore their stateful applications. 

If you are a VMware admin, you have already gone through this modernization journey once when you migrated from using bare metal servers to virtualization. With virtualization, you needed a backup solution that spoke to vCenter, identified all the virtual machines and resource pools, and then helped protect those. Now, you need a solution that can talk to the Kubernetes API server, identify all the namespaces and stateful applications, and help you protect those. That way, when it comes time to restore, you wouldn’t simply be restoring the underlying machines. Instead, you would be restoring your applications with all the Kubernetes objects, application configuration, and data.

We have discussed the challenges with traditional backup solutions and the design considerations for a modern backup solution in a previous blog. So, in this blog, we will focus on how PX-Backup from Portworx can help you backup and restore your applications running on VMware Tanzu.

Before we jump into the backup and restore piece, let’s discuss what happens when you deploy VMware Tanzu Kubernetes clusters on your vSphere environments. VMware Tanzu Kubernetes clusters are deployed by creating and applying configuration files (yaml) against your supervisor cluster. You can set the desired state for your Tanzu Kubernetes clusters in the yaml file—which includes things like the version of Kubernetes you want to run, the number and size of VMs to be deployed for the control plane and worker nodes, the CNI plugin you want to use, the StorageClass you want to use for your nodes, and the pod and service subnets you want to use for your cluster. Once you apply this yaml file, VMs are deployed using a template hosted in your local content library, attached to the correct network, and hosted on the correct vSphere datastore. You can now connect to this cluster using the ‘kubectl vsphere login’ command and start deploying your applications.

When you deploy Portworx on your VMware Tanzu Kubernetes clusters, it automatically provisions VMDKs (as First Class Disks) using the native VMware CSI driver and attaches them to the worker nodes in your Tanzu Kubernetes clusters. These VMDKs are then aggregated into a storage pool that you can leverage for your stateful applications. Persistent volumes can be dynamically provisioned on this storage pool using Portworx Storage Classes. If we look closely at the anatomy of a stateful application running on VMware Tanzu Kubernetes clusters, it includes the following pieces:

  1. StatefulSet or Deployment objects that are responsible for the lifecycle of your Kubernetes pods.
  2. ConfigMaps or secrets to store environment variables or passwords. 
  3. Kubernetes Service to facilitate communication between the different application components or allow users to access the application itself.
  4. PersistentVolumes and PersistentVolumeClaims, which store your application data.
  5. Depending on your application, you might have additional objects like Operators and Custom Resources.

To successfully backup and restore your application running on VMware Tanzu, you need to capture all these Kubernetes objects, which will also include your application data and configuration. 

You can use PX-Backup to protect applications running on VMware Tanzu in a couple of different ways.

BackupRestore

Local Backup and Restore: 

In this scenario, you have containerized applications running on your VMware Tanzu Kubernetes clusters on-prem. You can deploy PX-Backup on the cluster running your applications, or you can deploy it on a dedicated cluster. Using the PX-Backup UI, you can add all your VMware Tanzu Kubernetes clusters running Portworx. At this point, PX-Backup will talk to all of your clusters and identify the different namespaces and applications that you have running on those clusters. In addition to linking the VMware Tanzu Kubernetes clusters, you will need to add an S3-compatible object storage bucket as well. This will act as your on-prem backup repository and will store all of your backup snapshots. Once you have these things configured, you can start configuring schedule policies, backup rules, and backup jobs for your applications running on your VMware Tanzu Kubernetes clusters. 

Having a local copy of your applications allows users to restore quickly in case of accidental deletions, data corruption, ransomware, etc. You can choose to restore from the latest snapshot or an earlier snapshot, based on the point in time that you want to restore your application to. In the following demo, you will see this scenario in action, where a VMware Tanzu Kubernetes cluster is running a simple stateful application and an object storage bucket has been configured on a Pure FlashBlade system to serve as a backup repository.

Remote Backup and Restore: 

In this scenario, you still have your applications running on VMware Tanzu Kubernetes clusters on-prem, but you want to restore them to a Kubernetes cluster that might be running in the public cloud. This is important when your source cluster is no longer accessible and you want to restore your application to a different Kubernetes cluster running in a different location. For this, you can continue using an on-prem S3-compatible object storage bucket, given that the network connections have been configured correctly to facilitate restore to a remote Kubernetes cluster. If not, you can also use any of the public cloud object storage solutions, such as Amazon S3, Google Cloud Object storage, etc. You can implement TLS-based encryption when adding your remote backup repository to ensure that your application data is encrypted in transit. In addition to configuring a remote backup repository, you will also need to connect to the remote Kubernetes cluster, so when it is time to restore, it only takes a few clicks to get your application up and running again in the remote site. 

In the following demo, we have a simple application running on VMware Tanzu Kubernetes cluster, and a Google Cloud object storage bucket has been configured as the remote backup repository. We have configured backup jobs to protect our application and then successfully restored it to a Google Kubernetes Engine (GKE) cluster running in us-east1 region. 

In both demos, we have used an either/or approach, but you can customize PX-Backup to implement a combination of these two approaches, where you can have frequent backups— may be on an hourly schedule stored in the local repository—and then have your daily or weekly backups stored in the remote backup repository. 

To summarize, PX-Backup is built from the ground up for Kubernetes and can help you protect your stateful and distributed applications running not just on VMware Tanzu but any other Kubernetes clusters that you might be using for your applications. PX-Backup protects your application, including all the different Kubernetes objects in an application-consistent approach, ensuring complete data recovery.

Bhavin Shah

Technical Marketing Manager | Cloud Native BU, Pure Storage

Share Share on Facebook Tweet about this on Twitter Share on LinkedIn



Back to Blog