 Hey, everyone. Thanks for coming by. My name is Shin Horiyuchi. I'm with Trilio Data. We are backup recover managed for OpenStack. And what I'd like to do is kind of go over who we are, what we do, and then go over a little demo of how our product works and give a demo of a migration scenario. So in a cloud environment, what you'll see here is, why is cloud native backup important? What you'll see from, obviously, everyone's journey into the cloud is that you'll try to use your legacy data protection tools. And you'll see that, obviously, they're agent-based, heavy, hardware-dependent. You've got vendor lock, obviously, some scripting involved for specific types of applications. And then you're locked into a central IT and ticket-based system for support. And that really isn't adhered to anything like the cloud. So what's important to cloud native data protection is that we want to be able to leverage your native OpenStack APIs, software only, vendor agnostic. So you're not locked into anything. Automated integration, and then really from a cloud perspective, OpenStack perspective, is that we're really focused on self-service management via tenant-driven control. OK, now, how we can help or how we help the OpenStack journey to come to completion is that, number one, we're agent-less, focused on multi-tenancy, self-service model from by default, scalable as your cloud grows, we'll grow with it. We're non-disruptive, and we're OpenStack integrated. Number one important thing there. But Trilio is actually not just data backup and protection. It's beyond backup. And what I mean by that is the recovery. Backup is really only half the battle. But when you get into the recovery, that's where we really shine. So from a local backup recovery, we have file and folder recoveries, virtual machine recoveries, entire tenant workload recoveries, and then also disaster recovery scenarios there. Then on top of that, a couple of use cases here from obviously from an OpenStack perspective, depending on where you are in your journey, tenant-to-tenant migration, availability zone migration, distribution migration, and version migration. Now, I'll go a little bit deeper into these as we get through a couple of the slides. But Trilio really integrates with everything that is OpenStack, meaning we leverage all the native OpenAPI services, a Neutron, your Novas, your Cinders, your Glances. We are compatible with all the different distributions. And then from a target repository perspective, again, these are the different types of protocols that we support. And what really differentiates us from anyone else out there in the marketplace is that the way that we capture the data. We not only capture the data, but the metadata of the full tenant's workload. And what I mean by that is we'll leverage your OpenStack native APIs to get the metadata of your VM. So for example, we'll get your networking information from Neutron, your VM information from Nova, your volume configurations from Cinder, and then your Glance images from Glance. And then we capture everything in an incremental, forever fashion. So a couple of things here from a use case perspective. So we've covered backup and recovery. So we have your local VM recoveries, backup and recoveries. We have our file and folder recoveries. We also have our tenant recoveries within the cloud. And then once we get into the kind of fun stuff here is what else we can do beyond backup and recovery is the migration perspective. Everyone has a different perspective on how they can use the cloud, how their journey has changed throughout the years. And so from a tenant workload perspective, what we can do here is backup from a tenant within a specific cloud, and then restore that to a new tenant. So for example, if you have a pre-prod tenant, do your testing there, do your backups, and then recover or migrate that to a new tenant within that cloud and call that production. Another idea here is take a backup from tenant one, import or migrate the workloads to a new cloud tenant as well. Another use case here is availability zone. Let's say, for example, you have AZ East, AZ West. And AZ East is starting to get a little saturated. You want to start to do some load balancing from a VM perspective or a workload perspective. You can pick and choose a couple of workloads to say, hey, I'm going to move these over from AZ East to AZ West to load balance everything across. And then from an upgrade or OpenSec version migration, let's say you're on Okada, you're looking to migrate over to a new cloud on Queens. Same idea, backup everything from a tenant workload perspective, restore that back into a new cloud on Queens. Same idea, distribution. So let's say you're on upstream and waiting the waters there saying, everything looks good, but now I want to jump in the boat with one of the main distributions here. You can do that type of migration as well. And then one last thing here is disaster recovery. So let's say you have OpenSec Cloud 1 and 2. And 2 is kind of you have that cloud stood up ready to go. OpenSec Cloud 1, you've got Trilio Vault as the backup solution. You do your local backups here. You would replicate the target and then recover into that cloud from there. So that kind of use cases, backup recovery and use cases there. So we are in booth C2 right there, kind of a little hike from here, but I'd like to get into a demo from here show you what it looks like from a OpenSec integration perspective and then a demo of a tenant migration. So I'll log into this cloud here. And so what you'll see here from a tenant level perspective and our horizon integration, you'll see that the new tab here is exposed called backups. Within backups, you'll see something called workloads. Now, a workload to Trilio is a logical grouping that answers your four main backup questions. What do we want to backup? When do we want to back it up? How often do you want to back it up? And how long do you want to retain the data for? So if we look at one of these workloads here, you'll see Cloud Bronze. And if we look here, you'll see that there's three VMs that are being protected. And then the policy or the protection scheme tied to that is right here. So you have your start date, start time, end date. You repeat every RPO. How often do you want to back it up? And then your retention policy can be set in one of two ways. As you can see here, either the number of snapshots to keep or the number of days to retain a backup. So if we go back in here, we'll take a look at these snapshots here. And as you can see, these are all the backups that are available for recoveries. And as you can see here, if you go to the first, it's a full first and then incremental forever fashion backup. So each one of these is a synthetic full backup that is fully mountable, fully accessible, and fully recoverable. And if we look at one of these backups here, what you'll see is not only the data that's being backed up, but the metadata of that VM or the tenant's workload backed up here. So VM 6, 10, and 8, you'll see that there's IPs that are tied to them. We'll get the security groups, the flavor of the VM, any networks that are attached, any volumes that are attached, data volumes, and then the ID of the VM. Now this type of data is captured at every backup. So for example, if someone adds a new NIC or changes the network type or anything like that, we'll capture that at every backup. I focused a lot on the backup side of things, but that's really, again, only half the battle. So if we look at different scenarios from a local recovery perspective, your worst case scenarios, these VMs are gone. Someone has deleted them. So to recover these, you use a one-click restore. Now this one-click restore will take this specific point in time backup and restore it as of this configuration back to its source location. The other types of, the more granular level of recoveries are what we call an in-place restore. And this gives the tenant or the user the ability to pick and choose specific volumes out of those VMs to recover. For example here, if we take VM 6 and we say, all right, this VM isn't booting, but we think that we believe the data disk is fine. We take it, we can click here and say, restore just the boot disk. If we go to VM 10, for example here, we say, all right, it boots fine, but the data disk is corrupt, let's restore just that. And if we go to VM 8 here, we can say, all right, this guy's fine, don't touch it. So that's back to the source location. Another granular level recover you have here is selective restore. This gives the tenant the ability to use a copy of a production VM, for example, in a pre-prod environment or a testing environment for test devs. All you can do here is change the network mapping of the VM to maybe like a private internal network or something like that. Change the volume type mapping. So if the destination has a different type of storage, you can use that. And then again, at a per VM level, let's say for example, we wanna test VM 6 as a production VM and you wanna copy of it in a different availability zone. We can do that here. We name the VM. You can change the flavor of the VM. Then you can actually stand this VM up in a new availability zone. Again, test dev availability zone, anything like that. Test it. Again, VM 10, same idea if you wanna rename it. Get a copy of it. Change the availability zone. All right, so it's a really useful tool from a test dev perspective. All right, and then the most granular level of recovery. You know, you're typically, you know, the users aren't gonna ask for a volume level recovery or VM recovery, but they wanna just pick a file or a folder that they'd like to recover. So that option, the last option here is called the mount. And what we wanna do here is also show you a file search. So let's say for example, VM 10, we're looking for, someone had modified the Etsy host in this application, so it's not talking to the other servers, IP was changed, anything like that. What you can do here is search against all the snapshots, a list of maybe the last three snapshots here or specify a specific date range. And what we can do is search against the backup images that we store, and the search criteria will show the results. Now, after the search results come back, what you'll see are the three, whoops, the three images from the search criteria. And if we expand all, you'll see the search results here. So you can see your modified time, access time, and the file names from the search. And then from there, they can identify the backup, where the file is that they wanna access, and then go in here and mount that snapshot. Now, I have one mounted already, but the process would look like this. If we go to mount the snapshot, you'll choose what we call a file recovery manager. Now, this is a VM that is a public glance image that we would ship to the Cloud Admin and make it available to the tenant, so that they would spin up this VM and mount our backups to, kind of acting like a proxy host. So once that's been mounted, what you would do is browse to that file manager VM, and what you'll see here is, since we've mounted the entire backup, you'll see all the data that's associated with that backup. And then the user can go in, drill down into the folder, to the file that they wanna get. So let's see, Etsy host, for example. They can download this locally here on their local machine, or they can SSH into this VM and SCP the file over to a target location. So what I'd like to show you next is a use case example of a tenant level migration within a cloud. Now, this example can be used from a tenant in one cloud to a tenant in a new cloud as well. All right, so you'll see here that there's two workloads, a demo workload and a summit VM workload. And within those workloads, you'll see some VMs here. All right, and for one of these migrations, there's a couple of bits of information that you'll need. So what you'll need to do is identify the tenant ID of where you wanna migrate your workloads from and where you wanna migrate them to. So what you'll see here is, you'll go to the projects here, identify the tenant ID of where the workload is now and where you want the workloads to be migrated to. And then you'll identify the user that has the right privileges to be able to execute this type of command. This will typically be done by a cloud admin that has access to the ChilliAvult VM or the workload manager here. So what you can do here is list out and double check all the workloads that you want to migrate. And what you'll see here is that the IDs, the two workloads that you wanna migrate and the IDs that are associated with them, the project IDs. And then what you'll do here is specify with a workload reassign command the old tenant ID, which is the current one, and then a new tenant ID that you wanna migrate the data to. So we'll see here this command here. So old tenant will be the current tenant. So copy and paste that over here. And then we'll assign it to a new tenant, which again, this can be within the same cloud or a new cloud. So we'll get the ID of that new cloud here or a new ID here, paste that in. And then we'll get the user ID that has the right privileges to be able to do this. Now, once this command has been executed, what you'll see from a result is the workloads and their new project IDs that they're assigned to. And then we'll log into the cloud as that tenant or get into that tenant. And we'll see here that from an instance perspective, Summit DR is the new tenant. From an instance, there are no instances. There are no volumes. And then we'll go to the backups tab here and see that the workloads are now present in this tenant workspace. And from a recovery perspective, what you'll do is identify a point in time that you wanna restore into this new tenant workspace. We'll run a selective restore. We'll name the restore from auditing purposes what was this done for and why. This is where we can choose a network mapping on this new cloud or the current cloud I wanna bring these VMs up onto this new network, change the volume type mapping if this new cloud has that. And then at a per VM level, we can choose if we wanna change the name or anything like that. And then we'll hit restore here. So this will take from the target repository and restore this back into the new tenant workspace. So once that is completed, just see here it's executing and available, what you can go back now and see is that the tenant workspace, if you go to your instances, you'll see that now there are five VMs from that workload have been restored into this new tenant workspace. And then the volumes that are all associated with them as well. And then again, if you'd like to, you can go in to do the other workload to get the full tenants workloads migrated over, same type of operation. You do the selective restore. Change the network mapping if you want. Change the volume type mapping. And then again, from a each VM perspective, if you don't wanna include one of these VMs, you can uncheck it, exclude it, and then hit the restore button. And this will show the last few VMs as well, being migrated over. Once that's available, double check the instances. Now that the other three VMs are there. So all eight VMs from that tenant's workspaces are now in this new tenant. And then the volumes that are attached as well. And then if you'd like from that point forward, if this is going from a pre-prod to a production environment, you can actually enable protection against those VMs again by just going into the workload, editing those, and turning the scheduler back on. And that's it. I mean, it's as easy as it looks and it's even more powerful than it is as well. So appreciate the time. Thank you very much.