Video: Hypervisor Freedom across European Enterprises | Duration: 2708s | Summary: Hypervisor Freedom across European Enterprises | Chapters: Introduction and Welcome (21.225s), Hidden Migration Costs (95.735s), Rubrik's Security Framework (299.925s), Rubrik's Architecture (454.265s), Zero Trust Protection (528.875s), Data Threat Analytics (717.335s), Recovery Orchestration (1135.145s), Hypervisor Support Roadmap (1374.365s), Live Demo Walkthrough (1627.385s), Customer Success Story (2334.025s)
Transcript for "Hypervisor Freedom across European Enterprises":
Hello, everybody. Thank you all for joining me. My name is Brian Knutson. I am a senior technical marketing manager with Rubrik. I'm here to to talk a little bit about, hypervisor freedom and and how Rubrik can help you, to protect your entire environment regardless of where you are within your hypervisor, journey. So from a... From an agenda perspective, I'm gonna talk about that that journey aspect of things and, you know, some of the things that you need to start thinking about. Are you ready to to modernize your your hypervisor environment? Then we'll talk, quite a bit about Rubik. That's what we're really here to to focus on is is the Rubik piece of things. So, several different topics that we'll we'll cover off on here. And then I'll do a quick demo, kinda show you what the interface looks like, what a, example of of what you might go through as a Rubrik customers before you make the migration and what that would look like and and how it would help you through that process. And then finally, we'll talk about, this customer testimonial, that, like I said, is in the is in the docs tab if you wanna pull down that, that story that that we documented in there. So with that, we can go ahead and get started and talk about kind of this unexpected journey that you may be on. Knowing that, you know, the whole Broadcom situation is the one that most of us think about, but, you know, this has been happening since before the VMware Broadcom acquisition happened where, you know, you start talking about Kubernetes and trying to move things into containers, trying to move things into more cost effective means. By no means is, Broadcom's acquisition of VMware the forcing function. It is for a lot of customers, but by no means is it the only one that's forcing customers through this. And it is it is a murky woods. There is a lot of questions and unknown and different paths that you can go down. And and I'm assuming if you're here, you're probably at least considering, something like this. The real challenge ends up being to not only consider which hypervisor is the right right one to move to, but what else has to change, and what other aspects of your environment are are going to be affected by swapping out that hypervisor. Swapping out what has become kinda central to a lot of our infrastructures these days, because it's it's not something that stands alone. There's a lot of stuff that is built built up around it. And it leads us to the hidden costs, the hidden risks of modernization, where, you know, replacing your hypervisors above the waterline, but below the waterline, there's a lot of other things. One thing that, a lot of customers run into, and this is this is nothing new at this particular point in time, I experienced it when we started moving into virtualization in the first place is who owns this application? Who's in charge with it? Who's who's gonna make the ultimate decisions on things? You know, because as part of changing out your infrastructure, you may relook at who's responsible for managing the virtual machines, who's responsible for defining the data protection aspect of things, what what kind of changes maybe need to occur along the way, you know, if a if a decision has to be made about how to change things, what's that change gonna look like, and who's ultimately we're gonna be responsible for it. And that's not just within IT as to, you know, who might be managing it, but also on the business side of things. You know, who in the business owns that particular application sometimes isn't always known by the IT team. Then we talk about security. Obviously, every conversation has to do with security these days, because it is a, it's a team sport. It's something that everybody has to play a role in. And so understanding, how security is working within that hypervisor environment, within that application, within the operating system, that could potentially be changing, because it may be tied directly into your vSphere infrastructure or your SCVMM infrastructure for Hyper V. If it's tied directly into that and you swap that out with something else, do you end up with a gap as you move things over? And if you don't consider it ahead of time, you may leave your virtual environment kind of exposed for a while. And then finally, when we talk about native tools, there's there's a lot of things that VMware may be taking care of for you today that, on the other side, isn't being taken care of through those native tools. How are you gonna replace those? How are you going to cover those things? How are you gonna ensure that the functionality that you had before is going to continue on the new side? Or, you know, maybe you decided you don't need that functionality. It's not important to your day to day business. Those types of things need to be considered ahead of time. So let's talk a bit about Rubrik and how we fit into this. We're really focused on making sure that when you do the migration, that you end up moving over clean environment and, ensuring that you stay clean once you get migrated over, both from a, you know, what... What's sensitive in that information within that virtual machine, what data maybe shouldn't be in there, but, also, when we talk about, threats and making sure that, you know, malware isn't existent within there. So we really focus at Rubrik on kind of four main things when it comes to helping you through your modernization journey. The first is making sure you've got unified visibility, making sure that no matter where your workloads exist, that your data security aspect of things that Rubrik is managing stays consistent. And, you know, we do that through very strong interface focus. Secondarily is a zero trust security. Really, what this kinda comes down to is if if you're protecting your data and that... If the entire environment has to be burnt down because of a of a malware outbreak or because of some sort of malicious insider threat, AI also comes into play here where it can go rogue and do crazy things. If everything else gets destroyed, your data protection should still be there. It should be the last thing standing, and we focus a lot on that. Data threat analytics is that ability to find that malware, to identify the blast radius of of an event that happens, making sure that, you have visibility into what's going on there. And we've got a lot of really unique capabilities within that space. And then finally, all of this really ties into the final step, which is having a clean recovery. Being able to very quickly identify what points in time are clean, which points in time are not clean, whether that be ransomware, anomaly detection, or it... Well... And, being able to quickly get to that point and get it restored very, very quickly and effortlessly. So we're gonna dig into each of these. That's gonna be kind of the the rest of... That's kinda your... What's gonna come with the rest of this Rubik conversation. So, really, to the point of this of this webinar is different hypervisors, same Rubik. It doesn't matter which of these, hypervisors you happen to be on. We've got you covered, and quite frankly, it's gonna look the same to you from a Rubrik perspective. Your security aspect of things is gonna be consistent through here as well, including any integrations that you've done between Rubrik and your your security tools, to be able to benefit from what Rubrik's able to detect there. So this is... This will be a big part of what I show in in the demonstration is, you know, whether you're going through vSphere, Hyper V, HV, whatever, it's gonna look very similar. When it comes to the Rubrik piece of things itself, we can go back, you know, twelve, thirteen years when Rubrik was first invented, was first incorporated as a business. The focus was to say, hey. This legacy backup and recovery infrastructure concept isn't working very well. You've got your software in one place. You've got your data in another place. Maybe you even got your metadata in a third place, and they all work across the network, which leaves a lot of trust between these different systems. So as we look at how to migrate the environment into something a little bit more secure, a little bit more... Little bit less vulnerable, we said, hey. Let's combine this all into a hyperconverged type appliance where all of the data, all of the software, all of the metadata exists within one place. And we built on top of that what we call our native data threat engine, which then locks a lot of other capabilities that Rubrik... That we'll talk about with Rubrik, all on the zero trust type of of architecture, designed to be immutable. So the backups are stored in a file system that was immutable by design. It it is the... It's not only the default, it's the only way we sort data. And so this really kinda plays into that. Hey. This is gonna be the last thing standing should everything else get, get destroyed for whatever reason. So that really takes us to the zero trust data protection side of things. Another aspect that that folds into this is making it simple. So the more simple the infrastructure is, the less likely something bad is going to happen. So simplifying things by having a very declarative backup rules. You say, I wanna backed up this frequently and retained for this long, and we go and do it. No more having to define schedules and and managing those through the life cycle as as this database gets really large and starts pushing its window out, other things need to be moved. You don't have to deal with any of that with Rubik anymore. And it will manage this data through its entire life cycle. So setting those retentions, allows us to, be able to to monitor that and ensure that it's going to be maintained throughout its entire life cycle, and then being able to identify when there's new things. So instead of connecting you to virtual machines and setting up jobs for individual virtual machines, instead, we're having you connect to the management layer. And through that management layer, we will regularly pull it to make sure that you are backing everything up appropriately, that everything is getting properly protected to ensure that your data is is safe and secure. And then when we capture that data, we do a lot of different things, and this is just gonna be the tip of the iceberg, again, to use that same metaphor, about how we're going to keep your data safe. So it's not just about having an immutable file system. It's not just about keeping the data off the network so they can't be directly addressed across the network, but things like being able to to to put that air gap in there so that it can't be directly addressed, Being able to encrypt it at rest so that even if they get into the Rubrik system, they can't do anything with the data. It's a huge risk factor. Getting access to backups means you get access to all of the data across time. Making sure that it's immutable, as I mentioned. Accessing the data itself can be controlled very, very granularly with role based authorization and roles. Being able to have that retention lock to say, if if anybody wants to try to change the retention to reduce the time in which it's kept and cause it to be deleted early, that's a major risk of your of your, you know, your protection of your data. And so we we have the capability of saying, hey. We're gonna lock that out, so that, nobody can can make those changes without the proper permissions. And then having just this ultimate backstop, which is intelligent data lock. If for some reason a bunch of backups get deleted, if it's abnormal, you know, we saw, hey, the retention got changed and all of a sudden a bunch of stuff got deleted, we're gonna throw that into, essentially, like, a recycling bin. We're not gonna truly delete that data. We're gonna take it offline. We're gonna make it unavailable to you as a customer and potentially the threat actor, and then you would have to call Rubrik, and then Rubrik would have the ability to unlock that data back back into your environment. So giving you a very strong out should something catastrophic really happen. All of these things, amongst many other things, quorum authorization is is another big piece of this, that, help to protect the data. So we don't rely on any one layer. We rely on multiple layers because, you know, if if one thing has been proven with threat actors is that they're they're wily, and they will find a way, eventually through one layer. So we need to have multiple layers. Typical defense in-depth. So as we talk about the data threat analytics, we've got this data. We've got it protected. Let's talk about what we do with that data, because Rubrik has introduced that data threat engine. So as backups come in, the first thing we're going to do with Rubrik, and this is gonna happen on premises on an appliance. This isn't anything that that Rubrik as a company will see. This is Rubrik as a product in your environment. We'll see. Similar, when we talk about cloud and SaaS workloads. It's it's gonna be an area dedicated to you. First thing we're gonna do is we're gonna index that data. We're gonna see what's in there. We're gonna try and keep track of it. You know, what time was it? Which workload was it? What change? What what metadata do we need to apply to it? And then based on that, what we're going to do is we're gonna feed that into what we call anomaly detection. And this is a multi phased, approach to things using machine learning to look for, you know, massive deletions, massive additions, massive changes, looking to see things like extensions that have changed within the files, to try to... And amongst other things, to identify, hey. This is something fishy going on. This is abnormal. Let's let's put a put a mark on this and and note that. And then being able to then take it through a second phase and look for encryption and say, hey. Given the deletions and the changes or the the deletions and additions, is this a ransomware event? Is this something very specific? And and be able to put the extra notation on there. We're gonna try to detect what, ransomware group may may have, caused this. All of this is done really to help you to more easily pinpoint where things happen and what may have happened there, which is all indicators to the blast radius and where, the the clean recovery point should be, thereby minimizing the amount of data loss, minimizing the amount of time that you, you lose trying to get it back up and running. The next thing we're gonna do is we're gonna look for sensitive data. So, yeah, we've got all that data locally in that Rubik appliance or or in your environment, where we can look through it and say, hey. What data changed? What type of data was in there? How can we classify it, with with kind of pre prescribed classification engine and policies that go along with that? And then looking through that to say, hey. If ransomware were to happen, we've got an investigation task... Dashboard that says, okay. A bunch of changes happened at this point, and this was the state of the sensitive data on that particular object, making those connections very quickly. So that should a ransomware event happen or any sort of event happen, we'll assume that, hey, this day has been exfiltrated, and you're gonna have to report on that to some authorities. And being able to make that super easy for you to get to that in... In... To that point in time. It also helps on the on the front end. So, if you wanna be, kinda prescribed about this and and try to reduce that attack surface as much as possible ahead of time, you've got a guide as to, hey. This kinda HIPAA data exists on this particular system. Well, it shouldn't be on that system. Let's go investigate that. It gives you that capability to be able to identify that and go looking for it to try and clean it up. So a lot of a lot of good capabilities out of that. The final thing we'll do, again, at the time of backup, when that backup lands within the Rubik environment, we're gonna do what we call threat monitoring. And this is this is a really cool capability where, again, we're gonna index what changed, and we're gonna have a list of what changed. So we're gonna run that through this process where through multiple potential inputs, you've got a threat feed that comes into into your environment. And we're going to apply, a combination of Yara rules and hashes through all... Through those... That combined threat feed and look through what changes happened within that particular point in time, that snapshot, that backup, and say, hey. If we if we hit matches on any of those those rules, we can then put it into a dashboard. We can create alerts. We can allow you to have awareness of the fact that this most recent backup has a threat within it. And as as these, feeds get updated and new threats are added to them, we'll go back and we'll look at all of your points in time and say, hey. There is a new hash that got added, and and and we found it in some older... It started on this day through this day. We see we see this particular indicator of compromise. So kind of a a warning signal. Now, ideally, your EDR tools are gonna find that, before it ever gets to the backups. But if it does get in the backups... Because, you know what, they're trying to avoid EDR. They're gonna shut down EDR. They're gonna hide in places where EDR doesn't exist. They're gonna they're gonna hide in situations in which you may not see it actively, but we can see it through points in time differences. A recent one... Example of that is is Brickstorm, where they were attacking, virtual appliances and things like the vCenter Server appliance, things like an f five firewall. Those things generally don't have an EDR agent running on them, which means they're not actively looking for those, those threats and something that we will be able to do there. So final thing that we do kind of from a data threat perspective is to, provide this threat hunting capability. Now this is not at the backup time. This is an on demand activity. So you as a user, or some sort of system to system initiated thing, all this is API based, so it's very easy to to kick off through an API, allows you to identify your rules and hashes that you wanna go searching for. And you can identify the systems. You can identify the time frames with this search, but it'll go back and it'll search through all these all these snapshots, all these points in time to identify should any of these things exist in those points in time. So when an event happens, you get an alert from anomaly detection, you get an alert from threat monitoring, and you wanna go back through time and say, hey. Has this existed before? Or the security team comes at us and says, hey. We found this thing, and we hear Rubik has some capability. We wanna see if you can help us identify when it introduced to our environment, and they give you a hash. You're able to very quickly search through, all those snapshots to find that. And there's... They're both advanced and and turbo threat hunting, that go different layers with with different search criteria that go with them, that can allow you within seconds potentially to be able to identify all the places where a particular file hash may exist. Now we get to the point where this kinda all starts to converge together, when we start talking about recovery. And so, you know, no two ransomware attacks are the same. No two recovery situations are going to be similar. So we give you a lot of different options here. And this is where, from a multi hypervisor perspective, things can vary quite a bit. Not every one of the, hypervisors is going to allow us to do all the different types of recoveries. And and we'll talk about kinda where we are in the maturity with different hypervisors perspective. But, no, this is one of those things that can, you know, start small and and will grow over time. As hypervisors mature, as our, integrations with those hypervisors mature, more of these will be added. This is kind of a superset that I'm showing here. So a lot of capabilities around this, and and our goal really is to to try to find innovative ways with which to restore that data to get it up and running as quickly as possible. Because, ultimately, that's what's gonna matter should should an event happen. Of course, once we've once we've got the ability to restore, we wanna orchestrate this. And this is our... Kinda comes back from years and years and years of doing disaster recovery. We've got that, of course, but also the ability to, use kinda that same orchestration concept to do, recovery after a cyber event. Recovery after a cyber event. So we wanna restore our entire environment into an IRA, for example, and and get that up and running in a place where we know is clean, that we can start to either look for, what's going on in the environment through that malware or start to recover the production in a place where we know that the malware doesn't already exist. So being able to use everything that I've talked about up to this point to help drive that is a big focus for us. So what you see on the the screenshot here, you could say, you know, pick the most recent snapshot taken by this by this point in time, and then only pick... Only give me the options that are non quarantine and non anomalous. So really tying into all of the work that we've already done. And and mind you, that all... That work happens during the backup process, maybe as a point in time with threat hunting. All of that's already documented, already listed within the metadata of all of these backups. And so when you come into this, recovery orchestration, you can take advantage of that almost immediately and be able to to know very quickly which points in time you shouldn't restore. In fact, with role based authorization, you can actually prevent your standard admin accounts that you would use to do this restoration. You can prevent it from even accessing those points in time. You know, you can make those super super admin accounts that have access to that, or only the security team has access to quarantine points in time. So a lot of really cool capabilities to reduce the likelihood of bad things getting reintroduced into the environment. Now, of course, we wanna we wanna test these things. We wanna make sure these things are operating the way that we want them to, and so we've got the capability to to automate a lot of this. So being able to use out of band management, to to instantiate into clean rooms, to be able to say, hey. We've got a, rubric infrastructure within our clean room, within our IRE to be able to ensure that we're not crossing that boundary at recovery time. Being able to create plans to be able to say, hey. We already know what the orchestration needs to look like. Let's define that ahead of time. So it's just push a button and go. Again, years of disaster recovery help us a lot in the cyber event situation. So... And and and a lot of strong focus on introducing more more of the workloads that we can protect into the orchestration engine, more capabilities around being able to rebuild the environment itself. Our our focus is that we have to continuously make this improvement so that you have a better opportunity to, restore things and, more importantly, restore clean as quick as possible. And then finally, to be able to to report on this because, of course, auditors, the board, senior management, they're looking to know that you can prove that you can do these recoveries. And so being able to literally schedule this to run every Sunday night, send me the report when it's done, and forward that report on Monday morning to to the people that need to see it, and they can see did it succeed, how long it took, where the failure points were, things like that very quickly and easily. As promised, I kinda wanna end on where we are, in our hypervisor journey, to support multiple hypervisors. For a decade, we've had vSphere, decade plus. We we launched with vSphere, support, and that's always going to kinda be our our top, Cadillac version, if you will, because it is so mature, and vSphere is so mature as a platform. HV and, from Nutanix and Hyper V for Microsoft, of course, are two long term hypervisors that have been out there for a long time. We supported both of those for a very long time. So those are also very mature at this point and and getting pretty much to feature parity with with the Visa side of things. Those are the most likely hypervisors you're gonna be starting at. What we've seen is the surge of net new, hypervisors coming out. Some of these have existed for a long time and and are just now becoming popularized because people are being on this unexpected journey. But, you know, things like OpenStack, things like OLVM, Proxmox has been, you know, the really hot one lately that's kinda come out of nowhere that a lot of customers are looking at because it is kinda back to basics on hypervisors. We don't need all the bells and whistles. This is this is pretty cheap, and we can get going a lot quicker, with with a lot less cost. So introducing support for all these. We we have a pretty standard minimum viable product that we release for any new hypervisor. It's pretty much basic backup and protection. Doesn't include the data for analytics, the sensitive data stuff. Those things usually get added in kind of in the next, significant revision of the code of of the product to introduce those types of things. Because there's always kinda nuances and and new things that have to go in there. It's it's not nothing to be able to support new hypervisor because they all have their own API. They all have their own approach to doing it. While most of these that you see on the screen may be based on a KVM as a hypervisor, for example, the way to interact with that platform isn't necessarily interacting with KVM. It's interacting as It's like you... We don't interface with ESXi. We interface with vCenter. And so that that management layer approach is is a big focus for us because that's how we can do the discovery aspect of things, how we can, coordinate in the way that these hypervisor vendors are intending it to be. There's a bunch of stuff under consideration here, and, of course, I have to point out the disclaimer that, you know, we're making no promises on any of these. We have no road map to talk about on any of these. These are other hypervisors that are out there in the space, that, you know, we've heard from customers. And that's the big, thing that comes into play here on this slide is we focus a lot on what our customers are looking to do, what they're asking us for. So the ones that you see in the recent release box tend to be those where we've got big customers looking to make big moves or a lot of customers looking to make small moves individually. And and understanding what our customers are doing, how they're using it helps us to drive when we're going to introduce additional types of restoration, for example, or adding in those, those data threat analytics type type capabilities are really driven by what our customers are looking for and asking for. So I I recommend to all of you, if you're if you're talking with the the Rubik sales team, let them know what you need today, what you need in the future. If you're current customers, be be open about where your plans are going and what you're considering and and making sure that our road maps are aligning with your own road maps because we will listen to that. And and there have been things on on on both the middle and the right boxes here that have changed because of the demand that we hear from our customers, from from people that want to move to Rubrik but need a certain thing. So with that, let's move into the demo, and I'll I'll show you kinda what, what we have capable here. So, looking at what what Rubrik can actually do here. So, I'm gonna start here on kind of our main, inventory screen. This is kind of the the the... All list that is implemented in this environment of all the types of backups that we can do. So you can see a wide range of things from from SaaS to, identity to databases to cloud to on premises, hypervisors, Windows, Linux. Like, we've got a lot. And and that's that's obviously the goal is to try to try to consolidate everything into one interface. So you only have one place to manage restoring your data. However, you might need to restore that. If I focus in on the vSphere, you'll see that we've we've got a ton of virtual machines in here. And, you know, what you'll see is a very obvious list of what is in these environments, where they're at, how they're being protected, what kind of SLA. So that declarative language, is is what we call an SLA, and places where you have things that aren't protected, And and being able to quickly understand what your exposure may be is is super easy through here and and being able to do filtering on this. As I scroll up and down, you can see, of course, these are all VMware machines. You can see they're all over the place, physically, potentially, and being able to understand what, you know, kinda where all your data is and what's going on here. I'm gonna focus on this this SMB virtual machine. Let's say this is one that we wanna we wanna migrate it over to OLVM, is is the other one that I'll I'll talk about here. And you can see right now it's got a bronze SLA, so it's a little bit different. It is connected directly to... So somebody went in and said, hey. I want to manage protection on this virtual machine, and I wanna use this bronze SLA. So it's directly attached to that. So there's a very specific need this virtual machine has, is how I would understand that. As opposed to the rest of these that are derived from a from a higher level source. So that ability to apply it to the vCenter level or the data center level or the cluster level and say, hey. I want I want everything that's in this entity to inherit this, this SLA and be protected that way. So being able to do a lot of default. We'll see that once we move over to OLVM as well. So, you know, this one's got a bronze SLA, which has got a very specific backup need that it has. If I wanna look at that bronze SLA and kinda see what's going on with it, I can see a wide range of different object types that this SLA has been applied to. And looking over here, I can see a lot of information about it, including the frequency and retention. But what's really important to highlight is the fact that this particular SLA can be applied to just about every type of object. And, again, this is part of the advantage of having a declarative SLA by saying, I want this entity, whatever this is applied to, to be protected at this frequency with this retention in these places. Not, I wanna back it up in this way, or I wanna back it up on the schedule. Let Rupert figure that out. Computers are better at figuring that stuff out these days. And we don't even need to bring in AI or machine learning into this to to truly understand, how how that's possible. So as we can see, we can apply this not only to our our vSphere VMs, but also to our o l... OLVM. So that'll be important once we kinda get through this migration process and wanna protect... Because we're not protecting a virtual machine or an object type in a in a way. That's not what defines how we wanna protect it. What defines how we wanna protect it is the application and data inside of it. So, let's make sure that this virtual machine, this this SMB virtual machine is clean before we migrate it. So we're gonna come in and we're gonna come up to our data threat analytics, what we call our room, and we can see a lot of cool stuff here. So you can see, you know, anomaly detection, threat met... Threat monitoring, threat hunting, all very quickly from here. We can see what's being protected. There's a lot of stuff that's not being protected, anomaly detection, that kind of thing. First off, I wanna make sure there's no anomalous behavior going on here. So I can very easily do a search for SH one SMB, and I can see no results past twenty four hours, past thirty days, no anomalies. So I know, okay, nothing nothing suspicious has been detected in this. That's good. We we don't wanna move anything that's anomalous. We probably wanna deal with it before we migrate it over into a new environment. So let's just... Let's be a little bit more direct and look at threats and make sure there's there's nothing weird going on there. Here you can see within the last twenty four hours, we found a bunch of stuff. We'll, again, search for s h one SMB. No threats found. Let's go back to thirty days. There's some stuff that happened in the last thirty days. So, two days ago on July 20, there was some stuff detected. We We can come in here, and we can see what's going on. You could see a lot of detail about what's going on there, including what threat source found it. So two of our threat sources detected this particular thing. The threat family's I CAR. I know because I I understand and because the description is here. This is a test file. This is something you throw out onto a system that is not malicious but is is in pretty much all the threat feeds to detect. So I know... Okay. Nothing I need to worry about here. Common JS, again, I'm seeing this about a threat family. I've got a description here. Okay. This is something to be concerned about. Now I get hashes. I get the ability to quickly copy those hashes. Screen here, I'm gonna put this into, my my text editor so that I've got this kinda documented out there for me. I can go out to virus total and get more information. I can see what snapshots it's been detected in. So at this point, it looks like it's probably not a concern anymore, but I get the ability to do a threat hunt. So I can go through and and look through the rest of those, find any other threats that may be existing in the environment. But ultimately, I'm gonna come here. I can choose between a turbo or an advanced. I'm not gonna go into the details of those. We got plenty of information that dives into that, but I'm gonna do a turbo because it is by far the fastest. I can I can reduce, the the search criteria that I wanna do? So if I wanna just search this SMBs in in the Palo Alto space, so I know I can hit that pretty quick. I can simply paste in the hash value that I copied before. Click next. Let's just call this free migration. I can define what snapshots I'm gonna go to. So July 5 was the last time that was seen. So let's say July 6 to today, you know, max snapshots per objects. I don't... You know, we can we can probably expand this a little bit more if we wanted to. Let's just put that to a 100 just to show there's nothing missing there, and it's off and it started. So now I can come over into my hunts area where you're gonna see a bunch of threat hunts that have been kicked off. This is gonna be a combination of the turbo and the advanced. By default, I think it's going to just show the past twenty four hours. So my pre migration is done already. It took nine seconds to do this hunt. The the the magic of this is it's searching through a database, not searching the individual backups. I don't have to touch the backups to do a turbo threat hunt. So I can see that, okay, this SMB one found some stuff. The latest match was July 9, so it it exists in there a little bit longer. But, yeah, I can see that information. I can see it's not in there anymore. If I wanted to, I could spend some time digging back a little bit further, looking to see what happened, how this moved through. In this particular environment, I know that this is a demo. We we throw IOCs in there, and we pull them back out again just to show that change happens. So in this situation, I've done the research, and I know, hey. This this isn't anything I need to worry about. Awesome. Let's move forward, and and let's go to the migration. Now Rubrik's position at this point is that OLVM knows how to convert a VMware v... VM into OLVM format, what they need, better than we ever will. And so we're not gonna we're not gonna get to the business of doing the migration. Let the native OLVM tools, let the native AHV tools, whatever platform you're going to, they all have conversion tools. Use them because they're going to be the most integrated. They're gonna be the ones that are most likely to convert it the right way without any questions or concerns to happen there. So we're gonna assume at this point that the the VM has been migrated. I'm gonna flip back over to our data protection room, and let's go into our inventory. Let's go to my pins. Let's go to OLVM. So now we're on the other side. This is simulated. So I'm just gonna say, hey. Let's let's say it says S h one OLVM w two. We changed the name as part of the migration. So stick with me on that one. At that point, now we've got this moved over. You can see it's kinda derived. It's picked up a default, inherited SLA. So we know it's getting some level of protection based on the name. I can tell it really quickly. It's probably every day, retained for seven days, retained for one month, retained for three months, are the different retention periods that we have going on there. I can see it's taken some snapshots already. That's cool. But, you know what, I need to make sure that it's being protected the way the application needs to be, which is the same as what we used on on the VMware side of things, which which is the bronze one. So So I'm gonna go in here manage protection. You can see I can filter based on object type. So here's all of the SLAs that we have in the environment, most of which don't have OLVM selected as as a target object, but our bronze one does. So we can very quickly find that. I can search. I can choose to not protect or to clear it altogether. So now it gives me a confirmation. I can see what's changed. So... Okay. This this application, this data, we wanna protect for longer or we wanna retain for longer. You know, we we get a lot of information about what's going on there, some alerts about what may be going on, a note if we want to identify why we made this change. But we know this is all within the window of of a migration, so we're gonna go ahead and assign that. So we get a little pop up that lets us know there's work going on. We see this little swirly telling us that it's it's gonna take a little bit of time because it's gotta coordinate it throughout the entire environment. And then if we wanted to, we could go and we could... We can go kick off a threat hunt on this virtual machine, make sure it's clean on the other side. Ultimately, we've got this thing moved over. And other than the migration work itself, really, all we had to do is was look for look for anomalies, look for threats, which you saw was super quick. I did this demo in about, I don't know, ten, fifteen minutes with a lot of talking. If I were to do this, it'd probably take me five minutes, on on either end of the migration. So super quick and easy to be able to, hit that level of protection and and ensure that your migration is gonna be clean. And on the other end, you're gonna get the proper protection of this virtual machine. So that's that's kind of the quick overview. We've got, if you go to, rubric.com/explore/demo, we've got a whole bunch of walk through demos that you can do yourself, that will explain every step of the process and what you're doing if you wanna go deeper into how we manage hypervisors or how we do data threat analytics. Those are all out there ready for you to do. But I wanna close on talking about a customer story. This is a this is a real story with an actual customer, what they were able to experience. So this is Lewis County PUD. They had a ransomware event that came came into their environment, encrypted a bunch of stuff, had the potential of, like, actually taking systems down, the potential of taking down their phone systems and not allowing them to, be able to, potentially answer 911 calls, which, of course, is a really bad thing to do. You don't want that to happen when you're a municipality having to serve your your your citizens. Fortunately, they discovered this. It was, like, a 03:00 on a Friday type situation before a long weekend. So typical time for a ransomware event to happen, trying to put as much pressure on you as as possible to allow it to stay hidden as long as possible. They were able to then very quickly identify what happened, when it happened, and start restoring, within a couple hours. You know, they they weren't putting in extra hours on a Friday to be able to take care of this. They were being asked for a 10,000,000 ransom, which, obviously, they didn't wanna pay, and they were able to to completely avoid that. They said, no. We we got our data back because we do the right thing. We protect our our information. And so they were able to to completely avoid that. And they were able to confirm very quickly that the systems that were impacted had no sensitive data. Again, using that ability to cross reference sensitive data, and the, the the systems that had anomalies and threats very quickly and easily. So that all said, I mentioned this before. It it remains to be repeated. Rubrik Explore is the place where you can go and experience this for yourself. This is not a live environment. They're they're, simulated environments, but allow you to be able to click through the process and see see what that looks like. It's a great resource. It's something me and my team work on, pretty pretty regularly to make sure we've got a lot of stuff out there. There's always stuff being added to it as well, so always take a look there. But, hopefully, this was was helpful in that regard. And, you know, reach out to us if you have any other questions. With that, I'm going to, do a final thank you and, wish you a a good rest of the day. Take care, everybody.