Name: Rubrik Workshop: Database Backup
Uploaded: 2025-10-28T19:01:44.956Z
Duration: 1 h 7 min 52 s
Description: Rubrik Workshop: Database Backup

Transcript for "Rubrik Workshop: Database Backup": Hello, folks. Welcome in. Thank you for joining us today. Got a bunch of you already here waiting. We appreciate you spending your time with us. We know how valuable your time is, and glad you're spending a little bit of it with us. You're joined today for this Rubrik workshop over database protection. We're gonna cover, SQL, cover Oracle. Know what else we'll cover. Michael will come up on stage in a few minutes. He'll explain every everything that we're going through, but it should be a good one talking about how, Rubrik can protect databases. Quick, couple housekeeping notes quickly here about Goldcast if you've never been on Goldcast before. There's a couple good things over there to your right. In the chat, I'll post some messages and some some good things to know as we're going. But we want all of your communication and questions to come through the q and a tab. Asking us questions and getting your engagement is really what's gonna be, the most valuable for you, so you can kinda get the most of your time with us and with the material. Please ask your questions early and often, and we'll be happy to answer them as we go. Additionally, there's also another tab over there called docs. Bunch of good links in there and resources for you, both, on the topic at hand as well as future stuff we're doing here at Rubrik. So, again, appreciate you joining us today. And without further ado, we'll bring Michael up on stage, and he'll start walking through the material. And, again, appreciate y'all. Thanks a lot. Hey, Michael. Hey, Chase. And thank you for the introduction. Let's see here. Okay. Yeah. Because I'm getting familiar with Goldcast deal. Make sure I got all the right buttons pressed. Alright. Well, thank you everyone for joining us for today's rubric workshop covering database protection. I might fall. Let's see. We'll go ahead and advance here. Give you a quick little agenda as well as my my headshot here. Bit of history on myself. I've been now at Rubrik for about eight and a half years, so I've been here for a while. Prior to that, I was a SQL Server DBA for about seventeen years. And really, like, the reason I came to Rubrik is I saw some some really cool things that they were doing and they said, hey, we need somebody who understands databases who can help us, not only demonstrate the product, you know, show all the value about it, but also help guide the evolution of the product. Right? So, you know, for SQL being in Rubrik for, I think at this point, a little longer than my ten years, so about nine years. Right? It's gone through, quite the journey. Now in addition to that, obviously, you know, we're not just talking about SQL Server today. It'll be also how Rubrik covers some of the other databases like Oracle, like MySQL, like Postgres, but we'll get into that. So we've gone to the kickoff here. We'll just go ahead now and get into the deck. Again, I'll reiterate what Shane said. Please feel free as we go, to ask questions. Happy to give you any sort of information I can. Always happy to pop the note on certain things. We'll we'll definitely do our best to make sure we're staying on top of the questions that you have. Alright. So if we talk about sort of database backups, database recovery, right, If we look back throughout time, this really goes back twenty, thirty years. Right? The the current landscape of data protection is, you know, we've got our production databases, and usually these are backed up by a variety of scripts or tools. Right? You know, whether you're using native protection or using another tool, you're deploying agents or scripts or what have you, and then scheduling them through some sort of job scheduler that runs those backups off to some level of, storage device or storage location. And then what we do from there is, you know, it's funny, like, we talk about backup and restore and obviously, the the key key element or the key use case for that is disaster recovery. But, you know, it turns out backups and restores get used for all sorts of other, scenarios such as, you know, reporting copies of your databases, basically, test copies, analysis audit, what have you. Right? There's a lot of rehydration to lower environments like dev and test that you might need to do. And so this is traditionally how we've been supporting it. Now the challenges here, right, is that as we get through this, there's a lot of sort of, you know, the cracks start to show particularly with the age of this. Right? First off, when we're talking about like, oh, we've got scripts to run backups. Right? Well, I've gotta deploy scripts out to all my servers. They've gotta make sure they're all consistent. I have to have a centralized server that is kept up and running to manage all this and if that server breaks then my maybe all my backup jobs break. You know, we have this sort of issue of the backup storage. Right? We're just gonna use a lot of it the way that most backups, software works today. There's a lot of cost and expense and I know everybody says, well, disks are cheap. Right? But they're not cheap enough that, like, if we just start throwing everything on it and using it inefficiently, right, that we can just keep buying more and more storage, and that has its own problems as well. And then, of course, you know, the restoration of these backups, there's there's a time element. Right? That there's, hey, I need to actually take time in this, you know, there's larger databases. It takes longer to restore to bring these up to get these up and running. Additionally, with this, right, the kind of the this little red skull icon I got at the top here is the advent of ransomware. This has really become something that, has become the the big threat nowadays. Like, you know, when we were doing disaster recovery plans fifteen, twenty years ago, you know, it was things like, oh, you know, the data center burned down or a tornado came through or somebody tripped over a power cord, like, you know, I've had that happen where an IT guy was in, like, oh, it's racking a server and I pulled the wrong plug on something. Right? But now with ransomware, it's just it's more insidious and it's more prevalent. Right? And the problem is is where our traditional solutions, you know, okay, yeah, we can bring the backups back, we can get them back in place. Well, the problem with ransomware is when it goes after those backups and the ransomware attackers, they know where the backups are. They will corrupt those and they corrupt our history and they basically cut us off at the knees from being able to restore any of that data. Then, of course, you layer on top of this, like, you know, it's fine when we're managing one database platform, but we've got to manage Oracle and SQL and DB two and RDS and Cassandra and all these different database platforms that all are backing up in a slightly different way. It becomes very challenging for us as administrators to stay on top of all this. So, you know, as we go through this, I've heard talked about all this right, like, the time and data are at risks, time to restore, data consistency, making sure that everything's gonna be able to be recovered. And unfortunately, with all those different components, you know, we're adding more and more complexity, the number of people who have to be involved in a restore, the number of things we have to be able to accumulate to do a restoration. All these different tasks, all these different people, and the more that you introduce this, the more time it takes to restore, the more challenges, the more things that could break. And then, of course, this leads us to start to say, well, what do we need if we need a solution? Like, if and this is what Rubrik was asking years ago when we first came to markets like, well, if we were to start from scratch, how would we build this and what would we be saying we needed? Right? And the big things are we need to make sure like, job one is keeping your databases secure and available. Right? Making sure the data is there and I can be used and can be accessed and can be recovered in the case of a disaster. Now layered on top of this, like with all the pieces, all the moving parts, all the complexity that keeps introducing itself into IT environments, we need something that's automated. Right? And then, you know, it would be good on addition to the automation is if we could consolidate that into a single consolidated view. Right? Something that we're managing in the same way regardless of the database platform. Now, of course, with the ransomware, we need to be able to identify and remediate those cyber attacks and then, of course, you know, the the most important thing at the end, right, is can we recover that data? And so this is where Rubrik, introduces our approach to this. And we're gonna get into obviously the detail of what's going on here. First off, when we talk about keeping things secure and available, right, Rubrik has this zero trust design. Now what does that mean? That means that when we're building the platform, the way that the build like, one of the foundational principles is that there's no trust across the different components. Right? Everything involves a challenge or response, a a security check to make sure is this the right thing doing the right task at the right time. Right? And this is the this is very different from how backups have been managed because traditionally, we've had sort of what's called a full trust architecture. The storage has to trust the backup software. The backup software has to trust the database server. All these different components have to basically say, yeah, I I'm accepting that you're allowed to do what you need to do. And unfortunately, by doing that design, that means if somebody penetrates your perimeter, if somebody gets into your environment like a ransomware payload, then they have access to everything. So the idea behind the Rubrik platform is to say, look. We're gonna be able to to set this all up, and, obviously, there's permissions and there's security and all their that stuff gets configured. But at the end of the day, there's a challenge and response element to everything that Rubrik does to say, are you the right thing, the right person, the right process, doing what you need to do, and is this the right time to do it? We have a global policy driven automation. We'll see this through the demo as well as a global catalog for management and control of your, backups. We'll talk a little bit about threat hunting, more about sensitive data discovery. You know, with threat hunting, this is more something that we do external to the database protection but is important. Right? We have built into the platform the ability to identify, and quarantine ransomware payloads. And, you know, as a quick side story, right, I know one of our existing customers, they use this to identify somebody who had deployed a ransomware payload to one of their Oracle database servers. Right? So it is valuable, and while we may not be looking inside the database specifically for a ransomware payload, the fact that it's there as part of your holistic approach with Rubrik gives you an extra added level of security. And then finally, we're gonna talk about recovery and what we call the live mount. The ability to rapidly restore a database, bring that data back quickly so you can access it. And with that, just a couple things quickly on what the platform is. Right? So I mean, talking about all those those capabilities and how Rubrik addresses it. The way we address it is by using what we call the Rubrik Security Cloud. And the Rubrik Security Cloud is sort of our overarching architecture as for managing this. Right? It is designed not just to manage, you know, enterprise or on premises workloads. It's also designed for cloud software as a service payloads. Right? Like, the reality is is we're living in a hybrid world. Whether you've got stuff in a data center, where you whether you've got stuff in infrastructure as a service end like AWS or Azure, or maybe you're running one of the platforms and service databases. Right? You need a a single solution to cover all those workloads. And so Rubrik is designed to live in that hybrid world, to sit across all these different workloads and provide you the same level of protection regardless of what workload you're doing. Now we talked about the global global policy automation. We're gonna get into detail when we get into the demo. But essentially, what we're doing is we have this, SLA domain framework, which what we do is define that to say, here's how often I want backups to be taken, how long I want them to be kept for, and then here are workload specific elements of that. Right? You set it up. You it's it's kinda fire and forget. Once you apply it to workload policies, Rubrik has a plug and play aspect where we auto detect new workloads, new databases, new servers, you know, find a way to, apply those in an automated fashion to allow you to easily protect and manage your environments. The recovery, you know, again, we wanna simplify it. We're gonna see this in the demo, but really it's all about, hey, you know, what can we use to do the use the tools to basically say pick a point in time and restore. Right? The advantage of databases is they allow for point in time recovery. But the challenge with that, right, is that there's usually a level of date DBA work where I have to assemble log files and run scripts and get everything in place. Well, you know, Rubrik here is, like, we're saying, like, let us do that work for you. So by using the Rubrik tool, we can automate this process. We basically still do the same level of work, but we're making it all simpler for you so all you have to do again is the end user say, here's where I wanna bring it back, here's where I wanna bring it back to, the time and the the place, and then Rubrik will go ahead and run that. For today, our current database protection, you know, we've had mentioned SQL Server obviously, but we've also got Oracle. Oracle's been in the platform now for, I wanna say, six years. We support SAP HANA. We support MongoDB, Postgres, you know, DB two, both RDS and Azure SQL. And we have recently introduced MySQL. So MySQL is the the latest addition for our database protection. We're also looking at other platforms. You know, I don't have anything currently, slated for, like, the next couple of months, but we are actively working on adding other database workloads as well. These are sort of the big hitters, but obviously, you know, there are plenty of databases out there and we wanna try and make sure we're providing the same level of protection across all of these. And with that, that's probably enough on the slides. Let's see. Looks like Greg has a question about being recorded. Chase, can you, I'll let you go ahead and and handle that. I believe this is being recorded. I'm not sure, how it will be shared though. Yeah. I can jump in there. So the beauty of Goldcast is the same link that you used to join the webinar webinar today will also be available to you on demand. So those recordings available, just click the same link you used to join, and you can watch this on demand. You can forward it along to somebody else if they'd like them to watch as well. Perfect. Thank you, Chase. Okay. So, good question. And let's go ahead and yeah. I got that. Okay. So, you know, I slides are all well and good and I know it sorta gives people a chance to sort of, like, digest what's going on. But I always like to get my hands dirty. Right? I always like to let's let's get into the product. Let's show you what it's doing. And we'll start here. This is the Rubrik Security Cloud here. So I've got the, the dashboard up. Now, you know, full full disclosure, I am here as a global administrator so I'm gonna be able to see everything and do everything. But one of the things that Rubrik supports is this idea of role based access control. So we can create within Rubrik organizations, roles, users, so that when people come in, they don't necessarily have keys to the kingdom. Right? They can't access everything. You can be you can give full control to the DBAs for the databases and then maybe the VM admins for the VMware stuff, the, you know, storage admins for files or what have you. You know, you can segment it however you need to for your environment, but this is important and I think, you know, sometimes this gets a little bit overlooked. Traditionally, with these third party backup tools, you know, it's it's kinda limited for a use case or for a persona. Right? And it becomes very difficult for DBAs and the challenge, of course, is DBAs, like, when it comes to backup and restore and something, you know, horrible happens, the CTO is not going into the storage guy's cubicle and yelling at him is why the database isn't running. He's coming into our cube. Right? And so for that reason, with Rubrik as a tool and the part of the reason we do this role based access control is you should be able to use this tool. You should get your access. You should be given the rights to manage all the databases. There's no reason that, you know, you as a user, if you're a DBA, can't go in and use Rubrik to restore or back up your databases. Again, control can be put in place so you don't have access to anything else. You don't have to worry about, okay, I don't wanna see the VMs of the files because that's not my purview, but you should be able to get in here and use this for for your database management. Alright. So getting into this now, again, this is just sort of a a initial entry point database dashboard view or sorry, global health view. Right? So we can see where our Rubrik deployments are globally. We can see how many things are protected, cluster health, all this stuff. Like, one of the things I sort of breezed through, I talked about Rubrik Security Cloud. There's actually sort of two components to the Rubrik Security Cloud. We have the management plane, but then underneath it is what we call the Rubrik data vault. And this is an appliance that goes into your data center, right, that actually, does the heavy lifting. So one of the things just to also make sure what is understood around Rubrik is Rubrik, we're not here in the business to sort of, you know, put guardrail or I should put a fence around your data. Like, we don't wanna own your data. It's your data. You own it. Right? So when we talk about how these backups and restores are managed, it's done through this Rubrik Data Vault appliance that lives in your data center, lives in your boundary. Right? So you control your data. You have full control over it, you know, while it's the Rubrik software and the Rubrik appliance doing the work, it's yours, you know, it's your data. So we're not gonna stand in the way of that. And it's also true if this is running in the cloud. Right? You might stand up a Rubrik virtual appliance in your cloud accounts. All your, cloud native workloads are gonna be within your accounts along with your Rubrik, implementation. Right? So all this stuff is controlled by you. We're not gonna stand in the way of that. Now when we start to get into saying, okay. Well, how do I actually manage my databases? Right? We'll start in the inventory screen. And I could drill down with those bread crumbs, but, coming into the just main page, right, you can very see very quickly, we have a lot of different workloads here. Right? So vSphere VMs, Linux file sets, we have SQL Server, Oracle, Azure, Azure SQL, three sixty five. Like, there's a bunch of different stuff in here. Now we're gonna just focus, today again on databases and primarily I'm gonna use SQL Server to show you what we're doing here. But just to be clear, the way that SQL Server is managed is more or less gonna be the same way that Oracle's managed, that d v two's managed, that any other database is managed. Quick thing here, I see that there's a question for from Hari regarding Postgres. Yes. So we do have white papers for all of our databases and those are accessible. I believe those might be accessible via the links that will be shared as part of this presentation. If not, we can do that as a follow-up. There's that. Okay. So, moving along. So when we get into the the initial screen here, the first thing you're gonna see is a listing of all my SQL hosts. Right? And so how do we get this SQL host in here? Well, the way the Rubrik connects to the SQL host is via what we call the Rubrik Backup Service. Right? The Rubrik Backup Service is a a lightweight agent that deploys onto your host that allows us to communicate, how how to communicate with the SQL server or the Oracle host or, again, any other databases that you have. And it's really all it's intended for is that communication channel. Rubrik itself doesn't actually track any authentication information directly to your databases. We just know that the Rubrik Backup Service is out there. The Rubrik Backup Service will locally be managed with whatever account you need it to be. The case of, like, a Windows Server, it's gonna run under a service account. I believe with, Linux host, we run as essentially as root, but you can manage that. But again, like the Rubrik software doesn't know, like, oh, I'm gonna log in as this user in the SQL Server. It just says, there's a Rubrik backup service. I'll call to that and then allow that to, do whatever action it needs to. Now once I have the Rubrik backup service installed and a couple other key things is the Rubrik backup service, once you install it, will auto manage itself so you don't ever have to upgrade the software. It just automatically upgrades itself as you go so you don't have to mess with that. And then it doesn't require any restart to reboots either on the initial installation or any of the automated upgrades that to it that happens over time. So it's it's lightweight, it's non invasive. And then once that's in place, then you can come in and register that host with, Rubrik. And once Rubrik is aware of it, then we go ahead and auto discover everything else about it. Right? In the case of SQL Server, we'll get all the databases, all the recovery models, you know, we'll check for any availability groups, we'll check for any failover clusters, we'll figure that all out. You don't actually have to do any special configuration. Oracle is very similar. We'll identify Data Guard, we'll event identify RAC, you know, any of these other high availability architectures. Really, once you've registered that host with Rubrik, we'll pick up everything else. So with that, you know, once we have that in place, we're ready to set up our backups. And so the backups, what we're gonna do here is go into our SLA domains. So I mentioned these earlier as the artifact for doing the automated protection of your databases. And the way that the SLA name SLA domain works is when we create the SLA domain, we'll skip this flash screen. The first thing we're gonna do is define what sort of workloads we're going to manage with this. And the reality or the the reason for this is is in general, Rubrik's gonna work the same way for the SLA domain. There's a lot of consistency the way that it operates against the different workloads, but there are always gonna be some sort of workload specific things. In the case of, like, SQL and Oracle, we need to track for log backups. Right? Whereas like a vSphere VM, it's not gonna have any log backups so we don't need to track that. So when we check this off, we're basically informing Rubrik that, hey, we're gonna need to do a couple workload specific settings around this to, you know, to complete the protection. Once we've selected the workloads here, we're gonna go ahead and, go through the rest of the configuration. Now retention lock is a security feature. Basically, what this does is if I turn this on, it locks the SLA domain once I create it. And the only way that SLA domain can be altered or changed after that is if you get certain authorizations that are managed on the back end. And that's basically a security feature to say, hey, if somebody were to compromise my environment, I don't want them changing my SLAs and basically aging out backups sooner than they should. Once we've got that in place, right, we can come in here and set up the backups. And the frequency and retention is the core screen for this, right? What I'm gonna do in this, and you'll notice we say take snapshots, so just from a rubric terminology standpoint, snapshots is basically what we use to refer to our backups. In general, our backups tend to be snapshot, related backups. Each database is gonna be implemented somewhat differently, but the idea is is so we can use those to do a incremental forever backup. So when I come in here and say I want the backups, I'm basically gonna do like one backup a day, keep that for thirty days, maybe roll that into a monthly backup that I keep for twelve months, and then a yearly backup that say I keep for seven years. Right? So in general, like, what I've done what I'm doing here is I'm giving Rubrik, like, this is how I want back this to be taken advantage, but I've also defined a life cycle. Right? So you're not having to create cleanup scripts or add additional processes. This is all wrapped into the SLA domain. Now what you might notice is missing here though is there's no scheduling on this at least initially on this part of the screen. So by default, what Rubrik is gonna do is when you tell us what you need, we're gonna look at all the objects protected by this policy and then the idea is is Rubrik will go ahead and do the scheduling on its own. Right? So that you don't have to do it. The I like, traditionally, we think about that, right, with all the backup jobs and all these servers and whatnot and like, okay, well, I have some backups running at ten, but I gotta have other ones running at 10:30 and I gotta juggle all this stuff. Right? That's a lot of work. So with the SLA domain, what we said is, like, let Rubrik figure this out for you. You just tell us what you need from a backup standpoint. However, we also recognize that, well, yeah, you know, it's great that Rubrik gonna do the scheduling, but you don't want Rubrik to suddenly decide that, you know, 10AM in the middle of your morning is when Rubrik gonna say, oh, yeah. This is a good time to run a backup. You wanna control that. So we do give you some level of scheduling, what we call a snapshot window, which is essentially a time box where we say, hey, maybe between 10PM and 4AM or what have you, whatever you wanna set it to, that's when I want my Rubrik backups to run. So there is a little bit of scheduling, but in general, you're basically just giving some guidelines to Rubrik to say, you go ahead and do the automated scheduling, just do it around this window and then everything should be, manageable. Once we have that in place, then there's a few other settings. Now most of the time, DBAs aren't gonna be worrying about these next few settings, because this is more more for the storage team. But I mentioned that data vault. Right? So if the data vault is your initial landing space for your backups, that's all well and good, but eventually you might wanna move those backups to longer term storage. Traditionally, that was tape, but now in the modern day, that might be sending them up to the cloud for Azure s three or Glacier Blob or some or sorry, Azure not AWS s three or AWS Glacier or Azure Blob. Sorry. I'm mixing my terms up there for a moment. Anyway, Rubrik builds that into the platform so that we can go ahead and automatically manage that for you. And archival is how we would do that. So if I select archival, I can now go on one of the next screens and basically define, hey, this is how long I wanna keep the backups on Rubrik and at what point I wanna send them to the archival target. Now replication is more for, hey, I've got my Rubrik I've got Rubrik data balls across the globe. Right? Maybe I have one in Chicago, maybe I have a different one in DC, And I wanna base make sure that my backups that are taken in Chicago also are in DC for me to use and leverage. So with replication, I can turn this on and basically say, alright, I've got this data vault in one location, I've got this data vault in another location. Let's copy the backups from one to the other and keep them there in the event of a disaster. So once I've done this, I do need to select a source cluster. So we'll just select London here. So once I have this in place, the archival settings are pretty straightforward. You'll notice that I have this, I can either put in, values here. So maybe I say zero day zero years and, you know, sixty days or I can adjust the slider. And then what Rubrik will do, you know, based on the following settings and I can use an archival location, and then I want my AWS archive here. Basically, it's gonna say, alright, I'm gonna keep sixty days worth of backups on the Rubrik Vault and then day 61 automatically send that up to the archive. You as the user don't have to mess with any of this. It's going to go ahead and, manage it for you, like it's all transparent. And then, of course, the recovery workflow is gonna be the same as well. By the way, I am seeing these questions pop up. Don't worry. I'm gonna pause here in just a moment to answer some of these. Let me just get through a few more screens here. So that's the archival. Then we have the replication. So again, this is a situation where I wanna I've got two data vaults in two locations, so I wanna keep my backups copied from one to the other. So I could say, hey, I wanna copy to my Madison. And then it's again adjusting the slider or maybe just typing in and saying, hey, I want the last thirty days worth of backups copied to this other location and then Rubrik will automatically copy those for you. The final piece here is those object specific settings, the log backups. Right? So for Oracle and for SQL Server, it's pretty straightforward. You can come in and say, I want my archive log backups copied off every fifteen minutes and I want them retained for a day or two days or however many days you want. You can with Oracle control how, like, the log our catalogs are managed on the Oracle host. So either I can immediately remove those as soon as Rubrik's copied them off or I can set to say, hey, keep them out there for like four hours or eight hours after Rubrik's copied them off and then they can be used for other tasks or just say, hey, I'm gonna I'll manage that on my own. Log backups for SQL Server is sort of similar where we'll take the log backups and you just tell us how frequently you want it, maybe every fifteen minutes and keep them for fourteen days. And then Rubrik will run a log backup, on that period. And the other database platforms have similar offerings, right, for the point in time recovery. But once I have that, then I can give it a name and I've got my SLA domain and I'm ready to apply protection. So with that, I'm gonna pause briefly here as I look at some of these questions here. Let's see. Let's see. Got a question here about, can you please show how to use Rubrik to schedule a nightly job? So Rubrik, oh, thank you, Chase. So Rubrik from a, a scheduling standpoint, right now we don't have a workload engine for doing that. We have an API that is accessible, but currently a lot of our customers right now, if they have to do some sort of external scheduling to Rubrik, they are gonna be doing that using our API and some scripting. We are working on trying to add that in from a scheduling standpoint, try and build some sort of workflow engine, but that is an ongoing effort. So like I said, today, it's gonna be leveraging our API. And the cool thing about the API is everything you do through the UI can be done using that API, interface. And so we have a lot of different customers using a lot of different scripts for, like I said, nightly refreshes, copies to other places, running cleanup stuff. All that stuff is doable. That's sort of the art of the possible. Right? Because we have the API and the ability to script and we have a lot of tools around that to help you with that as well as, you know, we had a professional service team that can happily sit down and help you, hammer out some some automation scripts. But right now, that would be the way to approach it. The other question here, can I schedule SQL Server backups to run at a specific time? Say like 10:00PM. So as of right now, the the only way to do that would be using the API. We are also looking at that because we've had that request from customers. In general and I know there's a lot of use cases around know, sometimes you'll wanna run a backup right before you run a an ETL load or something. And there are ways to manage the Rubrik backup execution so those two things don't collide. But in general, most of our customers are accepted, like, they they're they're happy to work with, like, letting Rubrik do that. They don't need the exact scheduling anymore because of mostly how Rubrik is doing the backups and managing that. Again, there is a use case for that. I'm not trying to dismiss it. For right now, there's, outside of the API and there is a way to do an on demand backup. I'll show you that button in a moment. But as far as just having, like, saying, okay, I want my backups to run every night at 10PM, that's really not, like, intended how Rubrik works. Right? Again, we're trying to make things easier on you. And to be blunt, like, you know, as when I was at DBA, I used to I was I was in that mindset. I was like, okay, well, this is what we're gonna set up the backups to run and there's reasons for that. But the more that I've sort of, like, disconnected and say, alright, like, let's look at this more from a holistic standpoint, the reality is is a lot of that stuff can still be managed without necessarily saying, oh, the backup has to run exactly at 10PM. Let's see. Couple of things here. We I don't know if we have links shared on the API because there's a couple questions on a doc around the API and some of the resources. I don't think we have those handy as part of the presentation but we do have those. So what I will try and do is as a follow-up, make sure we have those resources available to you. Got a question here real quick. This is the last question then I'll move on. Can Rubrik backup Postgres instances in Kubernetes? So as of right now, we don't have the ability to do back ups of containerized databases, actively developing that. I I mean, I was literally having a conversation with the PM on this yesterday. So it's it's definitely something that, there's a need for. It's a way to enhance the product, right now so the answer for right now is no. We only do the, the non containerized versions, but expect to see a containerized version or containerized support, very soon, probably the next, like, you know, half a year, six months or so. Okay. So with that, we'll go ahead and put a pause on the questions. Thank you for the questions and the engagement. Hopefully, that's helpful. Let's go ahead and move on with, the recovery piece. Right? So once we have the backup set up, right, and we got Rubrik taking these backups, then it's about, okay, how do we do the recovery? When we go into let's get to my databases, back to SQL Server. Oh, I'm sorry. I have I've I've I almost forgot this piece. Like, once we create the policy, how do we assign it? Right? My apologies. I was jumping ahead. So assign the SLA domain policy is pretty easy. Right? Again, the idea with these SLA domains and the way Rubrik approaches it is to minimize the administrative overhead. So the way that I can assign these policies is very simply, I can come into my SQL Servers or my Oracle Servers or my Postgres Servers, what have you, and select what I wanna protect. And once I have those selected, then I can say manage protection and then I can go ahead and assign an SLA domain, like, maybe I'll use the gold one here. Right? But then I can say, you know, select that on the next screen. Now for SQL Server, we have a few things where we can control whether these are copy only or database snapshots. Do we wanna enable log back? But fundamentally, I take that SLA domain and then I can apply it. It's gonna give me a confirmation screen. But when I go ahead and say apply, then it will go through and apply those SLA domains across these. Now I've already got some SLA domains assigned. You'll notice here we have some of these SQL Servers where the we have an r an SLA domain assigned to it and that's gonna tell you here, like, this is what we've applied. Basically, at in this case, the host level, but it could be the Oracle host level, it could be the Postgres host level, it can be in the data guard or the data group sorry. Data guard group level, the r man level or sorry. Not r man, rack. I'm I'm going a little too fast and confusing terms there. So RAC level availability groups, we support all that. Right? But by doing that, we can apply this protection broadly, basically, as a an overarching protection level for that. And the advantage there is one, you know, everything's gonna get protected in the same way. I'm gonna be able to apply that policy in a uniform manner across everything. But then secondly, what we're doing is creating a default, right? So that if any new databases get added to those hosts or availability groups or rack clusters, Rubrik will automatically identify it and then protect it with that default level of protection. Right? So once you set it up, you don't have to continually go back and reconfigure it. It's pretty much good to go. But we can also be more explicit. So if I drill down into my SQL Server host and then I've got my instance, in that instance, I've got all my databases listed here. And I could be now very explicit and say, well, I only wanna protect this database. For, example here, I have this model database which, you know, is a default system database in SQL Server. Maybe I don't wanna back that up. It's it's the template database for new databases. I don't really care about it. It's usually just like this is the generic default. I've got everything else managed in other places. So you don't have to back it up by the way that this is being done. Right? I've selected this. I've said manage protection. In this situation, I said don't protect. Now this is already selected so I'm not really changing anything. But I could come in here, say don't protect, and then Rubrik won't take backups. And you'll notice here we have the assignment now is direct. So we're no longer inheriting from the parent level, we're overriding at the specific database level. So you have different tools to mix and match your protection in a way that makes sense for your environment. So with that, that's more or less setting up the backups, getting everything up and running. Once that's in place, Rubrik will use the policy to do the backups. Then if we move on to the restore go ahead and pull up one of my example databases here. I mean, backups are all well and good but at the end of the day, it's like, okay, well, backups are great but unless I can restore that database, like, that's not doing me any good. Right? So restores are the the main the most important part of this right here. So when I come into restore database, I'm gonna come into this database specific view and we've got some overview here on the left, but on the right is a calendar view that drives the recovery. And anywhere on that calendar view you see a little green dot, that's the day we have a backup. Right? That's the day we've taken, essentially, from a SQL Server perspective, a full database backup. From an Oracle perspective, it's a level zero. Under the covers, we're doing these as incremental forever backups or, again, each of those is essentially a synthetic full that Rubrik can assemble and give you back as the complete database restore. But, you know, the easiest way to remember this is like, okay, that's the day I've got a backup I can recover from. Now, of course, with databases, I can do point in time recovery. So that thicker green line that runs under some of these days, those are days I have log backups in which I can do that point in time recovery. So maybe I come into the twenty seventh where I have a timeline view now, And on this timeline view, I can go ahead and select a point in time. And again, this is SQL Server but this is gonna be pretty much the same experience for Oracle or for Postgres or for DB two. But I can now select this, I can adjust the slider, or I can come in and say, well, I wanna restore to, you know, 6PM and thirty seven minutes and fifty three seconds. Whatever you want. Right? You can put put that time in there. And then essentially what Rubrik's gonna do is assemble all the backup pieces to get you back to that point in time. Then what I can do is select recover and then when I select recover, this is where I'll get some options. Now I'll be upfront with you. This is probably where you're gonna have the most divergence when it comes to the different database platforms because each one will give you different options around the recovery. But in general, what you're gonna see for each recovery option is what we call a restore, an export, and amount. I think in Oracle, this is a restore and a clone and amount, and I think there's a maybe another option or two. But in general, what these are from a Rubrik perspective is restore anytime you see it is an in place recovery. So this is sort of the easy button for disaster recovery. When I select this, I will say, okay. You know, we come into this. You'll notice for SQL Server, I can't change anything about this. I've got my same database name, my recovery time. The assumption is we're gonna drop the source and restore back over it. Right? So again, easy button for disaster recovery. It's really only intended for this use case to say, hey. Reset the database back to my, point in time. Because it's limited, right, it's it's easy if you need that specific thing. But for the most part, it's gonna be not a common use case because most of the time, you're gonna be doing some level of side by side restore. And so to do that, that's what Rubrik calls an export. So the export when I select it, I now will be able to select a host on which I wanna do this export to. The export or once I select the host, I can then select an instance and then I have the ability to change certain things here, right? So I can change the database name. I've got the simple method and the advanced method for export. This is specific to SQL Server. So the advanced and simple, this tells me where I can land my files. So my data files under simple would all go into one path, my log files all to another. I tend to use the advanced for SQL to go ahead and manipulate, you know, all where my specific files are. So I can be very explicit about individual files, individual file names, put them wherever I want. Oracle's a little different with this. We use a configuration file, but you can basically do the same thing. And it's primarily because Oracle has a lot more different options for the recovery. So things like, you know, your your memory spaces, your memory sizes, block sizes, database name, database IDs. You can control a lot of that. It's just done through a control file, but it essentially accomplishes the same things. But, yeah, I can come in here and change the name of the database to whatever I wanted to. And then if I want to, I could change the file names and file locations. Now by default, this action is non destructive. This isn't gonna overwrite anything, but I can if I overwrite something if I wanna check this off. And that's, you know, that's table stakes. Right? We'd look at that. That's everything we would expect to see from a backup and restore point of view. Right? But the last option is where things get interesting. And this is something we we currently support for for SQL Server and for Oracle. We're looking at adding this to some of the other database platforms. So, but for SQL and Oracle, we can do what's called a live mount. And if we think about, you know, database recovery, really any recovery, there's two challenges. One, I have to have somewhere to land the database files to. Right? I have to have some storage, on a server to write files out to. The second thing is I need to wait for the bits and bytes to write across the wire to send data down to the the database host. Well, with mount, what we decided we could do or what we we built out is instead of us recovering, we're gonna do a little bit of storage magic. I'm sorry. Instead of us recovering out to a database host, we're gonna actually use some storage magic and present the data directly off the Rubrik cluster. We still need a database server in your environment to attach this to, but once I come in here and select this, and we'll call this, workshop. This live mount, I'll select an instance in this case for SQL Server. I'll select a database name and then I say mount. Now this is a two terabyte database that I've been showing here in the demo. Right? So two terabyte database depending on your environment might take like twenty, thirty minutes, maybe forty five minutes to recover. Depends again on, you know, the size of the database, your environment, your infrastructure. But with this, with this live mount, what Rubrik can now do is bring this up fairly quickly. And so if we come to the events here and one thing I didn't really touch on, right, is nice thing about doing all this management through Rubrik is you get this consolidated event view. So while this is filtered on this particular database, like, Rubrik has an event tracking system, cataloging system that covers everything in your environment. So you don't have to worry about running scripts to collect metadata from all your hosts. It's already built into Rubrik. So if you need to do reporting or auditing, you know, check for your database, backup failures or successes, That's all built in and you don't have to do any additional work to create the catalog. So this is running. I'm gonna go ahead now and open up, my RDP session here, which usually I have open at this time, but I I didn't have a chance to get this open immediately. But let me pull this up. I'm gonna go ahead and show you though what the live mount looks like in management studio. And again, we can do this for Oracle as well. It's just kinda easier here with the the SQL Server environment. But let me refresh oh, not new query. What am I doing here? Let's just do this. So we will where is that? Refreshed. Don't know why I couldn't see it. Okay. So refresh. You'll notice here we have the live mount workshop database that I just created, this live mount. And I I expand this out, you'll see that I'll have all the database tables in here. Right? So I could come in here in a normal database. I can come and query it, do whatever I want to it. The difference is if I look at the properties and the files, for SQL Server, what we've done is we've created an SMB share on the Rubrik cluster and basically presented your database files back through it. So see you have an IP address which is a node in the Rubrik cluster and then a a random string and a path to the file name. So like I said, we're just creating this this copy of your database running where the storage lives on Rubrik, and now I can come in and query it for whatever I need. I can also modify this data. It won't affect the backup. Remember, the backup is this immutable state, so I can't alter or change the backup. But I can now come in and use this to query data out. I can modify data if I need to. One of the most useful, use cases for this, right, is object level recovery. And a lot of people tend to ask about how do you guys do object level recovery? Well, with this live mount, I can now bring up a copy of my database fairly quickly and it is another copy of the database. So if I need to query data out, I can query out, you know, 500 rows, I can query out a full table, a couple tables, and whatever tool I wanna use, whether it's straight query, BCP, SSIS, whatever I wanna use, I can copy that data out to a live database somewhere else. Right? Again, I can modify this data. I can use it as a reporting copy. There's a lot of different use cases for this and what's cool about this is it's transient. Right? It's not like, this is just storage taken up on the Rubrik cluster. It's a little bit of snapshot magic. So when we create this, we don't actually create like a full, in this case, two terabytes worth of the data. We're giving you pointers to the original state then you can modify it and then we'll track those pointers. But ultimately, it's just, you know, a copy of the database running on the Rubrik platform and then when you're done, you discard it. You don't have to worry about, oh, hey, we're tracking those changes, retaining it. It's all sort of it's discarded and you can create a new one. And that's another one of the advantages, right, is let's say you need to restore the database to a certain point but you're not sure which. Well, instead of like, oh, restore it. Oh, that was the wrong point. Tear the whole thing down and rebuild the whole thing again and take take all that time, you can bring live mount up after live mount up after live mount. You can bring up multiple live mounts at the same time, all different time points. You could bring up one, say, oh, this is the wrong time point, tear it down, bring up another one. You got a lot of flexibility there. So that more or less covers the recovery piece and you'll notice here the live mount, even though we were working on it, right, took me a minute and a half to bring back a two terabyte database as part of the live mount. Right? So that's that's the real value here is this can all be done really quickly. I'm gonna pause real quick. I don't think we have any, oh, here we go. We do have a new question here. Is the live mount database persistent on the Rubrik cluster? How long can it stay on? So the live mounts thank you, Chase. So the live mounts, they they are persistent on the cluster. They are really, they live there as long as you want them to. There's no, process that tears them down automatically. They just live out there for as long we've had people have live mounts out in the environment, you know, literally for weeks and months at a time. So there's no upper limit from a, like, a hard like a like, we don't enforce any upper limit on that. I will say there is sort of a soft limit on it because the longer it lives there because it is a snap shot, right, there is a a chance for instability. Usually, we recommend no longer than ten days, but again, we've had customers who had live mounts out there for, like, months and they were still, like, using it. It was fine. As far as, like, okay. Well, we but what if I wanna clean it up? This comes back to sort of the API and the utilities there. Like, we do this internally in our own lab where we have a script that runs through and and cleans up existing live mounts on a nightly and a weekly basis. So anyway, yeah, that should be that. Alright. So I know we've got just a few minutes left. There's one last thing I wanna touch on here. So this is all like the core functionality. Right? But one of the things that we've added recently that I think is really exciting is this idea of sensitive data discovery. So Rubrik a couple years ago, we purchased a company called Laminar. Laminar is, a company focused on what's called data posture security or data security posture management. I always get that screwed up. Right? So the idea is is that what they're gonna do is they're gonna analyze their environment and identify sensitive data, data at risk, exposure, and also by extension, do threat hunting and the like. And I mentioned earlier, like, the threat hunting capabilities, which we're not really covering today, but something we can do holistically in your environment to identify ransomware ransomware payloads that may infect your environment. But when it comes to databases, one of the more important things is understanding what kind of data we have within the database, particularly when it comes to sensitive data. Like databases, they manage the crown jewels. Right? They have all the important details or data within company, so things like, you know, people's social security numbers and credit card numbers and addresses and phone numbers. All this personally identifying information along with other stuff is within the database. And so what we wanna do is bring a tool that gives you some visibility into that, again, without necessarily granting the keys of the kingdom. Like, traditionally, that's something DBAs would manage and if somebody need to understand that, either the DBA has to run the query or build the report and there's some additional effort. So what we added under our data security posture, portion of the Rubrik platform is the ability to be sensitive data discovery on databases. If I scroll down, I don't think it's in oh, okay. The dashboard dashboard changes on me, from time to time. But let's go to object inventory and let's filter on object type SQL, MS SQL. So we have the ability to capture these databases, and what you're gonna see here is what we've we've got different security or some different, analyzers set up, and I'll show those analyzers here in a moment. But basically, we can see on our databases that are being scanned, of which I have a lot, I've got this one copy of the database that has some sensitivity hits on it. Right? So Rubrik has scanned the database, checked the data within it, all in an anonymous fashion too, by the way. Like, we're not retaining what the actual sensitive data is. We run a scan against the table. We figure out, oh, hey. This matches a certain pattern. We don't retain the data itself, but we retain what we track around it. So I can drill into this database here and start to see some more details. You know, I've got some, high level overview here, like what's the the different categories that we're flagging this sensitive data against, whether it's HIPAA, whether it's USPII, what have you. But more interestingly, if I click on this tables tab, this will actually show me the, like, specific detail about k. It's this table. So it's the person schema person table in AdventureWorks. I've got these 20,000 hits. These are the categories, and this is the data type. So it's a Social Security number, and I can even get down here to the table structure itself that will tell me this is the column or the field that that, that the name of it. So SSN, you know, does the Social Security number. You know, this is the the column name and then the the type of data that's flagged against that. Right? So this gives you a tool to track and see what sort of sensitive data is showing up in your database and how we monitor that over time and give you visibility. And this is to be honest, like, you know, this is one of the things I think makes life a lot easier for DBAs. Obviously, DBA can use this to see what sort of, sensitive data is there, be aware of it. But this also grants visibility to a degree to security folks, right, to security teams, to security executives, to, basically anybody who needs more of a high level view without actually needing direct query access into the database to identify this on their own. So you don't need special tools for this. You don't need any sort of, unique permissions. You just set the scan up with Rubrik and let Rubrik handle that. And the way that this is managed here is let's see here. It is the policies. So we have data classification here, and so we can create these, high level classifiers that basically create a rule set for how we wanna identify the data. And you'll see here I have business, I have, CCPA, I have a database sensitive data, set up here as a custom one, I have HIPAA. You have a variety of categories. And the categories are basically a collection of what we call data types. And so the data types are gonna be analyzers where I create, you know, say, hey, I wanna scan against this. So whether it's, you know, Australian, Australian pensioner concession card or blood type or physician name, you can use some of the canned ones. We have a bunch of canned ones or you can create your own. And if I create my own, I'll give it a name. I select a category I want to assign it to and then a sensitivity level. So maybe this is a medium sensitivity. We'll just call this dummy for a second. And then I can say, okay. Well, I have two ways to look this up. I can either use a regex, so I can create a regex lookup for this, or I can create a dictionary lookup. Maybe I have a a a CSV or some other data file that I can use and have that, as my lookup for this. So you have the ability to create or use the canned sensitive stuff. Yeah. So that's more or less that. There's a quick question here. Ryan is asking, does that work if TDE is enabled? Yes, it does. So TDE is an at rest encryption. Right? So you set that up. That's gonna encrypt the files. In order for us to do the sensitive data discovery, we've got a lightweight query that actually queries the database and you can set that permission up. It's essentially gonna use your, Rubrik backup service to connect in and query the database. So anytime that I can actually you know, once I connect into the query layer of any database engine, I've essentially authenticated to TDE already. So TDE is something that Rubrik works in conscience or, in concert with. Right? You can do TDE. We can back up TDE databases. We can restore TDE databases. That's all manageable. But as far as the sensitive data discovery, right, we're already sort of past that, encryption layer. We're gonna be leveraging your TDEE to connect to it anyway. So, while it's there and it's enforced, it will still work and you don't have to worry about, like, we gotta do special rules around the TV. Okay. So I think that covers it. We are at the top of the hour. I appreciate everybody's time. You know, feel free to ask. I think we've got all the questions answered here. Though I do owe everybody a follow-up. I know that we talked about the API stuff, but, you know, feel free to throw some other questions in there. Otherwise, within the docs link here, we should have, your links to the labs. Yeah. So you'll see in there, there are two links to the to the doc to the doc section. One for the Oracle guided lab, one for the SQL guided lab. So you'll have access to those links. Those will give you the lab walk throughs where you can go with that and kinda walk through the Rubrik interface, see all the different, components and, you know, test out or see how different functionality or workflow works. But beyond that, I'm just gonna hang I'll I'll go ahead and pause for a moment, take a breath, and then, of course, if you have any questions, I'll hang out for a bit. Otherwise, again, appreciate the time. Chase, while we're doing that, is there anything you have to, to kinda close out with everybody? Yeah. Appreciate that. One thing I did notice as I clicked on the SQL link, it is incorrect. So I'm just gonna copy that into the chat here for y'all, and then I'll update it in the docs tab as well. Just pasting it into the chat right now. Okay. So in the chat, we have both the Oracle and the SQL guided lab if you're having trouble finding the docs tab, but they'll they'll be there as well. Now we appreciate y'all joining us today. I just I launched a survey. We'd appreciate your feedback too to know how we can improve these, events going forward. Thanks for spending the time with us. That's really all I have. We have we have some upcoming events too. You can definitely check out that link in the docs tab of future webinars, and, happy to have you with us. And, you know, we'll we'll hang out online here, for a few minutes, see if there's any other questions, any other issues getting into the lab. Just drop them in the q and a. We're happy to help out. Thank you very much. Thank you. Okay, everyone. I'm just coming back in as a final check-in. Appreciate again all the time. We're gonna go ahead and close down the webinar now, but, feel free to reach out if you have any other questions or any other issues, with the lab or anything. And, other than that, have a great rest of your week.