Hi, and welcome to Backup Central's Restore All podcast.

I'm a host w Curtis Preston, a k a, Mr.

Backup, and I have with me my Monday morning melancholy

minimizer Prasanna Malaiyandi?

Wow.

How's it going?

So we won't get into your melancholy, but here, here's some good news for you.

You know what this, you know what today is.

There's two important things that happened today.

W. Curtis Preston:

It's, no, I got nothing.

So the first one is I now

Oh, do you?

year.

You know the day you're three actually.

It was actually a couple of weeks ago.

It was, it's actually two weeks ago.

Right.

But I do now have a three-year-old beard and three-year-old hair.

I don't know what you call three-year-old

what I call three.

Yeah.

In need of a haircut.

That's what I, that's what I call that.

No, it's fine.

And.

The second one is, this is our 200th

Are we really recording our 200th episode?

Wow.

That's almost four years of podcasts.

That's a lot of talking.

And thank you to the listeners for listening

to us for these last like four

I'm, um, I'm on another podcast that

doesn't have as many listeners.

Um, and I mean, it has very, very few listeners and it's not, you

know, it's just not the same.

Like if you, if you're producing a podcast and no one's listening to it, it's gonna.

You're like, why am I doing this?

But yeah, we've got, we've got, um, you know, um, thousands of you out there that

are listening to it and we appreciate it.

And without that, uh, this would seem like a lot of effort for nothing.

So, um, definitely, um,

Yeah.

Well, that's good.

You know what?

See,

Prasanna Malaiyandi:

make your Monday a little

brought, that, brought that, that helped me out.

I'm having, I'm, I'm not having the greatest Monday here and see this.

What, this, why, you know, you're my Monday morning melancholy

minimizer, but, But the, but the beard, the beard and the hair thing.

I know, man.

I mean, it, it's funny for those of you watching on the, on the, you know, you

can see the video of this if you go to backup central.com or you can listen to

it on, you know, on any of the places.

And, uh, but those of you looking, you, you see me, I just got a new

haircut talking about this nice trim saying, I've got this nice

trim, trim kept to my face, beard.

And then we have Prasanna.

Uh, that is the complete opposite.

Yeah, I, I, I once had a friend, hi Jane, who

referred to me as the caveman.

And this is what I had a normal beer too.

Not like this.

opposites in so many different ways.

Um, you know, like when it comes to movies and, you know, when it comes to

the things we enjoy eating, what, there's some stuff we like eating that's similar.

Um, but, and I, and

And this is why we get along so well,

whole opposite attract thing.

Um, well, uh, we're gonna continue our, uh, backup to basic series,

uh, today, talking about databases.

Before I do that, I'll throw out our usual disclaimer.

I and Prasanna work at different companies.

He works for Zoom, I work for Druva.

This is not a podcast of either company.

Uh, the opinions that you hear ours.

If you'd like to join the conversation, just, uh, reach out to me, w Curtis

Preston gmail, or at WC preston on Twitter and also linkedin.com/iin/mr.

Backup.

You'll find me there as well.

And, uh, you know, um, join the conversation, right?

We'd love to have you on.

And also please rate us, uh, go to your favorite podcast or scroll down

to the, to the comments and um, you know, give us some stars and some

comments we love that keeps us going.

Uh, except for that one guy or the, gave us one star.

I don't know what his deal was, but, um, it's one person.

It's one person that gave us one star.

And he doesn't say why.

I'm like, Hmm, that was harsh.

Um, Who that is.

Yeah,

tell us so we can

I think, you know, if you want to say, listen, I would

really like to listen to that podcast, but Prasanna needs to cut his hair.

All

Not gonna happen.

I'm sorry

know, it is what it is.

Well, we are continuing our, um, our backup to basic series, which

is based on this, uh, latest book that I wrote, which of course I

had lots of help from Prasanna on.

Um, and it's, uh, modern Data Protection from O'Reilly and Associates, and, you

know, you can find it at, uh, wherever.

Wherever books are sold, um, you can get both, uh, an ebook

version and a printed version.

And, um, So let's talk about, uh, th this is about protecting databases.

So I, I know I've told this story on the podcast, but it was a broken database

that basically started my career, right?

Um, that, yeah.

Um, it was the, the name of the database was Paris.

It was my, uh, my bank's purchasing database.

And, uh, we were backing it.

Via what I would now refer to as the hot backup method where you put the

da, you put the data files into backup mode, and then you back them up.

Except that we had moved, um, we had moved the server over to another, we

had moved the database over to another server, and nobody had told me that,

that I needed to put the script in place so that I could do the backups.

And we had been backing it up for months without, you know,

without getting a decent backup.

it was inconsistent.

And, um, I remember sitting there and the, the boss was like, so

let me, let me get this straight.

We have absolutely no backups of Paris whatsoever.

And I'm like, that is what I'm saying.

Uh, and she didn't fire me tr you know, chalked it up to bad training.

Uh, Ron Rodriguez, all your fault to this day, I'm gonna

throw you under the bus for that.

You're like, you're like a name That sticks in my head.

good guy.

But yeah, just he left that out of the training.

So, uh, so I think it's important for you to understand databases

because they are, you know, I think for, for many environments they're

more than 50% of the data center.

Isn't that, isn't that normal?

Like for structured data essentially to be,

I think that's changing these days.

Oh, sorry.

For structured data for most of it to be stored in databases.

I think that would be a

So you're not necessarily agreeing that

most of the data in the, in the data center is structured data.

You're thinking that nowadays unstructured data is more because we're just, yeah.

Okay.

Yeah, yeah.

We

data.

Yeah.

And, and if, and when you, but if you do caveat it with saying in the

data center, I think that statement

You know what's funny?

The phrases like that come out of this old mouth, and I don't

even mean it when I say it.

Yeah.

I don't, I mean, in the computing environment.

Um, so you, you're thinking that there's a lot of stuff up there.

Just because of the amount, large amount.

Oh yeah.

Just the large amount of data that's out there in the world.

Right.

And unstructured

There was a time when structured data, data

and databases specifically was the king of the data center.

Right.

Um, and then, um, then we just started storing on just all kinds of nonsense.

Um, we just, we as a, as a human race, we have seemed to have a

never ending desire to store stuff.

Pack rats.

Pack rats.

That's what we

Um, so I, so the, you know, if, if you don't know anything

about databases, the, you know, you should learn a lot in this episode.

If you know a a lot about databases, you may know more than I do.

I am not a dba, uh, I have never been a dba.

Uh, I have often been at war with DBAs, um, but.

That is a database admin who, yeah, from a

backup admin perspective, probably

uh, I, I've run into a few fights, you know, I've had

a few fights, but, um, so I think it's important to sort of divvy up the,

you know, the computing world into these different buckets so that we

understand what we're talking about.

And the first thing that I talked about was database delivery model.

And the first is, uh, is traditional database software.

What would you think I would mean by that Prasanna?

And maybe give an example.

Yeah, so the biggest is you basically take the software, you

download it from the vendor, you deploy it on your servers, you're managing

it, you're doing everything else.

This traditionally has always been like Microsoft sql.

You have your Oracle databases.

I think those are probably the two biggest,

Still, still Cybase.

Informix is out there and, well, and of course, yeah.

Yeah.

I don't know.

MySQL might actually be the biggest database out there.

Um, in terms of just certainly number of deployments, but many, many, you know, but

I wonder if we added up all the gigabytes of all the little tiny MySQL databases.

Um, I mean, the Backup Central has a bunch of MySQL databases behind it.

Uh, but yeah, that's basically, you know, that's normally what I think

many people think of when they think.

Databases, right?

But then if we take that database and someone else runs the database

application itself, right?

And then all I have to deal with, so basically they're gonna manage the

storage, the patching of, you know, Oracle, MySQL, uh, the security, perhaps

the security administration of it.

And then all I have to do is add database, add table, um, then that.

Mm-hmm.

Exactly, and then start using the database.

That would be what we call a PaaS database or platform as a service.

You get the database platform, and the best example I have

of that is aws, r d s, right?

Relational database service.

From a backup perspective, the main difference between these two is that

you don't, you, you can't necessarily install, like if you want to back up,

um, Let's say, uh, SQL Server, you can install a SQL Server backup, uh,

uh, a agent right it on it, right.

You, you don't

observe it,

And just quickly on that, I don't know if we'll talk about

this later, but, and, but I think that's where a lot of these vendors who are

providing PAs databases sort of try to bake in backup and some of these recovery

operations into the platform itself

yeah, they, they do, they do tend to build in backup features.

You often need to actually execute those features.

You need to actually, uh, Drive the backup, but they give you the tools, they

give you the car, you gotta drive it.

Um, there is one interesting one, and I'll pick up on Amazon.

I'll pick on Amazon here for a minute.

Amazon, r d s does support, um, uh, RMAN for Oracle.

Let me, let me rephrase.

They support Armand backups for Oracle.

You know what?

They don't support.

S B T

No, they don't support rman restores for Oracle.

oh oh.

That's.

You

can make, you can make Rman backups with Oracle, with Amazon rds.

But the last time I checked you cannot do am you cannot do, uh,

rman restores, which is just odd.

Uh, it is

but I think that's where they hope that you're

using like their built-in snapshot and capabilities and everything else like

that to if you need to actually restore.

Otherwise it's like, hey, you have an Armand backup and you

could take it offsite or to your

own instance, if you will, to do your restores.

I guess it's more, yeah.

Yeah.

Um, just a weird one.

So then the next one we have here is serverless databases.

You want to tackle, tackle that one?

Yeah, so we just talked about, okay, you have.

Sort of someone else managing the server, but you're still

managing all the databases.

You also typically are involved in sort of performance tuning

at that point as well, right?

With serverless, you're sort of getting away from all of that.

It's like, Hey, here's a database endpoint.

You don't even do sort of the normal, basic operations other than sort of

accessing the data, and it automatically sort of scales up, scales down on its own.

You don't have to worry about it.

Now, it's funny that everyone talks about serverless, even like serverless.

In the end,

there's still a server somewhere, right?

Right.

But you are not

managing it right.

Yeah.

Um, and the, the biggest example here I would have would be DynamoDB.

I mean, there are a bunch of serverless databases, both on Amazon and

other, other, uh, cloud providers.

But the idea with, with Amazon db, I think, I think it, it,

it's a perfect example of how, how you can make it very simple.

With Dynamo DB , you just give it a key in value.

Right.

You have an account, you have a authentication, you give it a key and

value pair and it will store it somewhere.

You're not creating that table, you're not creating a database,

you're not creating any of that stuff.

You're just say, Hey, here's a key and a value.

Uh, store it for me and I'll ask for it later.

So that's what I'm calling the database delivery models.

And then we've got the database models, which are, which are like

the different, that's how you would, that's how you might get a database.

This is what kind of database you might get.

Um, and the biggest category, what would the biggest category be?

What do you think?

And by the

Well, it depends.

It

not even.

Well, I think it depends on what

you mean by biggest, right?

Is it the number of deployments?

Is it the sizes?

Right.

I don't know.

I'm just talking about the, the db engines.com, the most

popular

relational databases.

databases.

Yeah.

It looks to be over 75% of, of the other ones.

There are other types.

One of them is the one I just mentioned, the key value pair database.

Right.

There's time series, there's graph databases, document databases, a

database just for search engines, right?

Th these are the different types of databases and they tend

to behave differently from a backup and recovery perspective.

And I do think it's important for you to understand, um, you know, the

type of database that you're backing up when you're backing it up, right?

That's

Because they each have their own nuances and differences.

It's not like a database is a database because from backup

and restores, they're completely

different.

Exactly.

And then this is where I think we really get into, you really need to understand

this when you're doing a backup and recovery, and that is the different

consistency models of a database.

What do you mean by consistency models?

So immediate.

Right versus eventual versus hybrid.

These are the, the, the different consistency models, right?

Immediate is the one that most of us think of when we, um, When we take a

databases, at least, I'm, I'm gonna say it's probably the most popular,

again, relational database management systems, RDBMSs, those are, I'm

pretty sure those are all immediate.

Wouldn't they be all immediate?

I think so.

yeah,

yeah.

But then eventual is the one that I struggle with.

It's like, why would you want that?

But,

yeah.

Well, I

sense once you realize how they're

typically deployed.

Yeah.

Well, and here's a good example, right?

So you have a bank, you go make a deposit with immediate, it's like, Hey,

the transaction shows up immediately.

You can use it, right?

With like eventual, it's like, Hey, you made a deposit.

Sometime in the next 24 hours or so, your bank balance will, or

your bank account will balance out.

But until then, you may be able to withdraw funds.

Sometimes you may not be able to if it hasn't cleared, right?

So,

Yeah.

That's kind of how I like to think about it.

The example that I used in, um, the book was I used

DNS as an example of the concept of eventual consistency, where, um,

you're gonna get a different answer depending on who you ask and when,

Yep.

right?

You, you create a, a DNS entry and it takes a while for that entry

to.

Propagate

Propagate throughout the system.

Uh, and the same is true of, of, of an eventually consistent database.

And the thing is, you can't use the eventually consistent model.

If getting a wrong answer will will break the, I was gonna say, yeah, we'll break

everything.

um, but.

You know, it, it is weird though, right?

It, it's weird.

It's, I struggle with this idea of eventual consistency, um, and,

um, how it would be okay for you to get essentially a wrong answer.

but I think it depends on the

application, right?

Where

it absolutely

if it's, yeah, like if it's okay for you,

cuz there is a trade-off, right?

With, uh, immediate consistency.

Typically there is some sort of latency associated with committing

a transaction, especially if you're talking about multiple nodes, right?

Which is typically where

you see the eventual.

Yeah.

You look at dns, for example.

DNS would break if

Could you

to be, if it had to be

immediately consistent across the entire world, right?

That's the thing.

Immediate consistency is very tight, right?

You've got to have it right.

And then I also listen hybrid, which is, um, somewhere between the two.

So here's an example I have.

So for example, DynamoDB users can tell DynamoDB they want a

strongly consistent read, and it will always read from the leader.

Um, where the right was initial, which is the leader is where the

right was initially made, even if it is still being replicated elsewhere.

So that's hybrid.

It's an, it's eventually consistent database, but you could say when

you create a key value pair in Dynamo DB upon read, always read

from the first person, right?

Um, yeah.

There, there's a bunch of a MongoDB Couchbase, uh, that support that.

Um, I had listed here of immediate are all the ones that we, the, the

ones that everybody knows their name, Oracle Sequel, you know,

uh, I have, uh, eventual consistency.

Uh, I have Cassandra and Neo four J.

And then I have, as hybrid, I have Mongo and DynamoDB.

Those are just an example.

Um, by the way, all that stuff comes from a great website,

um, called uh, db-engines.com.

Um, they list all that stuff in there.

So, um, The next one, I have a bunch of terminologies here, and I'm not

gonna go through a lot of them, but, um, I think one that people

struggle with is the difference between an instance and a database.

Um,

What, what is the difference

between an instance and a database?

well, an instance is essentially the way I, the way I

would describe it is, In many cases it's the same, but an instance is a set

of processes to talk to the database.

And the database is, well, what we normally mean when we say database, right?

Um, so, uh, so let me, lemme just read here, because I, I, I got this like,

check, you know, 50 times, you know, uh, there can be multiple databases within

an instance, and a database can also be distributed across multiple instances.

Right.

Um, on the same machine or on separate machines within a cluster.

Therefore, an instance in a database are two entirely different concepts.

Historically, an instance ran within a server, but modern database

platforms have instances that span multiple servers and node, right?

Um, so the instance is basically the thing that runs inside a server or a bm.

Talks to this thing, but a database could be across multiple

instances or multiple databases.

That instance, um, it is

complicated.

See, this is why, this is why

but, but, here's here, here's a

go ahead.

though.

As a backup person,

what do I need to worry about in that case?

Do I worry about more of the instance or the

database?

Well, you just need to know.

You need to know that there, yeah.

It depends.

You need to know that there are different things because.

It, it's going to dictate how you communicate with the thing that

you're trying to back up, right?

Um, in many cases, I'm, I'm gonna throw you prob again.

I'm gonna say in most cases they're the same, right?

They're not the same, but they're in the same place.

There's one instance and there's one database.

Most of the databases that I worked with, it was one

instance of one database, right?

Um, The, um, but you just need to know that that's not always the case, right?

We all know what a table is, right?

Um, you know, I, I liken it, I liken it to a spreadsheet, uh, but it's not the same.

The, um, and then there's this concept of a data file, which is where we stored the.

Right where the database stores the data.

Um, and this concept of a table space, which is what it sounds like, it's

a space where you put tables, so you could put many tables in this database.

Um,

And each database does it

slightly differently.

yeah, I'm, I'm trying to be very, very general here,

Yeah.

And I think the other question, and I know we talked about this at the

very beginning, talking about the problem you ran into with Paris, right?

It's just because you have a database doesn't mean you could just take all the

database

files and copy them out

No, you can't because the data, those data files

are what you're trying to back up quite often.

And if you're backing it up outside the world of the database, the database

is changing those data files while you're, while you're backing it up.

And it's, it's not gonna be consistent, you know, part, part of the, part

of this file that you backed up.

Part of it's gonna be for one point in time, part of the file is gonna

be from another point in time.

No, no.

Good.

And then, Again, going for a very generic term.

Here I have this concept of a master file, and that is sort

of the database of the database.

Um, a perfect example is the Oracle control file, right?

The, um, uh, again, this is most databases.

Not every database has this, um, it, it might be a J S O N file, right?

Um, go, what were you gonna.

does it ever feel like inception when you're working on

databases where it's like a database

within a database, you know?

Yeah.

Uh, by the way, SQL Servers master Database has this concept.

Essentially it's the thing that's keeping track of all the

things that we're talking about.

What are all the data files?

What point are they at?

What if we have a eventually consistent, you know, what,

what change level are we at?

Um, it's the thing that keeps track of all the things.

And, um, there

impressive that they actually used that piece of technology as

a core foundation of like keeping track.

It's like

that's kind of

neat.

Yeah.

Uh, and so there's going to be a different backup method for that.

If that file exists, there's gonna be a different backup

method for that file, right?

So you're gonna back up that database.

You're gonna, um,

In Oracle, for example, there, there's a command backup control file, right?

It's just a separate, uh, backup.

They're

now

exactly special.

Uh, and then we have a very important concept, and that is

the concept of a transaction.

You wanna talk about what a transaction is.

Yeah, so usually when you say make a right to a database, right,

you just issue the SQL command or whatever to do a simple thing, but that translates

into a whole bunch of other things.

Now, when you actually get that before it can apply to the actual

database, and I don't know if you wanna talk about logs right now, but

that transaction, typically when you think about a transaction, especially

on a relational database side, it's something that has to either complete or.

It's either the transaction completes and the entire database rolls forward

and everything's good, or the transaction doesn't succeed and no part of the

transaction is successful, so basically the entire thing happens or it doesn't,

which means it's atomic, right?

So it all happens and everything's successful, or no part of it happens.

So you don't want the case where it's like, Hey, I am withdrawing

money from your bank, but I don't set the balance properly, or

other things like that, right?

So it either all needs to succeed or none of it

succeeds.

Otherwise, the world goes crazy.

Right.

And that matters most when you, because there's two

different types of transaction.

They're simple and it's complex.

Complex has a bunch of different parts of it.

And, uh, that's a, a perfect example where you were saying that you, all of those

parts have to work or, or none of them are allowed to work and you will then.

So if, if we can't finish the entire transaction, let's say.

Um, the database crashes.

It's in, it's in the middle of that.

What, what do we call when we make that transaction?

Yes, we roll

back the

You roll

back.

Yeah.

Which basically, so now you have to think about it though, right now that

you have this concept of, okay, there's a transaction, it's atomic, it either

all succeeds or it gets rolled back.

Now if you think from the database perspective, you need to be able to

track all of these, because how do I know how to go back to a previous state?

It's like I need to.

The previous state.

Right.

So there's so many other things a database does as a matter of just accepting a

single transaction.

Yeah, exactly.

And, and that's why we have the transaction log, right?

So first, not every database has the concept of a transaction.

I still think.

Did every database has transactions, they just might not call it that.

Um, cuz every database is making changes, is storing data and making changes.

I think that generically every one of those should be called a transaction.

And, and by the way, this was one of my biggest challenges when I, when I

wrote my first, um, version of this, like, which is a really long time ago,

was trying to get, um, DBAs, again, of different database products to agree

on a generic term that would work and,

for everything.

yeah,

exactly.

And transaction.

Um, I is one of those things, right?

Um, but the transaction log re uh, Oracle for example, calls it a

redo log, some call it a, you know, um, so I ha I have the, um, It.

So what I do

The T log in

log might not

be there, by The way, I'm, I'm showing that not in all NoQ databases.

And by the way, um, we didn't talk about no SQL when we were

talking about database types.

I thought no SQL meant that they didn't use sql.

It's, it's not, it's not only sql, it's what is, what no SQL stands for.

Um, anyway, I just thought.

Important, but, but the transaction log is extremely important.

Um, the first being the one that we've already mentioned, and

that is the database crashes in the midst of something, right?

Either the database dies on the server or the server dies.

Someone pulls out a plug.

Um, and then when the database comes back up, This is the job of the

master file, the transaction log.

So we come up with the master file and the, and the database

looks at all of the data files.

And again, I know I'm using generic terms and these aren't always going

to be applicable to every database, but essentially the database comes

up and it's got something that looks across the database and

says, okay, something happened.

We need, we need to get back to a consistent.

Prasanna Malaiyandi:

Put Humpty Dumpty back

Prasanna Malaiyandi:

together.

Yeah.

Right before we can let people start, we need to figure out

if we had anything in process.

We need to figure out if there were any transactions that we started recording.

That we didn't finish, right?

So the database is gonna come up and it's gonna look at each data file and

it's gonna look at the, the control file.

Like in the case of Oracle, look at the control file, otherwise

known as the master file.

And then, um, look at that transaction log and say, all right, we were

supposed to finish this transaction.

And then you're able to go to each data file and say, what Transac.

What?

Um, there's a, like, I think it's called sequence number.

Sequence number is what I think Oracle calls it.

Look at the sequence number and say, did we finish here?

Did we finish here?

Did we, oh, look at you.

You didn't get to the sequence number.

You know what, we're gonna have to roll everybody back.

Right?

That's what, that's the job of the control file is, I'm sorry, the of the

transaction log is to roll everybody back.

Um, So that, uh, we don't have, um, consistency problems

inconsistent.

And then potentially you could also recover the database and roll back

forward and reapply that transaction

and not lose data.

Yeah, I wasn't gonna cover that yet, but in fact, I'm sorry.

We're gonna cover that in part two because I'm realizing that we've been talking

about this for a while and we're, you know, we're coming up on 35 minutes and

we've just covered sort of the basics.

We haven't gotten to the backup and recovery.

In the book, by the way, in the book, you occasionally see

these, those little, where is it?

The little scorpions, right?

And the scorpion is meant to be like a, a warning, right?

So here's what I have here.

Please note that just like everything else in data protection and protections

mentioned in this section, only protect against hardware failures.

So when we have.

All the things that are built into the database.

If a DBA accidentally drops a crucial table or a bad actor, uh,

deletes or encrypts your database, your fancy replication will only

make it more efficient, right?

It will immediately replicate whatever happened everywhere else.

This is why we back up databases too.

you about to say something?

I was just going to say that for the people

listening, Databases are complicated.

So if a lot of this sort of goes over your head, don't freak out.

Don't worry.

The database admins have been doing this for years and years and years, right?

And just like you've learned sort of virtualization, which we'll

talk about later, and physical or traditional, uh, sources as well, you

just need to understand the mapping.

And there are a couple different differences for databases.

But once you understand that, It becomes a lot easier, so don't freak out.

Don't worry if this all sounds like a different language, but

Yeah.

And.

just doing that mapping your head.

Yeah, and I listed, um, again, going to that db engines.com,

there are 13 types of databases and 300 different database products listed there.

So don't feel overwhelmed.

Um, this is not the world of, oh, is it Linux or, uh, windows or Mac, right?

This is, well, it depends, and there are types of databases.

I'll just be honest.

There are types of databases that I don't get.

Graph being one of them.

I just don't understand what or how they do.

I, I think you

I I heard I heard a new one.

Yeah, I heard a new one recently, which was, uh, vector databases,

which is pro apparently starting to be used for like AI ml.

Oh, of course.

The world of A I M L.

Um, the, the thing that, the thing that you need to understand.

Uh, about any database is that it has really important data

that needs to be protected,

Yep.

What you need to know about that database is, is.

From a backup and recovery perspective is you need to understand all

of the elements of that aspect.

Um, the one thing I think you will struggle with, with some databases and

some DBAs today is the same thing that we struggle with in other parts of of it, and

that is, Um, some DBAs of some products, confusing availability and um, you

know, that concept with data protection.

Um, and I think of like Cassandra MongoDB where they're like, oh, we're good.

Like we, you know, it's replicated.

We got everything three different places and, um, you know,

it's eventually consistent.

Um, and, um, we c we can lose a node.

We're good.

We can lose seven nodes.

The database will.

Okay.

What if we lose all the notes, right?

Or what if

someone drops a table

what if somebody drops a

table, right?

What if, uh, what if a, you know, a ransomware, uh, a threat actor

comes in and does bad things?

I, I don't, this is just like the same argument that I make in the SaaS

world is, um, Like everything needs something that is like backup, right?

I, I have the broadest term, the broadest definition of backup that I think

anybody in the industry has, and that is anything that copies the data to another

place for the purposes of restore,

Yep.

that's, you know, snapshots in a replication to.

Um, as long as we have the ability to go back in time, and as long as I

don't have the ability to, to attack the backup with the primary, that's my

biggest concern that I often have with snapshot and replication based methods.

Right.

Um, so hopefully if you're using snapshot and replication, hopefully on the other

end your copying that data somehow.

Yep.

Um, if, if that's a, um, you know, a C D

P style backup, if that's tape, if that's disk, if that's cloud.

But just don't tell me this thing doesn't need backup,

that just doesn't roll with me.

Right.

Um,

Right.

Can I, can I challenge

resilient, you know, go ahead.

Sure.

I, and maybe we'll talk about this when we get to a chapter.

I think we have a chapter on cloud, right?

Oh yeah, I'm

when we get there, um, one of my biggest questions is, what

about everyone who uses like Amazon s3?

Mm-hmm.

Right?

Because no one didn't, as far as I know, almost no one

backs that.

I, I, it is a problem.

It is definitely a, a thing that needs to be discussed, and it's a

thing where, Um, I firmly stand on both sides of that, of that story.

Right.

Um, that, that's a, yeah, we will definitely, um, we will definitely

talk about that concept and you will hear me waffle back and forth.

And part of it is, um, it's a little bit different in that.

The, the multiple locations and we're get, we're got the cart before the horse.

But you're deal, you, you have something that is, um, you have features that

include both protection against node and site failure and human failure.

Yep.

So if you have stuff that deals with both

of those, um, That, that's where I start to waffle a little bit.

Yeah.

And we'll get to that

at some point.

Yeah.

Well, when we get to the chapter on

And we're not, and we're not gonna solve that.

We're not gonna solve that.

That problem when we get there.

But anyway, so this is the basics.

Uh, by the way, if you, if I think that resource db-engines.com,

uh, is a great resource.

Um, and, uh, to help you understand all these different models, um, and, and to

understand which model your database that.

That you're, uh, using, um, we didn't mention Postgres, right?

Postgres is another very popular, uh, I think it's gotten a lot more

popular over the years because

what?

I was thinking like the web app development stuff.

I think they

use that a lot more.

Yeah, I, I think it's got, it's, it's, it's an open

source product that probably has the.

Like data integrity stuff built into it compared to MyQ l Um, there's complexity.

It goes with that, but I think that's, you know, that's the thing with that.

Uh, all right.

Well, uh, enough talking about databases, we will do part two coming up and talk

about how to back these things up.

Uh, that's, and that's really you.

That's really what we

The meat and

That's really what we wanna talk about.

What's that?

The meat and potatoes.

Yeah, absolutely.

All right, well, uh, thanks for, you know, the usual good

questions, et cetera, Prasanna.

try Curtis and I hope you have a wonderful rest of your Monday.

Happy 200th episode.

Happy 200th episode.

And, uh, thanks to those of you that have listened on those 200 episodes.

By the way, if you haven't listened to all 200 episodes,

you got some catching up to do.

Um, and, uh, remember to subscribe so that you can restore it all.