When it comes to choosing your Kubernetes backup and restore strategy or designing a disaster…
May 1, 2020
Overview of Backup and Recovery for Kubernetes
And PX-Backup is installed and is managed in the same type of way in the sense that Portworx backup is a cross cluster/application such that you can set up these schedules and policies or backups across your different Kubernetes clusters that are running Portworx. And PX-Backup talks to at CD. So make sure that’s available for some cluster state. So this management section here can be a small Kubernetes cluster that’s running PX-Central for dash-boarding and monitoring and connecting it with PX-Backup so that you have a single pane of class for all your Kubernetes clusters. Now once PX-Backup is set up, I mentioned you’ll have access to the user interface. And what you can do with that is create backups and policies and schedules. So before we get started with what a backup is, we first need to understand what an application is. So an application in a namespace may consist of many different pods, which is part of a deployment.
It may have a secret associated with it. It might have a PVC associated with it. And these pods may use the PVC, they may reference the secret, they may have a service and that gives access to the application across different namespaces in Kubernetes or from the outside world. And so we have to remember that each one of these types of things, multiple pods is deployment or StatefulSet, a service, secret, a PVC which connects to a PV that something like Portworx provides is all part of the application even though they are a part of different objects within Kubernetes. Now, in order to create a backup, we can do this at many different levels. So PX-Backup allows you to back up the entire namespace, which is great for a blanket backup meaning every application within this namespace go ahead and take a backup of everything within it.
And we’ll restore that entire namespace when we need to or recovery. The other way is to take an application view, which is what we’re gonna talk about here and gather essentially all the objects and the data that are part of the application which is basically an application plus data or a backup. So when you take that backup, you’re gathering the application plus the data and shipping it off to object storage. And that entire thing is then treated as your backup. Now you can be more fine grain about things. You can just back up a volume. But for recovery of an application, this is definitely what’s needed. Now for recovery, we can go ahead and instruct Portworx to take those objects, which is in this case all the objects and data and place them back into the namespace of the existing Kubernetes cluster. So we then instantiate everything in here. We’ll get the secrets.
We’ll get the service and the volume and Portworx will be able to understand that it has an available snapshot backup that it can restore. So your application is recovered to the last known backup. Now this works really well from a backup and recovery standpoint or a single Kubernetes cluster and Portworx cluster. However, PX-Backup is multi-cloud. So if you have applications in cloud, on Prem, VMware, Azure, anything, you can connect PX-Backup to these cloud end points or infrastructure end points. And you can have backup targets. So object storage is definitely your backup target but this means S3, it means S3 compatible storage like SEF, it means MinIO and various other ones that you can use to store your backups. So that also means that you can select a backup target and backup your application such that it can be restored to an entirely different Portworx in Kubernetes cluster. So let’s say that I want to restore my applications and data to a cluster on Prem or in APS.
We go ahead and just reference the backup within PX-Backup and target the other Kubernetes cluster. So your entire application, including objects such as services, secrets and data can be restored to a completely different Kubernetes cluster. And this is really crucial in the sense that you may not have the original cluster to restore to, right? If it’s years have passed and you need to rehydrate the data and application for various reasons, this is one way to recover and keep that retention. So overall, this is the overview of PX-Backup, how it gets installed with the central management plane and management cluster and how it reaches out and to multiple clusters and can back up at the namespace level, application level, object level and restore it to namespaces and other clusters on various types of infrastructure. So hopefully that gives you a general sense, PX-Backup. I’ll put some descriptions and links below this video as well as where you can find out more to test it, try it and learn. So until next time, take care.