Name: Rubrik Workshop: Database Resilience, Decoded
Uploaded: 2026-10-28T18:35:57.317Z
Duration: 1 h 4 min 12 s
Description: Rubrik Workshop: Database Resilience, Decoded

Transcript for "Rubrik Workshop: Database Resilience, Decoded": Okay. Welcome, everybody. Thank you so much for joining. We're gonna get started here in just a few minutes, but we're happy to have you here. Yeah. It looks like the chat's already popping off, if I will or if you will, with where everybody is from. I love to see it. Keep that coming. We have a wide range. of people. Sorry. Go And I was saying, like, we have a wide variety of cities, ahead. people from different cities, so. it's very good. Love it. Awesome. Okay. Well, just for the sake of time, folks, we can probably go ahead and kick off at least with the housekeeping items, and then we're gonna dive right into the content. But, again, welcome. If you're just joining us now, if you're here to talk all things databases, you're in the right place. And if you're not, stick around. You will definitely learn something. But, yeah, I really appreciate the time. So just a couple housekeeping items if this is your first session with us. People are already discovering the chat. That's the first. On the right hand of your screen, you'll see a chat, docs, and q and a. Feel free to put your feedback, comments, as we go through the session in the chat. Please put your questions in the q and a, and I can help monitor that as well. But that way, we can just make sure they're either answered live here or we can follow-up. It's a lot easier for us to monitor in the q and a than it is the chat. So that's one item. And then for the docs, these are just additional resources that go along with today's content. So take a look at those, when you get the chance. The session today, we have you for an hour. We might end a little bit before that depending on, the questions, but excited for, yeah, what we have lined up. The other thing I'll just kinda get out of the way here is we have a survey at the end of the session, and that's going to ask a couple of questions on just, you know, did you learn, what you came to learn today? We really want that feedback, and that's the other way we're gonna be able to... If you attended the full session and you meet all of our terms, and conditions, we can send you the the thank you gift card for attending. So just stay tuned for that. But with that being said, Alpika, I'm gonna kick it off to you, and we can get started. Thank you so much, Hannah. And once again, welcome to this edition of Rubik workshop. We are focusing on database resilience, so more on the recovery aspect. I'm not going to go too much in detail about a particular, database, but it's overall about your database resilience. And, good morning, good afternoon, depending on where you're joining us from. Hope you have a good session and stick around, like Hannah said. It's a great session and lot of information, and we have a gift card coming at the end as well. Now, quick introduction. So my name is Alpika Singh, and I'm a senior technical marketing manager here at Rubik. Been with Rubik for over five years now, and I pretty much deal with, all the customer facing technical content. So slides, demos, YouTube, blogs, webinars like these, etcetera for our databases, our enterprise suite essentially. So databases, unstructured data, SAS, and AI as well. So I do have experience in other product areas as well. If you have questions regarding databases or anything else, feel free to put it in. And, would love to see as many questions as possible. I will try to wrap up the session quickly so I can get to q and a quicker. But please don't wait till the end. If you have questions, add it in, and I can always take a break from the presentation and the demo and answer the questions first. Okay. With that, what are we gonna do today? Now before we think about what we're gonna do, I I do want you to picture a situation when it's, like, 2AM and your phone is buzzing, your laptop, is getting Slack messages, intern, your phone is getting all the Slack Slack messages. You're getting a call. That a production database that actually handles all your customer information, your order, and if you're an ecommerce company, the product... If the production data goes down, a database goes down, not... No orders can be executed. You know, think about that scenario. I'm sure that has happened more than once to you. But just keep in mind, when we go through the presentation. Right? So what are we gonna cover? We are going to break down that 2AM call and see how you can get from that panic moment, and thinking about, like, oh, do I have a backup to recover from, or how much data am I going to lose? How long will it take, to how you can take Rubik, how you can take, you... How you can take advantage from Rubrik and get back your database up and running quickly, and how legacy systems fail to provide you with the same level of solution. We'll dive more into the flexible recovery scenario like granular recovery, and we'll touch base into, Rubrik live mount. Then we'll get into high availability that is coming across most of our databases now. And, the goal is to get feature parity at the end of it. So the other data, like, somewhat one or two databases will be fast follow-up. Then we'll get into some of the data thread analytics and data discovery and classification features that are available. And then I'll leave you with a live demo, of the overall, Rubik's Security Cloud platform and, what the UI and everything looks like. And Hannah is going to provide you with all the, click through demos so you can experience it firsthand as well. We have a lot more on Rubik explore, so you can go there and find, other workloads as well. With that, let's just get started. Now think about that, you know, as in every year, the data is only growing. Nothing is, becoming less. So the... Over the period of next three years, the projection is that over 200% of your current data is going to grow. Right? Or your data will grow, by 200% in the next three years. Now, this is across all of your enterprise, not just databases. Now think about the fact that when I talked about the 2AM calls and your... If your data is only going to grow 200%, the frequency of that 2AM call, is only going to go up, from now on. Right? And if you look at the cost, that is, that every company has to face for any downtime is essentially around 9,000 for every minute. So by the time somebody actually gave you a call and even described the scenario and, asked you how long it will take for your database to be up and running, you would have lost lots of money. And then one of the most common reason why the downtime happens other than, you know, accidental errors and your, system went down. The system where you are hosting, the databases is ransomware. Like, over 90% of the organizations have faced ransomware attacks. And this percentage is only going up with AI in the mix. A lot of times, AI is actually accidentally deleting your production databases as well. We've seen lot of cases, of that as well. So keep that in mind, like, how things are evolving, in the in the enterprise world and how the two AM calls is only going up right from before. So now when we speak to our existing customers, when we talk to people at trade shows or even if we talk to you, like, for example, this webinar, the feedback we get is that customers and prospects, they are not looking for every feature, to be available in every database, any database recovery or backup solution. Right? They are looking for four things. One is predictability, which means is that if they have to answer this call, like, how long before I can get the database running, they they should be able to answer that question fairly quickly. And it's not based on guesstimates, but based on the fact that, you know, there are capabilities available, with the solution that you are able to get your solution, database back up and running and without losing much data. Next is the data integrity part. Now think about the fact that after every backup complete, you're not sure if the... Any data corruption happens or if your database was encrypted or, you know, what if your VM was encrypted itself and in turn your data got encrypted? Like, you don't know if your data is safe to recover from. So that's another aspect that our prospects are very worried about. Next is the speed. How quickly can they recover their data? And ours is... Now if you do the math and try to even multiply nine k with sixty minutes, it's a lot of money. Right? So you've lost a lot of money which nobody wants to. So you want your database back up and running fairly quickly. And again, you want to simplify all of, your data protection. Like, you do not want to sit and manage a lot of complex scripts, which essentially differs if you move from one database to the other because your interface, to the database is different. Like, it can be r, r man to VSS to something else. Right? So it could be different clients you need to interface with for your backup scripts to run, which you don't want to keep managing and updating on a daily or hourly basis. And if... Think about the fact that if you add a new database, you have to make sure that you... Your script is actually taking that backup, as well. So there's a lot of complexity that, is currently out there. So they just want to reverse. Like, that's what customers are looking for. And, if you're looking at recovery solution, it's literally just the opposite. So with the traditional tools, you're forced into guessing if your backup is actually clean. If if there is, making... Like, there is no way to make sure that data corruption didn't happen. It's not encrypted, things like that. And then a lot of times when you are using, manual scripts for backup and recovery or manual tools or traditional tools, the recovery becomes the problem, where you recover first from full backup, then you add your incrementals or your deltas, and then you add your transaction logs. Just think about the fact how long it will take, and that will also be error prone. Like, what if you missed adding one differential and you've lost a lot of data. Right? And it can cause a lot of data corruption as well. So it's very important that you run away from all the manual, process. If you think about actually moving the data, to even check if the snapshot is good enough, you might actually have to copy the data back into your environment before you can even verify. Like, now you're wasting a lot of time as well as resources, and it may or may not work. So, you know, everything is again, like, slow. It's a guesswork, and you're just stuck in that. And again, like, when you're managing, multiple databases, like, no enterprise will just run on a single database. Every database has their own, pros and cons. So for this... Depending on, the application you're going after, you might be using one, or five, like, mix of SQL and the no sequels of the world. Right? So, it's... If you start using multiple tools for each one of them, now you are looking at at a management, issue because it's very hard, to... And it's... Essentially, it's in silos. So, getting a clear picture of what actually is getting backed up and what the RTO and what the recovery times look like can be very difficult as well. Now this is where Rubrik can actually help you. First off, we offer automated discovery. Once you add your host to Rubrik Security Cloud, that's our SaaS platform and I'll show you in a bit. Rubrik will automatically discover all the databases Depending on the database. If there is DB2, we'll just do the instance mapping. If there is MongoDB, we'll go all the way up to tables. Depending on the different databases, we will give you automated discovery, at at a very granular level as well. And you don't have to do it. It's it's, duplicate test that automatically. Now we have a policy driven SLA engine. That means that it's a policy... It's a SLA policy engine that works the same across cloud, your enterprise apps, your, SaaS as well, if you're protecting with Rubrik. So you can, you know, declare, like, you you want to have fifteen minute RPO. So you can set how often you want to do the backups. Like, it can be full backup and, all the transaction log backups that happens in the background. That can be very granular, so you don't have to worry about what your RTO looks like. It gives you that flexibility as well. Next part is the instant access. We do have a lot of recovery options. So if you want to export, if you want to do an in place recovery, you know, we offer that. But the instant as... Access is essentially live mount where we, mount the storage or mount the database. It runs on Rubrik and you can get your database back up and running quickly. So you can, you know, run queries or at least, verify the health of the database as well. And the last part would be the unified management and visibility. So, again, if you have five different databases, you have virtual machines, hypervisors, you have SaaS, cloud, whatever. You can manage everything from the same UI, so that, you know, your recovery and management becomes simplified. So let's dive in deeper on each of the functionalities. So when we talk about l s... SLA policies, what you see on screen is, like, you can actually define how often you want to backup. What you don't see in this screen is the frequency of transaction logs or, any log backups. I will show that in the demo, but you do have the capability to take differential backups, incremental backups, or, you know, free... You can back up the transactions log pretty frequently. So your audio is pretty quick and to ensure that not much of the data is lost. Now Rubrik manages the entire life cycle of the data. Once the data backup happens, when it gets, deleted, everything is managed by Rubrik based on the SLA. So it manages your data from cradle to grave. It will automatically purge the data if, the the snapshot is set to expire after, say, seven years. Right? So you don't have to do anything. It'll free up the storage for your usage as well. Again, like, I'm not gonna get into the auto discovery protection. But, yeah, like, it's a centralized platform and the same SLA policy engine works for all the workloads. The next is the recovery timeline. Now, think about a scenario where you have full backup, which is identified as f. And then you see an I, which is gray box. Basically, that's an incremental backup. Incremental backups are essentially backups that, happens between any backups. So if there's a differential set to, happen later, basically, it will back up anything that has not been backed up before, after... Sorry. After, the the last successful backup. Similarly, differential will backup every data that has not been backed up since the full backup. So, a differential also will include, incremental backups. Now depending on the database type, these vary little differently. So, you know, take it with a grain of salt, but we do have the option for all three of them along with log backups that that can happen every fifteen minutes or five minutes if you want. Right? Now think of a scenario, when it's basically LA. That's where either a failure happens or your database gets corrupted. You have the option to actually recover from... Do a point in time recovery from either a full backup and... Or your first incremental, second incremental, or, you can actually take the differential backup and Rubrik will automatically apply all the log backups that has happened, in between. Or you can actually recover from the last log backup and, available. And Rubrik will first apply the full... All the incrementals, all the differentials, making sure that, you know, you have the latest and latest copy of your data, as well as apply all the log backups where... Whatever is needed. So, you know, the granular recovery, ensures that you don't lose too much data and, and that way is you have the option to do recovery from wherever you want. Like, if you have, say, a cyber event and you realize that the clean copy to recover from is the first incremental, you can actually, recover from that and carefully apply the, log backups as well. So there are options, and Rubik can automate that process for you as well. Now, that is talking about granular recovery and then, like, the options. Right? Like, what we want to highlight is the, live mount capability. Now live mount, is essentially... You just go click recover and you get an option, click live mount, and that's it. You don't have to do anything after that. You don't... You do have to select the snapshot you want to recover from, but we'll get to that in a bit. But what happens after that is that it, Rubik automatically mounts all the data, on the storage provided. Basically, it's the Rubik secure vault, or if you're saving it, in Cloud wherever you want to, but it's on Rubik's infrastructure. Rubik is, Rubrik is managing all the compute and the storage resources there. Now once the database is mounted, your database is back in action. So you can actually, start doing any queries. You can read from the database, and you can use it for doing any, one record recovery or if you just want to recover, say, five records rather than restoring the entire database, you know, you can do that as well. You can actually query to make sure that there is no data corruption, and make sure that your data is correct before the recovery happens in the background. So, you know, think about the fact that, when you're using legacy tools to even do any sort of, single record recovery, you actually have to copy all all the entire... It could be terabytes of data first to your compute, to your storage, and then even start the process. But Rubrik basically, does all that for you and makes your data available to you instantly. That way, as you can get your databases back up and running quickly, and, start doing... Start using it, basically. Just some time line comparisons. When we look at, traditional way to copy and restores, we are talking about hours, like, not one hour. We are talking about four to eight hours. Think about, the $9,000. I think approximately 9,000 times eight times 60, that's the amount of money you could potentially lose if you're using the old way. Versus with Rubrik, you can get the, database back up and running in under two minutes. And then, you can start the copy in the background, to make sure that, you know, everything is up and running from your, infrastructure as well. Okay. So one of the other capabilities that we, that I want to talk about is high availability. Now what is high availability? No one in, like, in enterprise world will run, just a single instance of Oracle or say, MySQL, database. Right? If if you're using it, of course, as a primary, and a secondary. And when that happens, a lot of times, the d... DBAs are actually struggling. Why? Because once your primary fails and your... You have backups running through that and your, primary fails and your secondary now becomes the primary, the backup does not continue automatically. You might have to manually start the process. And once you start the backup from your new primary, it actually can, you know, it will be a new backup chain. And once you want to revert back to your, previous primary, you have to somehow recover or make sure that your backup is available for the duration, you know, when this whole high availability switch over happened. So it becomes a very manual and error prone situation, trying to figure out, what is the latest backup. And just imagine if something goes down right that minute. Right? During that high availability, and you need to recover. Right? So it becomes a very painful process to figure out, which is the latest and greatest snapshot I should recover from. So Rubrik has made that process very simple. There's only one SLA, one backup chain across the pair or high availability pair. You define that in Rubik's Security Cloud, and you're good to go. The moment a failover or a failback happens, Rubik detects that automatically, and it switches from taking backups to the new primary always. It will not initiate a new backup, from... If if there's a failover or a failback ever. Again, like, all this is auto detected. You don't have to do anything. Just assume that if your primary is offline and your new primary becomes online, Rubrik will go ahead and, detect everything and start the backups from there. And, you can recover from either the backup or primary backup. You can either backup from the primary or the standby depending on who's online as well. Now let's see how that actually works in in in Clari. So, you do have to install a small agent. It's called Rubik Security Cloud. It's it's part of the onboarding process, and you have to install onboard the host. And once you onboard to Rubik's Security Cloud, the master host or the primary host, is where the backups will start from. And the standby host will be in an error state as a standby or a replica mode. When I say error state, you won't see, like, like a red thing that backup is not happening. It will just say that, no backup is happening because it's in a standby mode. So so backup starts from primary and your, master fails and your standby now becomes the master. What happens is that the snapshots will continue or the backups will continue from the new master. And if there's a failback, your new master comes, your old master comes back online and, the new master becomes standby. Rubrik will, make note of the change and the snapshots will then start from, the old master as well. So all this is very automated. The failover just happens automatically. With that, now there are a couple of situations that happens during a a disaster or a cyber attack situation. Right, like, what was affected? How do we prioritize, your account? And, you know, if... Do we need to report to any authorities about any data leak that has happened? Things like that. Like, that's one of the biggest, questions that, you know, your admins have to face on a day to day basis. And Rubrik is there to help with that as well. Now we have, two engines. One is the threat detection engine and one is the data discovery engine. Now when we talk about... Let's talk about the threat detection engine first. Now what happens in threat detection is that Rubrik compares your current backup with your previous backup. This is more at your hypervisor or your virtual machine layer, where you actually run your databases. So Rubrik can compare the current backups with your previous backups and figure out if there is any signs of encryption, if there are massive deletion, events that has happened. It even uses, Jira rules or, hash files to actually scan your, backups to look for indicators of compromise. I'm not going to get into the detail of it because that's a big topic in itself, but just know that Rubik has the capability to detect threat, by using your backups. And now this is actually very beneficial because this way is, even if you have threat actors present in your environment, they won't know, that we are doing all of the scanning, because we are using the backups and not touching, the live environment at all. You do, get a immutable backup with, with Rubik. So any database backups, it's basically... Once it's written to Rubik, it's read only or append only, model. So, if a record changes, that does not mean we go and change the record. That means it's saved as a new record. So those are some of the capabilities that we offer in the platform itself to make sure that, even if, the threat actors have access to your backup, they can't just go and encrypt or they can't just go and delete all your backups. No one has the capability... No one has the access, to do that. Even Rubrik cannot do it for that matter. So, we make sure that your data is immutable. We scan for all the threats in your environment, to make sure that if there are any, we make you aware of that. K? Now we get into data discovery and classification. So, it's very important to know where your sensitive data lives. Why? Because in case, there is a cyber attack, you do have to report on what sensitive data exposure you're looking at. Right? But before that, if you're a hospital or if you're a financial institution, you do have to make sure that your data is tightly locked down and no, user... No unauthorized user has access to update, delete the data. Right? Like, because that's when they start exfiltrating your data or deleting the data. So it's very important to know where that is. Rubrik has the capability. Basically, what you can do is you can, assign some sort of... Not some, but, it can be, custom policies or it could be in built policies to look for sensitive data. The policies are designed to look for your Social Security numbers, patient records, address, passport number, medical information, you know, and they differ by geography, like the the format of that data. So we have analyzers that are actually very geospecific, to look for that, sensitive data. So once you apply this to your database, what we do is, during the backup time, we actually query the production database and essentially analyze, some percentage of the, production database. Because, you know, when you look at the databases, the type of the data is same. So we don't need to scan your entire database, but say 20 records just to see what kind of data is in the database and who has access to it. So we collect that information and we tell you, like, you know, there is sensitive information in x, y, and z database. Currently, there are no violations if, you know, if your database is locked down, but it's good to have that information. But if, say, x, y, and z, database now suddenly has, per... Per... Like, delete permissions for a new users, we will flag that. So we are also tracking how your permissions are changing for users over a period of time. And that that is very important because, you know, if in case there's an intruder, with a fake identity, they can actually start deleting your data as well. So tracking that change as well is important. So Rubrik can do that, for you, you know, after... During the backup period. Now, I do want to show you the demo. But before that, I'm just going to go and check if there are any questions. So the question is in case primary, secondary... In case of a primary, standby setup, if standby database is activated for business needs and back and forth, both DBs are required, how will Rubrik, handle the situation? You know, this is a very support questions. I don't have the right answer for this, but, I'm sure we can handle this. Our support will be able to help you, with this scenario as well. And, you know, in fact, if you already have access to your SCs, you know, you can raise this question to them, and they can get you the answer from our engineering team as well. Okay. Good question. So in a situation, usually, primary standby belong to different data center. In this case, do we need to add both nodes, primary, standby under one Rubik cluster, or can we add DB nodes to the respective Rubik cluster based on their location? You can add them to, separate clusters as well. Actually, I take that back. So the snapshot chain is, in in in... Snapshot is basically in a single chain. You don't have to add them to clusters. I'll show you how that happens actually. Rubrik will automatically detect, where your primary or secondary is, and it will save the data in a Rubrik cluster. You don't need to deploy Rubrik clusters in every data center if you don't need to. Clusters in every data center if you don't need to. Okay. Armand... Okay. Oracle DB, database, can we just restore a schema with Rubik? Yes. Do... You do have the option to do that? Oh, great question. Is there a way to see what type of backup was taken in a report? Our auditors want evidence of when full backups were taken, but I haven't seen where that information is exposed in a report or event logs. You do, you you can get to reports, and it can tell you when was the first backup, like, full back up taken, when was the full, when was the last time the full backup was taken, and what are the backups after that? The reporting, it does have the capability. And another thing what you can use is actually Rubrik AI. It's it's like a claw like interface. If you have access to Rubik's security cloud, you can just ask the question and it should be able to create a report for you and in fact, email the report out, on a regular cadence as well. So, you don't have to hunt for it. You just have to Rubrik... Ask Rubrik AI and it should be able to help you. Oh, yeah. How does Rubrik knows if the data corruption occurs during a backup? So we do do a data integrity testing, before we call the backup process to be completed. So it's after every backup. So, yeah, there is a process. You know, during the process, there is a step. During the backup, there is a step, to make sure that we check for data corruption and, all of that. Can you live mount to another server and what are the requirements for the server? No. We... You cannot live mount to another server. You can use the export option if you want. That can serve as, another way to, get your data, but, no, we don't have the capability to do a live mount somewhere else. Good question. So I thought Rubik does one full backup and incremental forever backups. How do we do differential backups? I don't see an option, on the SLA domain creation page. Now, like I mentioned, we have different type of backups for different databases. So you will see more of different... Differential backups if you're using HANA or if you're backing up HANA or d v two. Those are the capabilities over there. If you're doing Oracle or SQL, you won't see that. You will just see incremental backups and full backup and, again, like log backups as well. I was just trying to describe all the different types of backups that are available, but it differs slightly on per database level as well. Is the live mount utilizing NFS? Yes. I think you need a multi agent RBS and you'll need to create an SLA domain with replication, after creating a replication pair. I think that's, for replication, we, don't need a multi agent. It's just a single agent from, you know, from what I understand. And there's a single SLA also that happens for replication as well. How do you make a registered Rubrik agent read, restore from a replicated Rubik cluster, and still continue to back up from original cluster? When you're doing the restore, there is no option to actually, choose your target. It will basically... I believe whatever is more available as in in terms of compute and resources, it will automatically select where you are recovering from, and then it will continue to back up to the original cluster from what I understand. Okay. So with that, in the interest of time, I just want to quickly do a quick demo, and show you the interface and, what you can do with it. So so this is Rubik's Security Cloud. Once you become our customer, you will get access to this. So this is a centralized management platform to back up your identity, your enterprise, your SaaS, as well as your cloud, objects. Like, if you... I do want to show you the inventory from the data center. We have wide variety of, hypervisors as well as different databases as well. So HANA, d b two, Oracle, SQLs, and, MongoDB, etcetera. So, we have even informix, protection as well. So once you install the Rubik's, agent, it's a tiny agent, that gets installed on your host. Once that's done and you add it via the, you know, you add the instance to the inventory, what do you do next? You assign them an SLA. Let me show you quickly one of, like, for Microsoft SQL, if, I basically... I can add a host. I can select the cluster where I want to, save the data in. And once the host is onboarded, you will see them listed here. By default, there is no backup, no SLA because there is no SLA assigned to it. So, what you do next is essentially assign an SLA or create an SLA and assign it. Creation is simple, and the process is same for any, database as well as cloud or other on prem stuff or SaaS stuff. So you select the database you want to. For example, I'm going to do SQL, and you have the option to enable retention lock. This is, very helpful because if in case, the attackers or cyber attackers get access to, your database or your backup infrastructure, they cannot go and modify the retention period or they cannot go and delete your data. So we highly recommend, our customers to enable it so no one can just go and start deleting your data. Next, you define your frequency, how often you want to do the backup. I'm just going to do four and seven for now. You can even specify a snapshot window, as well for each of the frequency if you like. Otherwise, it'll... The, first backup will be as soon as the SLA is applied, and it will continue based on the, SLA agreement. Next, you can archive and replicate, the backups. See, by default, we don't back up the log backup, but we obviously ask you to, enable it and you can decide how frequently, you want to back up your logs. Now this is what... This will determine your RTO, RPO situation as well. Right? So if if it's mission critical, you may not want sixty minutes. You may just want fifteen... Every fifteen minutes. Right? So you can decide, and then save the, keep, the retention period and then give it a name. That's all you have to do. They can mention for SAP HANA or d b two, you can define your increment, your incremental or your differential, free... Backup frequency as well. So once you do this, you do this, you go to your instance, and essentially assign the SLA at the instance level, or you can even do it at the database level. Now if I just, do it at the instance level, like you can see, like, all the database and the, everything else, host instance and the database are automatically, discovered. If you assign the SLA at the instance level, all the databases, will be protected by default. And if you add a new database, they will also get protected. However, you can actually assign different SLA for each database as well. So, what you get here is like this... Sorry. My system is a bit slow. Give me a second. Let me put a different database. Oh, because there is no backup for this one. Okay. Okay. So what you get is basically like a calendar view when the backups, was completed. If you have backup available or not, I'll just select yesterday's. It'll tell you what the log backup frequency is. It'll give you all the snapshots. You can... You have the option to recover from the snapshot and then add transaction logs as well. Or, you can actually select the point on time to be the most recent and then do the recovery as well. So this ways, it will recover, from, it will automatically apply all your transaction logs and your log backup. So to make sure that you have the latest and greatest copy, you have the option to either mount... Like, that is the live mount, restore. That's the in place recovery. You can export the database or you can, you know, even download as well. So you would talk... Someone asked me about archive. Yeah. You have the option to, download it from archive as well. Okay. So these are some of the options available, for your, backup and recovery. Now I'm only talking about SQL here, but if you go to other databases, you will have similar options for backup and recovery. So, backup happens automatically once you want to do the recovery. You will, see exact same interface, exact same date. You have the same options as well. We do have HADR capabilities for most of our database support as well. Some of them are slowly rolling in, but for most of them, we do have HADR capabilities, flex motion, and things like that. Okay. With that, I don't see chat. I don't see any more questions. Oh, yeah. This is a nice one. What is the best practice to backup SQL? Always on cluster for a complete protection backup on VM level, in... Instance level, database level. How about availability groups? So, I think if you have, if you have availability groups, of course, you should protect at the availability group level. It depends on how you are set up, but, we do have the option you do, backup, depending on how you have implemented your database. But by default, if you don't have, availability group, we will always recommend to back up at the instance level. So, you know, at the instance level, you can give, probably, like, SLA frequency of every day. And then as in when you start, adding new databases, you can change the SLA frequency as well. So, what if you add a new critical database and you forget to set up an SLA for backups. Right? By default, at least, it will be backed up once, a day. So we always advise on doing that. That's our best practices to ensure at least you have a way to recover in case you forget to back up your newly created database and what if it goes down. Right? So that's a probability. Oh, yeah. This is... Okay. So I will explain how does Rubrik know if the data corruption occurs during a backup. So before we call the backup process complete, there's a step built into. So, basically, what we do is, you know, we connect via Rubik, the RBS agent, Rubik backup service agent. We do some mounts that we can use secure thrift as well. We identify the data that needs to be copied, over if it's not your first time backup, if it's an incremental backup, essentially. Once we finish... Before we finish the process, we do, check for, data corruption. We do a lot of, I think, what? Similar to hash check, we do, check for what we've... Like, we compare, the data basically in the backup as well as your production system to make sure that the data is same, at every point in time. Like, we have copied it correctly. No reconnection happened, things like that. So the... Yeah. The checks and values. That was the word I was looking for. So we do a lot of checks and value comparisons, before the database, backup is completed, just to make sure that, we don't cause any corruption, once we, do the recovery. Okay. Just looking at more questions. Oh, how do we back up for SAP HANA database? No. It's not, it... I mean, behind the scenes, we... It's not same as our man or SQL. We basically, in, we have a interface that connects to, I think it's called, in in client or something. I'm forgetting the exact name. But we basically connect to the SAP HANA, backup connector that is offered by HANA. So we have developed an interface to connect to the backup interface and we've backup wire that. So we want to, utilize and make sure that we are in compliance with every, database we protect. So it's not a standard way of, protecting in the back end. What you will see is the backups are completed, but we always, partner with, the vendor and we see what is available from the vendor in terms of the interfaces to, backup from. So, yeah, it it varies slightly for each database. Is point in time recovery to a different target, or dump files supported? Yeah. We do support that. Basically, it can be an export or it... Like, it's called differently. It's either an export or you can select, like, recover to a different target. Again, if you go to HANA, it will give you the option. Instead of export, it'll say, recover to a different target. So we do have the option to do that for all our databases. I am not going to... I have some questions here about, performance. I'm not... Sorry. I'm, not going to get into that. But if you do want to get some, performance related pricing, packaging information, you do you do need to, talk to your, representative to get that information. Okay. I think I answered most of it. And in the interest of time, I think I should write. I was I was just gonna say I'll peek it. There are, a couple others, but maybe we take a break and then you move on and and kinda wrap. up the content, and then we can. jump back into it. Okay. Perfect. Thank you so much. So like I mentioned, we do have product support for a lot of databases. More is coming, look out for, the the information that comes out at the end of January, February as well. So we have lot of product... New product announcements coming as well. One thing I do want to talk to you about is that we have lot of customers that are already using Rubik, and multiple, types of databases. So we... Rubik is actually protecting over 3,000,000, database objects, and the largest database we are now protecting is over one petabyte in size. And we have over 100 k. Like our customer... One of our customers that has largest deployment of database, and they have about 100 k databases. So we are able to protect all of that and more. So, just wanted to leave you with that. I have lots of resources listed in, the slides and Hannah is going to send you a lot of great information as well. We have lots of cool new white papers. We have lots of webinars coming up, and we have a Cloud Resilience Summit as well. So you can get information about Cloud, about database deploying... The database that are deployed in your different Cloud. Of course, feedback is always welcome. If you have more questions, you can either reach out to me or you can reach out to sales@trot.com as well. And with that, Hannah, I will, give it back to you, because we just have two minutes, left. Yeah. We can stay on a little bit longer to maybe answer those, questions, but I just launched a survey. If you get the chance, would love to get your feedback. I'm gonna drop the links now into the chat. So if you could navigate to the chat for the guided, demo. I don't know if you wanted to speak to that at all, Deepika. Oh, yeah. Thank you so much for reminding me. So, basically, it's it's the click through version of what I just showed you. I have, I I did try to share multiple database protection. So there's Oracle SQL, Postgres, etcetera. And we have a lot more available on Rubrik Explore as well. So, if you have a particular database in mind, you can check out. And if I have not shared the link with you, you can go to explore and find that as well. And easiest way to navigate, rather than click is always the left and the right arrow key. So if you're just sitting and just trying to experience what the product looks like, what the onboarding process looks like, installation process, things like that, recovery process, you can just keep hitting next, which is the right key, right arrow key, and you can get through the demo in no time and learn more about Rubik. So with that, I'm going to wrap up. Thank you so much, for spending the hour with us, actually, the complete hour. So, yeah. See you again for the next Well, Opika, I was just gonna say, let let me chime in here real quick because I extended the session so that, you know, we're we're not gonna get kicked out. here. So if. anyone is staying on, if you want, I can help you navigate through some of those last questions. And if not, like Alpika said, we will be in touch. We record who asked the question so we can reach out directly, you know, make sure that they get answered if we don't get to it today. But in that survey, there's a question at the very end that asks you to enter your valid business email. So please do that so that we can be sure to send you the thank you incentive for joining us today. I hope that's not the only reason you joined, but it's always nice to have, a little thank you for your time. So please please complete that. That would be very helpful for us. And just the other thing that I wanted to note, this will be in the email, that you'll receive twenty four hours from now, but that won't be sent. That gift card likely won't be in your inbox, until next week. So we have until end of next week to do that, just to make sure that everything's buttoned up on our end and that when you actually receive it, you can activate it. That's the most important part. And there were some errors that we experienced, last week, so we wanna make sure it's clear. So just be patient. If you don't see it tomorrow, nothing was wrong. It just might take till end of next week. And if you don't receive it at all, it might be because you didn't meet the requirements, that were clearly laid out in the terms and conditions, but hopefully you do. So that's that. And Alpika, now if you don't mind, do you want me to help you navigate to the questions? There's a way to just see the ones that are unanswered. Okay. So if you go to the left hand side, you can. filter by unanswered or even directly in the q. and a. You should see... Okay. Perfect. Yeah. I see it now. So one question, very interesting question. So I'm having difficulty backing up my SQL BizTalk on, Microsoft BizTalk on MSSQL? Do you have a document on best practices for backing up databases not compatible with MSSQL consistent features? Maybe support ticket would be best. We do have... We are... It's called managed volume. That's our catch all, way to, protect anything that is not not, workload protection by itself. You can open up support ticket or talk to your, rep as well. Looks like I'm gonna get kicked out from the room. So... Yes. Great comments are essentially live mount and exports are like VM snapshots, pretty much. It is point in time recovery to a different target. I did answer this one. I'm not sure what SRM VMs are. So the question is, what is the best way to protect SRM VMs? I'm going to get back on this. I'm not sure. I'm sorry, Hannah. I have to jump. okay. I'll wrap up. Go ahead, Okay. Alpika. Thank you so much. The the beauty of working in the office is you have to book the, the rooms. Yeah. I I hear everybody wanting to... Me to relaunch it. I am going to try. Let me see if I can relaunch it for everybody. Okay. I just relaunched it. So if you didn't get a chance to fill it out, do it now, and I'll stay on here for a few minutes that you get the chance to do that. But it should pop up in your, next to, like, the chat or docs right there, and then you can complete that for us. So I'll just stay and hang out. But really appreciate everyone. Like I said, just be on the lookout. You'll get a follow-up email, in about twenty four hours. And then, again, that should be in your inbox by latest end of week next week. But... Yeah. Okay. Yep. It's relaunched. So it's not gonna go directly to you. It's gonna be, it'll say, like, right now, like, chat, docs, q and a. There should be something that pops up that says survey. If you already submitted it, you can't submit a survey twice. It's only gonna be one per person. So if not, the good news is I can see who you are. So I can probably do some, you know, thing... Critical thinking on the back end to see if if you didn't put your email in. I'm sure I can find it with how you registered. So not to worry. We'll get you taken care of. Alright. I'm gonna give it one more one more minute here. So get your responses in. If you guys don't mind, we can go ahead and wrap up. Great questions. I know we didn't get to all of them, but that's a good problem to have. Again, hopefully, you got more out of the session, with some of these real life questions that you guys are running into versus just kind of going through the slides. So appreciate everyone's engagement. Okay. Alright. I'm gonna keep this open, but I'm gonna go ahead and head backstage. Thank you, everybody.