Transcript
you've probably got your automated backups turned on and figured, hey, I'm covered. And honestly, for a lot of day-to-day scenarios, those native backups, they'll work just fine. But here's where it gets interesting. Those native backups live in the same project as your production database, the same blast radius. If someone compromises your GCP project or you hit some sort of accidental deletion, well, your backups, they could go right along with it. On top of that, there's no immutability guarantee, no logical error gapping, and backups have the ability to drastically impact your production services. This is the gap that Rubrik fills. Today, I'm going to walk you through how Rubrik protects Google Cloud SQL from setup to backup to a full recovery. Hey there, I'm Mike from Rubrik. And before we jump into the UI, let me quickly explain what's happening under the hood because it's actually a pretty clever workflow. So when Rubrik backs up a Google Cloud SQL instance, it starts by taking a native GCP snapshot of that instance. It then spins up Exocompute, that's Rubrik's ephemeral compute layer inside your GCP environment. And Exocompute uses that snapshot to deploy a temporary database. From there, we'll leverage pgdump to extract a logical backup from that temp database, which leaves your production, well, it just leaves your production database alone. We then store that backup immutably, either in the same or in a completely different Google project. And of course, we tear everything down, the temp database, Exocompute, all of it, nothing lingers around. In the end, you have a portable, immutable, logically consistent backup that lives completely outside your production GCP blast radius. All right, so let's see how this is accomplished. Now, I've already got my GCP project onboarded into Rubrik Security Cloud, so I'm not gonna spend a lot of time on that setup. It's pretty straightforward. The key pieces are you connect your GCP project, configure an Exocompute region, which is where Rubrik's gonna spin up that temporary compute, and then your Cloud SQL instances get discovered automatically. Now, after we're onboarded, we can see all of my Postgres SQL instances showing up here. To protect them, it's just a matter of assigning an SLA domain, the same workflow that you'd use for any other Rubrik workload. I'll assign my instance to an SLA where it takes daily snapshots, keeps those for 30, and then takes monthlies and keeps them for a year. Now, if we wanted to archive off some of that older data to cheaper storage, that's all configured within the SLA as well. Basically, a single policy engine that we just apply to our workloads, and that's it. Protection for our Cloud SQL instance is now configured and live. Now, Rubrik's gonna handle all of the scheduled backups automatically, but let's kick off an on-demand snapshot so we can actually see this in action. I'll click into the instance here, and I'm gonna initiate an on-demand snapshot, selecting that same SLA to apply to the backup, and away we go. We can see the event kicked off, and if we click into it here, we can see everything is running. Now, behind the scenes, this is running through that whole workflow that I just described, snapshot, exocompute, tempdb, pgdump, storage, cleanup. But from your perspective, it's just a matter of walking through this wizard. And through some video magic here, we can see it's now complete. We've got a new recovery point that we can now use. And recovery is really what matters most. So let's say something goes wrong. Someone drops a critical table, bad migration runs, ransomware hits our project. Basically, we need to get our data back, so let's do just that. I'm gonna select a date from our calendar view, and then I'm gonna select a recovery point from earlier today and walk through a restoration. So right away, we have two different options. We can perform a recovery, which is essentially an in-place restore. This means data will go back to the original Cloud SQL instance, or we can select to export our database. This will create a new Cloud SQL instance from the selected point in time, leaving our production instance all alone. So let's go that route. Now, when we're doing an export, we do get the option to modify some of the database parameters. We can see here, we can specify a project and region. We can give the database a new name, change its storage settings, things like that. This all looks good to me, so let's just continue. And away we go. Now, if we navigate into our events here, we can see that Rubrik is going through the motions to recover the database. And again, through a little bit of video magic, we can see we're done. So let's jump into our Google console and make sure that we have our database. And of course, there it is. There's our exported copy, ready to be accessed, recovered from a clean, immutable, and air-gapped backup. So that's Cloud SQL protection with Rubrik, end to end. The native GCP backups, again, they're fine for basic operational recovery, but when you need immutability, air-gapped separation, and recovery that works even when your GCP project is compromised, that's where Rubrik comes in. The same SLA-driven policy engine that you'd use for your GCE VM instances is now extended to Cloud SQL. One platform and consistent protection across your entire multi-cloud estate. Now, if you want to check out the solution for yourself, give one of our hands-on self-guided labs a shot on Rubrik Explore. You can find the link down in the description. And until next time, thanks for watching.
