Backups and Recovery

[MUSIC PLAYING] What advice would you give to someone who's starting into a database migration project? We know we're going to be taking a backup, but we have zero experience. What advice would you give? Would you say hire somebody that has experience? Well, I would say that regardless if you're doing a migration or not, you should have regular and consistent backups of your database. If your database is running on a virtual machine, I would say you should probably take a belt and suspenders approach, which is to get a backup of the entire virtual machine where the database is running but also get a granular backup of the database, which typically uses the vendor's API in order to perform the backup. Those tend to be a little bit more flexible in options on how you can restore, whereas a full virtual machine backup will typically only restore the entire machine back to that state at that point in time. So having that granular backup is important. But also, depending upon how you're migrating the database, having an entire system backup might also be important. Yeah, we're toying with the idea of going Big Bang or to do kind of a trickle-type migration. So we're just talking about that. If we do Big Bang, that's obviously an easy thing to do in terms of taking a backup. The real-time data synchronization might be a little bit more of a challenge, but taking the backup to move the data originally, that would be a good thing to do. Yeah. And a lot of times when you're doing a database migration, really any kind of migration, sometimes the best strategy is to take incremental migrations. And in the meantime, while each migration increment is done, you're testing your processes and making sure that things work. And this applies to databases as well. So if you're going to be able to make a copy of your database in a different location and incrementally push over the changes, along the time when you're pushing over those changes, after each iteration, you verify that things are working normally. And then as part of that migration, it might include doing the complete cut over where you shut down the database and move everything else over. And then you know that on the other end it's going to work because you've been incrementally doing those migration points along the way. OK, gotcha. Listen, last question. I know you're cut for time. Criteria for identifying a backup solution for, I suppose, enterprise backup, but specifically that can do both databases because I know DBAs prefer to do their own backup because of trust issues. But what would be the criteria be? Well, you hit the nail on the head. A lot of times, dBAs don't like to relinquish control of database backups. Many companies will have a backup team that doesn't do databases because the DBAs prefer to take control of that. I guess when I'm looking for a backup product that I'm going to use prior to my migration or maybe even as part of my migration, I want a tool that can deal in both worlds, where the backup admin has control of the backup and the DBAs can also have some control of the backup. That might sound like a bit of an opposing view, but there are products that take those into considerations where the backup admins don't have to relinquish complete control of the backups to the backup admin. And naturally, I would think those products are the best ones. Well, I've got to ask, does NetVault-- is NetVault one of those? Yeah, so NetVault does have some pretty unique capabilities when it comes to that. It has Oracle Database, for example. Oracle uses a tool called RMAN to actually perform the block-level differencing of the disk and figure out which data blocks need to be backed up. Because of that integration with RMAN, we're able to use existing RMAN scripts. And that's a key point because a lot of DBAs don't want a backup product to touch their database because they're unsure of what it's going to do. Is it flushing transaction logs? Is it committing transactions when they shouldn't be committed? Things like that. So by allowing that RMAN integration and being able to perform the backup using only the parameters that are in the script, which would be in control of the DBA, we can give the backup admin what he needs, backup the database and protect the company's data, but give the DBA what he needs, which is to be able to control what exactly is happening to his database when the backup is happening. And so let's say I'm database agnostic. So you mentioned Oracle, NetVault. Is a database agnostic, or does it have specific, I suppose, APIs or calls to do different databases? Well, yeah, going back to your original question, which was, What kind of criteria should I use to evaluate database backup products? yeah, you want to be database agnostic. So you want something that's going to have wide coverage. But wide coverage, I suppose, really doesn't matter if it doesn't cover the databases you need. So with NetVault specifically, it covers Oracle, Postgres, MySQL, MongoDB, SQL Server, obviously, DB2. It covers most databases that are going to be in use by this-- That's fantastic. I do have one database for you to add to the product roadmap. OK? Aaron, you ready? Yeah, no pressure. Redis. Redis, yeah, we get that one a lot. We get Redis and not only Redis but a lot of cloud databases too. So most of our database support has been focused on prem. Yeah, it's good. It's good. Aaron, thank you so much for your time. It's very much appreciated.