 I am Gaurav Rishi. I'm the VP of product here at Casting by Veeam. And also you'll hear from Michael Corsi later, who's going to show you a quick demo. And really what we are talking about is an important topic, given that databases is one of the most common workloads on Kubernetes and OpenShift, of course, being a prime example of that. And so with that said, we'll sort of get into how we do it here as part of Casting by Veeam. And very quickly, we'll go through the use cases, quick architecture, why customers use us, and also then we'll sort of run a recorded demo with Michael Corsi talking about how to actually do this in real life and you'll get a good sense of that. So I think just a quick slide. We've been working with Red Hat OpenShift for a while. In fact, if you go to castin.io slash OpenShift, you'll see a variety of collateral around it. I think very happy to sort of use it for a few reasons, right? And I'll just run into the three use cases that we've been laser focused on as a company. So first of all, Castin is an acquisition which Veeam did. We are the number one Kubernetes sort of backup leader in this space. And Veeam, of course, is very well known for doing backups in the context of hypervisors. So Castin K-10, which is the name of the core product, has been our core bread and butter, has been these three use cases. One is backup and restore, right? So working in multi-tenant environments, by the way, in an air-gapped environment too, with Kubernetes native rollbacks, access controls, being able to do what we call polygrap persistence, which is essentially the fact that if you look at any cloud native application today, under the cover, they are obviously microservices that make up that application. And each microservice ends up using their favorite or the most appropriate database under the covers, whether it's a streaming database or a SQL or a NoSQL. And what you do need to backup in this new world is really the entire application, which is made up of multiple databases under the covers and hence polyglot persistence. So we've been doing that, so that application centricity has been our starting point and we do that really well, right? Disaster recovery is the second use case. Don't need to explain why that's needed. People do make errors all the time, disasters do strike. And of course you have things like ransomware, which make it all the more important in today's world. So we do that really well in context of regions, availability zones, hybrid architectures. And because not every architecture and deployment type is the same, you might go ahead and need to restore or rehydrate your application where the storage class under the covers has changed. You might have done something in spinning media, but when you rehydrated it, it's SSD. We as Gaston have the abilities to make these transformations. So really important and powerful feature and that's something that's quite useful. And then Kubernetes, of course, people expect it to be portable. That's one of the advantages of that, whether it's because you're going ahead and rehydrating applications because every quarter you have a new Kubernetes version come up or you're upgrading your clusters or maybe you have test-dev clusters. This is another place where Casun K10 shines to be able to go ahead and not only give you the backup in DR, I touched on, but also be able to move your applications for a variety of these reasons. And again, here it's not just a storage transformations that we can do in the context of DR, like I talked about, but also you're phasing out your secrets so that it can be regenerated. We have a really rich language to be able to go ahead and have these application transforms, as we call them, in action. So all of this, of course, works really well and that's one of the reasons, you know, Casun for the second time was put up as the number one in doing Kubernetes data protection. So, you know, there is a QR code. I would encourage people to sort of go ahead and scan that and read the report for yourself and, you know, I'm happy to answer questions about that if they come up later. But let me get on to the meat of, you know, where we have been integrating and how all of this works, right? So no presentation would be complete without a stack diagram. So he has fun from me, but this is obviously a joint presentation that, you know, we had done with Red Hat. Like I said, if you go to castin.io, you'll see a lot more collateral. But to just walk you through it at the bottom layer, again, you have any structure, whether it's hybrid or whether it's public cloud or private clouds or even in the edges now. And OpenShift, of course, whether it's ARO or ROSA or OpenShift on prem is got the layers and the capabilities that you see in the middle part of it. And Castin K10 is a cloud native application itself. So we get installed on a cluster on top of OpenShift. We support all of these variants which you see in the layers below. And on top of us, like I said, we take a polyglot approach, which means we protect the databases, but we do it in an app-centric manner. So we have gone ahead and made sure that when we introduce Castin K10 into a cluster, it'll automatically discover all of the applications running in various namespaces. It'll go ahead and decompose what the dependency map of that application is in terms of the various microservices, the PVs, PVC bindings, the data services, whether it's SQL or NoSQL, you see some icons in the layer above. And we'll go ahead and make sure that you can set policies that allow you to say, I want to back up this application X number of times a minute or hour or a day and then go ahead and safeguard the data in some repository, which could be offsite into an object store, for example. So that's really the backup DR and mobility point, which I talked about, that gives you that power of getting the portability as well as the security of that application. We are Red Hat operator certified. So you can find us in the catalog, we allow for lifecycle of the operations in this particular case. And then we are also on the Red Hat marketplace, which is operated by IBM. And actually very recently, we also added transactions to it. So in addition to going ahead and trying out Cast and K10, which is a fully featured free edition for a limited number of nodes, you can also go ahead and purchase it that obviously through the marketplace. And we have a couple of options there again. So you can buy it on a per node basis or you can go ahead and actually use it on a pay as you go basis. So a lot of flexibility out there and makes it seamless operations for anybody who's using OpenShift. And then finally, I mentioned this, we support a variety of OpenShift distributions, like whether you're on Azure with ARO or whether you're on AWS with Rosa or whether you're on premises with OpenShift, work in air gap environments. We obviously are integrated with things like the OpenShift Container Storage System. And so as a customer, you do have that freedom of choice. So just to get under the covers even more, a little bit of a busy picture, but let me walk you through this very easily so that you can understand it. So like I said, at the bottom of this picture, you can see you might have a few different variants of Kubernetes that you might be using in your system, whether it's a mix of AKS, but you want to move to OpenShift or whether maybe you're using ARO or maybe using plain Milena Kubernetes. You have a cluster and on top of that cluster, you might have applications. In this particular example, I'm just showing you two toy examples of two applications out there. One application ultimately breaks down into microservices running in pods, connected through a persistent volume to some persistent volume claim. And then the second application ends up also using a database. This shows SQL, but I'll show you a demo with Mongo under the covers. And so that's our second application. Cast and K10 gets installed in the same cluster. Soon as you install it, it works through the Kubernetes API server and it'll go ahead and discover all these applications and the dependency map, like I mentioned. You can go ahead and use the CLI or a user interface that you'll actually see to be able to set up these policies, as we call them, to decide how often you want the applications backed up and where they should be backed up and what those applications need to, how often do they need to be refined and kept in long-term retention. So that's the part which is the policy-driven automation that gets you a way to be able to scale back up in DR in large numbers. And you end up having this into insecurity because not only do we go ahead and make sure we encrypt the content as you move it along when you snapshot it and move it to an object store, we are also, like I said, in the operator certified. So we've gone through a rigorous process ourselves as Cast and K10 to be a part of that. And at the end of the day, the customers, the reason they use us is because extremely simple to use and hopefully some of that sort of shows up as I show you the application. But even though I think OpenShift's done a great job in terms of making it very easy to scale up, operations, one of the main points we hear from our customers is that there is a skills gap shortage. And so to go ahead and make some of these day-to-operations of backup and disaster recovery as seamless as possible, while still giving that flexibility of which environment to use under the covers is the number one ask. So usually it's that that turns out to be really important. But also I should mention that we've been built sort of ground up with our own data mover, serverless type technologies to be able to sort of go ahead and get you the parallelism and the security that one expects from a backup product. So that's really important and close to our hearts do. So with that said, let me do one thing. I want to sort of switch over and let Michael show you what this actually looks like in place. Let me switch over. In this demo, I'm going to demonstrate the backup of a MongoDB database on OpenShift. I have a MongoDB database, deploying OpenShift through HelmShart, a very simple situation actually. It's two-step full set. One-step full set is a MongoDB replica set in the sense of Mongo, not in the sense of Kubernetes. So basically it's two, two pod. One is the primary, the other one is the secondary, and each of them has their persistent volume plan. It's corresponding persistent volume plan. And there is another step full set, which is the arbiter. And the arbiter is responsible of selecting the leader between the two replica set in case of failure one. Okay, so the goal is not to explain all the MongoDB mechanism, but just to demonstrate how we can do a backup on this situation. So once that is deployed, you have installed custom on your Kubernetes, on your OpenShift clusters, and you become able to discover all the applications. But particularly, I'm going to find out my MongoDB application, sorry, MongoDB application, and I can see the two PDC, the two workloads, the two-step full set, and so on, so I'm going to create a policy on that. Okay, so that is the frequency. I can do early frequency with inventory, so I can see the frequency, some sub-frequency. Me, I just want to do on the move. But if I was early, for example, I can choose my retention, which means that as soon as I have reached the 24 backup, the next one will be replaced, the first one is going to be replaced by the 25th, but the first one is going to be promoted weekly, is the grandfather's solution. And I can export my backup, so I can do a snapshot, I mean, a real storage snapshot, and I can export it to a storage location like S3 bucket, for example. I need to choose my profiles, or I have the capacity to define many storage profiles, many location profiles, and I'm choosing this one, which is basically a S3 bucket on the US E-1 region. And I said I'm not going to do it early, I'm just on the move. That's about all. I can select my applications. Here, I'm choosing the simplest situation, which is choosing by the name of the application, but I can choose levels, for example. And in this case, all the namespace having these levels or all the namespace having workloads, getting these levels will be back up. So that's in my case, I just want to do a backup by name so that's going to be the MocoDB one. And that's all. Now, I can also feed the resource if I want. Typically, when you have some weird object, like big LFS PVC in your namespace, and you don't want to backup this one because it's a whole story and it's not supporting any kind of support, like a snapshot support, or it's difficult to make it up, you can just introduce and exclude a filter and say, okay, I want to exclude this air system volume claim which has for them my big PVC excluded. Well, this is not realist, but you can do things like that. And that's very, very useful. Okay, in our case, we, looking for simplicity, we are just going to backup all resources. And you can include also the non-namespaces, namespaces resource, I mean, all the scoped cluster resources, like all the CRD, all the custom world binding, the cluster cluster world binding, all these things could be capturing this part. Okay, and this is a very interesting thing here. You can introduce some hooks before and after the execution of the policy. And for these hooks to work with location profile, you can also define the location profile for the hooks. Okay, we don't need that right now. So let's, let's create a policy. Okay, and I'm going to run it once. And I am, the policy is running now. Okay, so during the time of this run, we can discuss about consistencies because taking snapshot of the volume is a good thing, but it's enough to make a good backup of your MongoDB application. And the answer is often no. And we need to discuss why. So let's see the different strategy that we can use for that. What's the best approach to capture this, this work? Today, we have choose this one, capture a snapshot of each policy. But you can also say, I don't want to make a snapshot. I just want to capture the file system. And is that a good thing? It's not a good thing. And the reason is that if you don't do a snapshot, you are not going to make a crash consistent. And what is crash consistent? Crash consistent means that you capture all the files in the same time. So your file system is consistent with what you have, what you had before the crash. Now, if you don't do a crash consistent backup, you may have file inside your file system which are unconsistent because if you have a big PC, you start to capture your file system at time one, you capture F1 and at time N, you capture FN. But F1 may have changed when you finished the capture of FN. And then you get files that are not exactly in the same time. And that lead you to potential difficulties to restart your workload. So at least this is a minimum. Now, that may be not enough. So let's see that. Just the capture of the PDC for a snapshot is very simple. We just take a snapshot of the PDC, we capture the spec all together, we put that in the restore point in our internal database. And when it comes to restore, we use this reference to rebuild the PDC and to rehydrate the manifest. And that's the minimum. But this solution is not application consistent because for many reasons, you may have many data kept in memory. For example, if you are using tools like Ironmore Kafka, Kafka is putting a lot of data in memory. So if you just capture the snapshot, just the disk snapshot, you probably have some issue with the data that are not flushed on the disk. So you're not application consistent. But we have another solution, which is the logical backup. So what means logical backup? Magical backup means that you capture a dump. And in this case, Kerstin is not going to capture the PDC, the snapshot of the PDC, he's just going to capture the dump. So what we have, we have an extension mechanism that lets you say, okay, I didn't want to capture the PDC on this workflow. I just want to make a dump. And I push this dump to a external location like a S3 bucket. And that's what we call the blueprint. The blueprint is like a recipe that you apply during the backup. And we capture only the logical artifact, which means the dump, and we put the reference in the restore point. And when we restore, then we extract this artifact from the location profile because we have the reference in the restore point and we execute the mongo restore. So this strategy is interesting. It's guaranteed to be application consistent, but it has a serious issue. It's not in the pre-move tool. So what does it mean? It means that if your mongo DB database is a urge mongo DB database with one, I don't know, not one terabyte of the database, imagine one terabyte of data on your mongo dump, on your mongo database, that can happen, actually. So you're going to make a dump of one terabyte and you're going to push to the S3 bucket, this one terabyte. This is going to be too long. This is going to take all your network bandwidth. And that won't work. You're gonna have a very long RPO because the export is going to take too long. So this solution is interesting if your database is under certain size, but not if you are dealing with very big data loss. Let's imagine now that you have a very big data loss. So we still have a solution for that. And that's what we call the consistent snapshot. But basically what does it do? Consistent snapshot. We are able to execute on the pod itself some of the database primitive, database API code, that guarantee you can do a file system backup, files a snapshot, at least. So in the case of mongoDB, this primitive is dysfunctional, F-sync and lock. F-sync lock, sorry, F-sync lock. And F-sync lock is flushing all the right operation in memory in the disk. And it's locking any right operation to keep them in memory. It can't be too long because every right is right in memory and not flushed anymore on the disk. So when you are calling F-sync lock, you'd better have your snapshots immediately finished or the most quickly possible finished. Then when your snapshot is made, and you put the reference here, then you have to call F-sync unlock to make sure that now your database is released back in its previous state, normal working state and back in business as usual. This kind of things, custom is able to support that without any issue. But you need to have such API to support this strategy. And now you have the best of both worlds. The backup is application consistent and it's incremental, which means that we just export to the S3 location, to the external location, it could be NFS as well, it could be a Google container platform, a container, yes, it could be a Google container, it could be a Azure block container, it could be a S3, a WSS3 that could be also S3 compliant and it could be NFS. So this is an ideal situation and custom is able to support that. Okay, so how do we do that? For that we use something that we call blueprint. Blueprint is an extension mechanism that makes sure that the 95% solution which is custom is able to reach the 100% solution, which means that you never have a perfect backup solution unless you have an extension mechanism that let you feel the gap to the perfection. And that's exactly what our extension mechanism, blueprint through the framework Kelly Sir is going to bring to you. The other advantage of blueprint is that they can be shared across the database that you deploy. And if you deploy all your database exactly the same way between namespace in your cluster or between clusters, then you can share them all over the teams and everybody can reuse them. And which one point that I really want to highlight is the ability to use blueprint for database operator. And why I'm speaking about that is because we see more and more that has special open shift that are not deployed anymore with M-sharp or with manual YAML file. They are more and more using operators. Operators is basically a controller which is working with a specific API of the database and they create the database, they maintain the database, they do all the operation that regular human operator should do. And that as a operator is becoming now de facto pattern when we are deploying the database on open shift. An example of one of them is the ETCD operator. So for the ETCD operator, now you don't build your ETCD yourself when you want to deploy an ETCD database on your open shift. So you use an ETCD operator and the ETCD operator is exposing different API to create an ETCD database while you define the number of replicas. But also the ETCD operator, and that's very interesting, is defining a backup API. This is this one. As you can see, it's called a little bit. Yes, this one. So the ETCD API for backup is this way. So you define an ETCD backup object. And you provide some parameters and here you are. You have your backup, suddenly. But it's interesting, but that's the only way to make a backup of your ETCD that has been in this situation. What does it mean? It means that using a snapshot or using any other things is not possible. So that's the only way to do backup with ETCD backup and more and more, that database operator are exposing their backup API. So the question is, how do you deal with that? How do you integrate this in your backup solution? And this extension, you can use the blueprint I show you, is responding to this question. So let's see an example of a blueprint that I wrote for that and this is this one. So what I do, I create a blueprint which is basically executed every time we do a backup on the namespace and we create this API and we reference it in our restore point. So every time we need to restore, we also have, it's not shown here, but the capacity to work with this object that we have created. Yeah, and this way with this extension mechanism, we can say that we also support the operator pattern for the database. Okay, all that said, now we can check our rent policy. Okay, it completed successfully. So the two phases, backup first, where we just do a local snapshot of all the PVC plus a capture of all the manifest in the namespace. Then we export both the manifest and the snapshot to the external storage. This is the export phase. Now if I want to restore this application, I just have to move to the application itself, MongoDB. And I can see all the restore point. I'm going to take the two days restore point. You can see that there is a local restore point if I want to do a fast restore or an exported restore point. If I lose my cluster, for example, and I don't have these snapshots available in my infrastructure because I lose everything, then I can still work with my exported restore point because it's on the S3 bucket and out of my disaster. So I can visit the restore point. I can apply some rules for the restoration, especially some very useful rules like changing the storage class or things like that. And you can choose what you really want to restore. So you have your two snapshots, you have your manifest, and you can decide to not import, for example, this secret because you don't want to have it in your restoration applications. But okay, restoration is also another topic and I don't want to go too far here, but that's all I have for us. So please do not hesitate, ask me questions now. I'm really happy to answer. Or I can have a more deep discuss if you really want to go in the details now. All right, so thanks, Michael, for actually having that walkthrough. I'll just leave you all with this, another QR code really. Hopefully you've got a sense of how we do it. So it was a look behind the scenes in terms of the variety of options we have to be able to back up databases. And some of you are actually running through these issues, we'll appreciate that. And then for folks who just care about going ahead and having a single click operation to be able to back up, export, and then be able to recover when the time is needed, we support that too with the easy to use interface. So with that said, you know, we have a QR code which lets you try cast and gate and completely fully featured. And that is free for you to use for a limited number of nodes. So try that. Or like I was pointing out earlier, you can also go to the Red Hat Marketplace and there are a few different options there also for you to get going immediately. Takes you less than 10 minutes to get this system up and running. And so definitely encourage you to try that.