 Hello everyone. Hi. So thank you for being here. My name is Harshita Sharma. I'm a developer advocate, kind of a newbie in that area, and a software engineer also. So a little bit about me, I work at a company which is called Maya Data. Our company has an open source product which is called OpenEBS and it's a containerized storage solution for Kubernetes applications. So we also work on the area of data agility. So when we also, another product is Data Migration as a service where we leverage Heptio Valero to backup and restore the Kubernetes resources along with the persistent volumes. Or you can see the data. So the things which we'll cover today in our lightning talk is what is Valero, why is it different, how it works and where can you use it. So Valero is an open source backup tool to backup the Kubernetes resources and persistent volume. It can be used in case you want your cluster migration or in case of disaster recovery. For example, you have a Kubernetes cluster, your applications are running on it and you accidentally deleted a namespace or your node is non-recoverable or there's a node failure or a disk failure. So your data is lost. So you don't want to be stuck in those cases. You want your resources and data to be saved somewhere and mostly remotely. So how Valero helps in it is, in case of Kubernetes resources, when it comes to Kubernetes resources, it communicates with the API server, Kubernetes API server instead of communicating with the ATCD database. So it has two components mainly, which is, first is server, which runs for the cluster where your applications are running. Second is command line tool, which you can run anywhere, mostly locally. And yeah, it can be run on premises or on cloud. And yeah, but for in the thing to be noted here is it doesn't provide any solution to backup your persistent volume. What it does it, it provides support for cloud snapshot features. So basically it communicates with the cloud provider snapshot feature to take the backup of your persistent volume. And any storage solution which wants to add a plugin to the same thing, to the Valero, so they can also add a plugin. It provides support to adding a plugin. For example, for our product, we have created a C store plugin. C store is our storage engine. So now it also supports the backup and restore of our persistent volumes for our storage engine. So why is it different? As I mentioned that it doesn't communicate directly with the ATCD database and it basically communicates with the Kubernetes API server to fetch the Kubernetes resources state. And how it helps is it lets you filter out the resources what you want to backup and restore. For example, you only want some namespace to be backed up or you only want a particular type of resource to be back up. So like for example, you just want your pod to be back up. So you can filter out a mention in the command line, your command. Just I want my namespace, for example, your application is running MySQL. So I just want my MySQL namespace to be backed up. So all the resources which are in that particular namespace will be backed up. And if you mention the type of resource is pod. So all the pods will be backed up. Or if you have connected your resources using labels, then you can also provide a label selector. And you can also mention using label selector that, for example, if you use a combination of it, you want the namespace to be backed up. But you don't want a particular resource to be backed up from that namespace. So you will use a combination of mentioning include namespace, which is MySQL, but excluding a particular resource may be service account using your label selector. And the second thing is you don't need to have direct access to the ATCD. And in most cases, because of security reasons, you don't have this access also. So how it works? For Valero, every operation which is basically on demand backup, schedule and restore. So every operation is a custom resource which is defined by a custom resource definition, CRDs, and which is stored in ATCD. So Valero also have controllers which who process these custom resources and lets you backup, restore and the related operations. So what you do? If you see the whole process is, I have deployed the Valero command line tool. I will run, before that, before running, you just need to set up your snapshot and backup locations and you set up your Valero server on your Kubernetes cluster. So snapshot and backup location is just simply a remote cloud place or object storage where you want your snapshot files and your custom resources configs to be stored and to be restored from. So after you set up your backup and snapshot location and your Valero server, your cluster is ready to be backed up. And then locally when you set up your Valero client, you will just mention, I want this, you will mention your backup name and you will mention which namespace or resource you want to be backed up or you can also mention you want to snapshot your volumes or you don't want to. And in case you want to snapshot your volumes, you have to mention for which location you want the snapshots to be stored in. So for example, if you want AWS snapshot feature to be used to snapshot your volumes, you will just create a snapshot location and then you will, there you will mention the access and the URL of it. And then when you mention in the command line, I want to, I want you to use this snapshot location. It will automatically store the snapshot files there and also use, will use the S3 or the AWS snapshot features to backup your snapshot. And yeah, then when you mention, okay the URL in the command Valero backup, now Kubernetes client or CubeCity, sorry, Cubelet will communicate with the Kubernetes API server and Kubernetes API server will validate your custom resource and if it everything is fine, then your custom resource will be created and backup controller will run a watcher. And if it finds any new backup object is created, then it will again query the Kubernetes API server for the Kubernetes state of your, of the Kubernetes resources, which you have requested to be backed up. And when the whole backup is complete, it creates a tar ball and it uploads the tar ball to the cloud provider. The cloud provider is the same where, which you mentioned in your backup and snapshot location. And you can have a different backup snapshot location. For example, you want your snapshot files to be saved in different place and your resources, Kubernetes resources to be saved in different place. You can do that, but preferred that you put it in the same place for like, for example, in case of cluster migration, everything will be at the same place and you can restore from the same place. Okay, so yeah, after that, when it comes to use cases where and when you can use the Valero. So, first is disaster recovery, second is cluster migration and third is whenever you want, suppose you want your setup or your application to be tested in a different or replicated cluster, then or testing cluster, you can say development clusters. You can replicate the production cluster to development and testing cluster and the next thing is disaster recovery. Okay, so I just mentioned that you, the Kubernetes as you can see is a volatile system and service outage can happen at any time or a pod or a namespace is deleted accidentally maybe or a node can go to an unrecoverable state. So in that cases, what you should do is, you can create a schedule and that interval is on your choice. You can create a daily backup schedule and so when you create a schedule or triggering intervals, if anything happens or any disaster happens, before that you will have your backed up resources and your data at the remote location. So and at the time of, suppose you have already created the schedule and your resources already there. So if in case some disaster happens, you know, okay, now I need to go back to the same state. So what you will do is, you will help, you will use the Valero client and you will run Valero restore these resources for me and at the time of restore also you can filter out. Okay, I do not want these three namespaces to be backed up. I just want one of them or I want to, do not want this particular resource. So you can use a label selector for that and for restore also it uses the same snapshot location which you can mention in the command which is Valero restore and yeah. So also at the time of restore what you can do is, you can put your location, the storage location, the cloud object storage location to a read-only state so that a new backup or restore is not, sorry, a backup, new backup is not created at the time when you are restoring your resources. Next is cluster migration. Okay, you can decide, you want to migrate your Kubernetes resources and your data to a different cluster, maybe a different, maybe in case you want to replicate your cluster for the testing and development reasons. So what you can do that for the, in that case of destination cluster which is a different cluster, you have to set up your Valero server then you have to create the backup and storage location, the snapshot location and as soon as you create the storage locations there, which is the same location you, where you, which you use to do the backup in your source cluster. So as soon as you create the location, Valero server keeps on syncing the resources which are there on the cloud. Okay, so when it comes to Valero, the, our object storage location is a source of truth so it will keep on checking, okay, these resources, these backups are there so I need to sync them down and if in case a backup resource is created on your cluster but it's not on your backup object storage location then it will delete it from your cluster. So, yeah, as soon as you create your location every backup resource, every single one of them will be synced from your object location, object storage location and when you see, okay, now this is the backup name which I used to backup my resources and then you can restore your, your resources using the same backup name by mentioning it in the Valero restore command. And yeah, open to questions. Yeah. Sorry, do you stop once before the backup one? Stop what? Pots. Pots. Pots. Pots. No, no, no. You don't need to stop any application before backup. It will, the application will keep on running as it is running but because the Valero communicates with the API server so it will just do the query and keep on checking the Kubernetes resource state. Can Valero stop? Can Valero stop? Before the backup. Yeah, if you want it to be stopped you can use a pre-hook for that. Valero provides support of pre-hooks and post-hooks. Like for example in case of databases if you want to flush in the, your data then you can use a pre-hook in that case. Yeah, my time is up. Can you do incremental backups? Yeah, if the Valero does the incremental backups only. Okay, thank you guys.