 Sebastian, let's see the demo of recovery of Bellora backups to AKS cross-account or cross-region. Okay. So here I have a simple AKS cluster running in Azure. The cluster is located in UK South running Kubernetes version 1.24.10. On that cluster, I deployed a very simple application, just a to-do application connected with MySQL database. I added three tasks. What I want to accomplish now is, I want to migrate that application to a completely new cluster located in a different resource group, different location, and using different Kubernetes version. So what I did so far is, on my AKS cluster, I installed Bellora, I took a backup, and I connected that cluster to CloudGasa. So if I go here under configuration general in clusters, I will see here one AKS cluster. You can see Bellora AKS cluster with version 1.24.10. If I click on that, here's a one backup definition with just one run. If I go to recovery points, I see one recovery point copy, that was a copy backup using RESTIC as the uploader type. So what I can do right now is go to Actions, Pick Restore. In the first step, I can select what resources I want to actually restore. So I can go with all namespaces or I can just select some and that's what I'm going to do. I will just restore one namespace. If I wanted to, I can go by labels, or make the restore even more granular and select different resource types from the list. But again, I want to restore full namespace. So I just go with one namespace and disable those two options. Explode Persistent Volumes said to know because I have a persistent data and I want to restore it. Include cluster scope resources. I'm going to leave it as auto, go next from here, create a new cluster, and I'm given a list of three choices. So I can either restore to AWS, EKS, Azure, AKS, and Google GKE. In my case, I'm interested in AKS cluster. So I select that and now I need to select Azure account. So I have only one that I connected with CloudCasa. So I'm going to use that, go next, give a cluster a name. So let's name it Velero, Velero, AKS Cloud Cluster Restore. Once we have that, we go next, choose the resource group. So my source cluster is located in S-Glub, AKS group. So I'm going to choose a different one, region. My source cluster is in UK South, but now I want to go to Europe and the West Europe, Kubernetes version. The source cluster is running on 1.24.10. I want to see if with 1.25.5 everything works fine. So I select that, provide client and client secret that will be used by the cluster. So here's the client ID and the client secret. Now I can go next, select networking type. So I can go with KubeNet or Azure sets up every networking aspect for you, or you can go with Azure CNI and customize the setting a little bit. But again, for a segment of simplicity, I will go with KubeNet. Go next, note polls. So I will have only one note poll with standard B2 West, a very small VM, and I will enable auto-scaling option here. I want to start with at least two nodes having max of, let's say three, and a desired size of two. Go next, cluster add-ons. As of now, I'm not interested in any of them, so I'll just simply skip this step. And here's the most important part. So Velero options. At the very top, you see the backup time BSL info, and you can see that the BSL used Azure service principle as the authentication method. Backups are located in container called Velero, and that container is present in storage account, SG Velero storage account. So now I can select the Velero server options. You can see that my source cluster was running Velero 1.10.1, but I want to change that and use now 1.10.2, which is a newer version. Namespace, I'm going to leave Velero as well. And here I can select an authentication method that will be used by the BSL on the restored cluster. So you can see that the source one was Azure service principle, but there is no problem if you want to go with, for example, storage account access key, and that's what I'm going to do. So I will just copy and paste storage account access key here. Go next, restore transforms. This is an optional step when I can rename namespaces, select an option to preserve node boards or even override existing resources if already present. Go next, post restore app hooks. So for me, there is nothing to be done after the restore. So I just skip this step, go next, and the last step, which is summary, everything that we selected so far, we can give a restore name. So for example, Velero AKS Cloud Restore and click that restore button. But just before this presentation, I run a run restore so that we don't have to wait for cluster to come up. So if I go to dashboard in the right-hand side under activity IC, my restore that I run, I click on that, go to activity log, you can see everything that happened. So let me quickly explain what's happening for that advanced cloud recovery feature. So the first step is we create AKS cluster and we wait for that cluster to be available on Azure. Once that is done, we install our CloudCasa agent on it and wait for the agent to connect to CloudCasa service. Once that happens, we download Velero. You can see the version that we selected, one that 10.2. We install the Velero on the restored cluster. Once the Velero is there, we create the BSL. We wait for the BSL to be available. Once that is done, we just wait for all the backups to sync. And once all the backups are on the restored cluster, we let Velero know that the restore can happen. And that's what actually you can see here that we restored 17 out of 17 resources that was a very small namespace and the restore was successful. So if I go to Azure portal, I can see my new cluster over here. Resource group is the one that we selected. Kubernetes version 1.25.5, the one that we selected and also location to West Europe as we want it. So if I go now to cluster, service and ingress, and here is my to-do app. And if I click on that, I can see my to-do application with the exact same task as we had on the source cluster with the only difference being the IP address. So that's how easy it is to perform a cloud migration from the Velero backups for AKS. Excellent, thank you. Now let's see a recovery of Velero backups to EKS. Okay, so here's a part where I demonstrate EKS Velero backup recovery to EKS cluster. So here I have a simple EKS cluster running with only two nodes and having Kubernetes version 1.25. And that cluster is running a very simple to-do application with just two tasks. That to-do app is connected with a MySQL database. And what I want to achieve is I want to take that data, take that application and migrate it to a new cluster, which is located in a, which I want it to be located in a different region. So my source cluster is located in EU central one, which is Frankfurt. And I want to take that application and go to a different region. So what I did so far is I installed Velero. I did a full cluster backup. And now what I also did was I connected that cluster to Cloud CASA. So if I go to configuration clusters, I can see my EKS cluster over here. I can click on that. I see my to-do app backup over here. And if I go to recovery points, there's a one recovery point for my backup. So I can go to actions, click restore. In the first step, I can decide what I want to restore. So go all namespaces and exclude some or I can just select a few. And that's what I'm going to do. I'm going to just restore one namespace. If I want to, I can go, I can select labels. I can select different resource type. But again, I want to just restore, fully restore one namespace. So I am going to disable those options. I exclude persistent volumes set to no because I have a persistent volume. I want it to be restore. So that option is set to no and include clusters called resources. I'm going to leave it as auto. Going next, select destination, creating new cluster. And from here, we can select EKS cluster and we'd be asked to provide a cloud account. So I have a one AWS cloud account QBR team that is connected to my cloud CASA. So I'm going to use that, click next. Now I'm in a EKS options step. So provide a cluster name. Can make it fellow EKS cloud cluster restore. Go next, from here, select AWS user. So I created one for purpose. So that's the user I want to use. Region, as you remember my source cluster is located in EU central one, which is Frankfurt. And now I want to migrate to a different location. So I will go with EU west tool, which is London. From here, I can select EKS cluster cluster role. So I have one over here. Kubernetes version, I'm going to go with 1.25 as well. Go next, networking, select the VPC where I want my cluster to be located. Subnet group, I can select one or I can select many. So I'd select all three of them. And VPC security group, that step is optional. And I would just use default VPC security group. Go next to the node pool settings. I will add just one node pool, node IEM role. I created one as well. So let me use that. VM size, that's a very simple app. So a medium, T2 medium VM shoot to the work. Disk size, 50 gigabytes is fine. And number of nodes, we can have at least two max of four and a desired size of two. Go next, we can select cluster items. And from that list, I'm going to enable EBS CSI driver because my source cluster uses EBS CSI driver. And I want my new cluster to use that as well. So I enable that, select role, go next. Valor options, here we can see the backup time BSL info. So you can see that my backup, here's the name of my backup and where it's region, where it's located. So it's US East One. And the authentication method used at the backup time, which is AWS IEM role or AWS IRSA. Now I can select Valero server options. So my source cluster used one that 10.1 but for the research, I want to use one that 10.2. Name space, I'm going to keep Valero. And as authentication method, I don't want to use IRSA now. I want to use AWS credentials. So I need to provide access key and a secret key. So let me quickly copy and paste those values. Go next, restore transforms where I can rename the namespaces if I want. I can give a brand new name or I can make it more general and add prefix or postfix. I can preserve notepads or even if I want to, I can override existing resources. But from that list, I'm not interested in any of that transformation. Going next, post restore outputs. For me, there's nothing to do after the restore so I can skip this step. Go next and just quickly name the, you can see here a summary and we can give the restore a name. But again, before this demonstration, I already run one restore so that we don't have to wait for cluster to come up. So if I go to dashboard and if I go to a next page, I believe, there will be one restore and here it is, Valero EKS cluster cloud restore. I can click that, go to activity log and can see everything that happened. So the first step is create EKS cluster, install all the required add-ins, wait for the cluster to be available on AWS. Once we have the cluster, we can add node groups, set up the access, set up IEM roles. Once we have that, we can install that EBS CSI driver that we selected. Once that is done, we start the actual restore. So we first download Valero, the version that we selected, 1.10.2. We install that Valero. Once Valero is installed on the restore cluster, what we do is we create the BSL, we wait for the BSL to be in available state. Once that happens, we wait for all the backups to sync on the restore cluster and then we perform a restore which you can see at the very bottom here that we restored 17 out of 17 resources, a small namespace, very simple app and the restore was successful. So now if I go to clusters on my AWS console, you can see location is now London and I can see my newly restored cluster over here. If I click on that and the compute, I can see two extensive T2 medium as we selected. And if I go to resources, service networking services to do app, I can see the load balancer URL which I already opened over here. And you can see that newly restored application with the exact same data as we had on the source cluster with the only difference you can see in the URL. So that one is EUS2 and our source cluster was EU central one. And that's how easy it is to take a Valero backup and restore it to a brand new EKS cluster. Thank you so much for taking time out today and show these demos to us. And as usual, I would love to have you folks back on the show. Thank you. Thank you so much.