You found the backup wrap up your go-to podcast for all things

backup recovery and cyber recovery.

In this episode, we tackle something that a lot of backup

folks get wrong, RTO versus RPO.

You might think this is a simple topic, but I guarantee there's

more here than meets the eye.

We're going to break down why these aren't just backup metrics.

They're business decisions that should come from your stakeholders, not from it.

And if you're thinking, Curtis, how can you spend an entire

episode on these two terms?

Well stick around.

We'll show you why these two concepts drive everything from backup frequency

to the overall system design and why getting them wrong can cost your company.

Tons of money.

This is one you won't wanna miss.

By the way, if you don't know who I am, I'm w Curtis Preston, AKA, Mr.

Backup, and I've been passionate about backup and recovery for over 30 years.

Ever since.

I had to tell my boss that we had no backups of the

production database we just lost.

I don't want that to happen to you, and that's why I do this.

On this podcast, we turn unappreciated backup admins into Cyber Recovery Heroes.

This is the backup wrap up.

Welcome to the show.

If I could ask you to take just a quick second to subscribe or

follow wherever you're watching us.

Remember, you can watch us on YouTube if you wanna see

our bright and smiling faces.

Or if you think I have a face built for radio, then uh, you

can use the podcast format.

But either way, if you follow or or subscribe to us and you'll make

sure you get our great content.

Uh, I am w Curtis Preston, also known as Mr.

Backup, and I have with me a guy who, for some reason today is just a little bit too

bossy Prasanna Malaiyandi, how's it going?

Prasanna.

I am good.

I think it's also a voice made for letters.

Boy, I've never heard that one.

I've heard you got a face for radio buddy.

Um, but, uh, yeah, I've never heard voice made for letters.

You know, there, there's a guy that I know that I spent some time with actually

just last week, and he has a voice for.

Like, um, you know,

basically people are always like, you've got an amazing like, radio voice.

And he's actually, um, he's around my age, maybe even a little bit older, and

he's actually trying to become a, um, like someone who, uh, does audio books,

um, uh, amazingly, you know what his name is.

What.

His name is Will Shakespeare.

This is actually his name.

His name is Will Shakespeare.

I introduced him to another friend of mine, uh, Robert Lewis Stevenson.

And, um,

think you're totally making this up.

No, these are two people.

They're the, I, you, I can show 'em to you on Facebook.

I'm friends with Facebook.

One of 'em I know via the IT world.

The other one I know via the, um, election worker world.

So, uh, we're gonna talk about, um, for some people, you know, when

you saw the title, you're like, how can you talk about this topic for,

you know, a, a podcast episode?

And you know what, this may be one of those times where we're gonna have a 10

minute podcast, but I don't think so.

Yeah, I don't think, I don't, I don't think that has ever happened.

I don't think that will, unless like one of us, like falls ill

in the middle of a podcast.

Yeah, yeah.

We do have the ability to, to Jer Actually, I'd say more me, I

have the ability to Jer Java and you have the ability to humor me.

Um,

Yeah,

so we're talking about

They're actually earmuffs like hearing protectors, not headphones.

I'm just really good at reading lips.

I'm gonna say that this topic, there are few foundational topics

that are more important than the topic that we're talking about

Ooh, I, I,

What do you think?

I, once you introduce the topic, I'm gonna ask about the other one

that may or may not tie this one.

Okay.

I mean, there are things that are very, you know, some, some of things

like, you know, they're like all equal.

But I'll just say this, if you are not factoring in this concept, when

you are designing your backup system and when you're maintaining your

backup system, you just not doing your

job

Well, and, and I think that some people might kind of implicitly be doing some

of this without realizing it's like, you know, sometimes you do things

but you may not use the exact word.

Well, you might not use the word.

And so, so today we're gonna make sure that you know the word and, and, and it's

actually, there's actually four words.

Uh, there, there's two that we're gonna start with, and then we're

gonna add two more on top of that

Can this be like Sesame Street?

This letter is introduced by.

this episode is brought to you by the letters RT.

O and RPO.

That's what we're talking about this week, is recovery time objective

and recovery point objective.

And a lot of people, it's a little bit like, um, the effect and affect.

Uh, people always constantly miss the two.

And uh, I'm one of those people that constantly, when I.

I, I have to think twice.

Yeah.

I have to think like, is it affect?

This is the, the effect.

Um, yeah, like affect is the verb, effect is the noun.

Um, and, um, yeah.

Anyway, welcome to English, but what, why do you think, I think

RTO and RPO are so important?

Uh,

you know, when designing a backup

Because it drives everything, right?

It because it's not only understanding the requirements that are coming

from your stakeholders who hopefully you are talking to, right?

It also, uh, it helps define like what your backup system looks like,

what technologies you use, right?

All the rest of that, all because of these two key phrases.

Now I'm gonna, I'm gonna put something out there, and I'm gonna confess

that in my first several years.

Of working in the backup world.

I never once thought about RTO or RPO and, and when I say that,

I don't mean just the term.

I

mean it's like we, we really didn't, I'd say we focused a little

bit on recovery time, but very little time on the recovery point.

Right.

Um,

you go any further, can we first define what RPO and RTO

are just for our listeners?

Yeah.

Just because you're throwing out these terms and so.

And, and, and, and for those who, for those that struggle with the two.

Right.

And give you a just my, my quick, um.

Thing.

Um, and that is so recovery time objective is the goal that we've set that how

long a recovery time should take, right.

You know, um, from beginning to end, from bad thing happening, which could be

anything from, I deleted a file generally.

Generally, we're talking more about disaster recovery here than

an individual file, but it could be an individual, uh, database.

You delete one file, you take a database down.

That database is behind a really big application and poof, you know,

we're talking about RTO right?

But it's the time that we agree that a system, that it should take the, the

backup and DR system to restore the.

Thing, the entity, whatever it is that has been taken down back to

full, um, fully functional status.

How's that?

I agree with everything except that last sentence you said, and I wanna be very

careful here because a lot of people like this is called a recovery time

objective, not a restore time objective.

A lot of people in backup think it's just getting the data back,

that, well, that's why, that's why I put that

thing at the end.

Yeah.

Right, but it's not just the restore, right?

It's not just getting the data back, right?

It is

yeah.

Yeah,

that entity, which I'm glad you put the entity word right, because

it's more than just the data.

And I think that's an important concept that backup folks should understand is

you're just part of the process, right?

What you do is you're restoring the data, but there still has to

be that recovery of bringing the application back online, bringing all

the other components back up, right?

Doing, um.

Making sure that everything is good to go before you actually

bring up the application.

And all of that is encompassed in the RTO.

Yeah.

It, it, it's literally from the moment that the, the thing is damaged

to the thing is fully functional.

Yeah.

Whatever the thing was,

right?

We're talking.

We could be a data center, could be, um, a server, it could be a database, it

could be a really important file system behind, uh, you know, a database, right?

yeah.

And, but this, but, sorry, I don't mean to be pedantic, but this is

No, it's

just you two.

You mean to be pedantic, but go ahead.

So let me be, so it's really important though, because I think sometimes,

like going back to my initial point, right, that you should talk

to your stakeholders to understand the business objectives, right?

As a backup team, you are only responsible for a piece of the entire recovery.

So make sure when the business says, I have four hours to bring this application,

to recover this application, whatever it is, you're just a part of that, right?

You can't say, oh, I'm gonna take three hours and 59 minutes and I'm good,

Right.

right?

Yeah.

Because that doesn't meet the business objectives.

That's not the case.

Agreed.

So that's the recovery time objective.

And the key there is recovery time.

Right?

Just, you know, when you hear that recovery time, we're talking about the

amount of time of the recovery, right?

Um, and then the next one.

Is a little bit less obvious, I think.

Um, and that is the recovery point objective, which is the amount of data

that we've agreed we can lose as measured.

By time, right?

Um, so we agree that in a recovery we can lose one hour's worth of data, four hours

worth of data, two weeks worth of data, whatever the recovery point objective is.

That is, it's the amount of data that we have as a business.

Go into those stakeholders.

As a business, we've agreed to the amount of data that, the acceptable

amount of data loss as measured by time.

I do agree with your definition, right?

And I've always thought about it as how much data can I lose?

Right?

And it might be okay, I'm good losing 24 hours.

It's not a high I.

Change rate application or it's not a mission critical application versus

my financial database that keeps track of all my transactions that I'm

probably not good with the one day loss.

Right.

That is probably minutes.

Um, it, it's really about.

The RPO is driven by the kind of business you're in, the kind of application

that we're talking about, and it's driven by the amount of revenue that

you would lose when you lose data.

Right.

Um, and there, and, and just the, just the one key thing is that as measured by

time, it's just that normally when we talk about the amount of something in data,

we're talking about number of gigabytes or

terabytes.

In this case we're saying as measured by

time.

Right?

So three hours worth of data,

not

be a small amount or a large amount, and I think depending on the technology

you choose as well, I know you can also get down to fry fine grain, like

outstanding iOS that you are willing to lose in some of the technologies

that you could possibly use.

right.

So that's a definition of RTO and RPO.

And we, we say that this is, um, there's a lot of questions that come up here, right?

But with without those two values, we can't properly design a backup system,

right?

So here's the question.

I'm the backup guy at TI Squad company, and I need to start

designing my backup system.

What RTO and RPO should I be using?

You don't decide that

What

I am the backup guy.

I decide all things backup.

no.

Curtis, no, no, no.

Because no matter what you pick, if you don't communicate and get the

requirements from your stakeholders, I.

They'll be wrong and they will always yell at you, and it's,

they, well they'll, they'll still probably

yeah.

Well,

but, well.

so here's, so here's, here's my version of that answer, and that is, I.

Your RTO and RPO is not a backup decision,

right?

It is a business decision

yep,

and you, you,

you might not even have input on these numbers.

The, the only input you can have is, uh, I can't do that.

Well, well there, I think you have two inputs.

Mm-Hmm

One is I can't do that because it's technically impossible.

The second is I can do that and it's going to cost you a boatload of money,

Yeah, yeah,

yeah.

I think the cost is the other thing that you can come back with,

which might also sway the business.

yeah, so the first thing is that, that the RTO and RPO need to come from on high

and from, you know, side to side, right?

They need to come from you.

You've, you've brought up the word stakeholders many times.

Why don't you define what we mean when we say stakeholders?

Yeah, so stakeholders are people within your company who are either running the

application or who are in the business side who understand the risks with this

data and the importance of this data, and can help quantify how much is acceptable

as an overall company to lose, or the amount of time it takes to recover.

Yeah, and I would say that a lot of times, like, so you talked about people

that are running the application, sometimes the people running the

application don't have any more, I.

Yeah.

Knowledge than you

do.

It's really like the cu the customer of that application.

And by customer I mean the internal customer,

right?

The person who, who, whoever's making these recommendations needs to be

somebody with purse strings, right?

Um, that knows.

The, that knows the business impact of that application knows the, the, the,

the ins and outs of the business and how you make money, how you lose money.

And, um, because they need to be able to say, look, when this application is down,

we're losing a thousand dollars an hour,

whatever it is, right?

We're losing, you know, I, I, I've worked with companies that say that, that they

will lose a million dollars a minute.

Of downtime, right?

That number.

So, so the, how much money will I lose while the system is down?

That's going to drive your RTO.

Right.

If, if we're, if we're losing a, a million dollars a minute that the system is down,

that means I can spend $10 million for a system that's gonna get me back up in

five minutes because, you know, there's a

50% RTO there, or I'm sorry, RROI,

there's a 50, you know, 50% ROI there.

Um,

But on the flip side,

gotta go ahead.

but on the flip side, if you're like, Hey, I'm gonna spend $5 million on

something that's just gonna cost a thousand dollars a day, if it goes

down, uh, you're probably not gonna

You're not exactly, you're not gonna spend, you know, $5 million to get,

you know, to, to get you that system that can get you a five minute RTO.

If, uh, you know, you're, you're only gonna lose a thousand dollars a day,

right?

You're, you're just not gonna do that, right?

So, RTO and RPO, um, are agreeing on the RTO and RPO are gonna

drive, um, the cost of the system.

So, so if, if the amount of money that we lose while the system is down

drives the RTO, what drives the RPO?

How much data you can end up losing,

Yeah, I, I think I, I was asking myself the question in my

head as I was saying it.

It's, it's a difficult question because they're very similar.

Yeah.

So if, if

you're losing a a thousand dollars a minute, I.

Right.

The, if basically your company is, is, um, generating revenue

at a thousand dollars a minute.

If you lost, um, an hour's worth of data, you are going to lose

$60,000.

Yep.

Did I do that math?

Right?

Right.

If you're losing a thousand dollars a minute, your company's gonna lose

$60,000 of business that you had.

Yep.

Um, if you, if you lose an hour's worth of data.

But there's also,

in addition.

RTO also applies with

Yeah.

In addition to the amount of business that your system will or that your business

will lose, uh, either bus business that it had or business that it could have

had, also, someone needs to be able to

come up with the intangible things like damage to brand identity,

right?

Um, also.

Potential future lost data due to this is, this is primarily, well,

it's gonna drive both of them.

Because if you, if you, if you took an order from somebody and

then an order just disappears

and you don't even know who they are,

then um, you know, not only are you gonna not get that business,

you're gonna anger a customer.

Also lawsuits potentially.

And potential lawsuits.

Right?

Exactly.

Right.

That's a good point.

So you have to think about all of these different things.

This is, but again, this is what a business

does.

This is not your job as a backup and Dr person.

This is not your job.

If you're thinking, you're listening to this and you're like, gee, this

all sounds really complicated, and the big responsibility, yes.

It's why it's not yours.

Um, it's, it's the CEO, the CFO, uh, you know, a lot of

people with Cs in their names

management

and then the people that they appoint, uh, under them to, to make these decisions.

Yeah.

were saying, what would

Oh, the risk management team.

Risk management team.

Exactly right.

So if RTO and RPO drive backup design, what parts of backup

design do RTO drive and RPO drive?

So let's, let's do RTO first.

What, What, element of backup design does RTO drive?

It is how you do recoveries.

Def define how, what do, what do you mean?

All right.

Mechanisms that you use for recovering your data.

For example, do you have a standby DR.

Site available and ready?

Do you have data in a replica database?

Are you having to retrieve data from tape?

Yeah, all of these are, I was looking for something maybe a

little higher level than that.

Those are all correct answers.

Um, what I was thinking was, it's gonna deri, it's, it's going to

drive the, the, the design that determines the speed of recovery.

Yeah.

Right,

which everything you just said

determine the speed of the recovery, right?

If you have an aging system with an aging backup server and an aging, an

aging storage, and you're having to do a full recovery, uh, from older systems,

that's going to take a really long time.

But if you've got a cutting edge backup system with failover, Dr.

All of these things, um, then you should be able to do a very quick recovery.

Uh, you, well, you should be able to do a very quick restore,

which will enable to do, enable you to do a very quick recovery.

Um, so RTO primarily DR.

Drives, I'm gonna say the, the power of the backup system, the oomph, the

speed, uh, its ability to restore data quickly, which sometimes the

quickest way to restore data quickly is to restore it before you need it.

Right, and, and to, and to not restore it at all.

There are mechanisms to either restore the data before you need

it or to not restore it at all.

What would be a way to not restore it at all

Do you basically have a copy sitting there that is

or,

available

or

or a

snapshot?

Oh

I know how much you love when I bring that up.

yes.

So if,

Which is like copy sitting there.

well, it's a virtual copy,

Okay.

right?

Um, it's very important to distinguish

that, uh, at least what I would call a real snapshot is

a virtual copy.

Yes.

Um, yeah.

Um, if you're able to, if, if it's, if it's a copy just ready

to go and you're able to just.

Restore as I make quotes in the air by simply going back to an earlier

point in time, um, you are going to get a very quick RTO right?

Yes.

I just wondering also is re,

I'm wondering though if like even fast, like what's even faster than a snapshot?

I don't know what's faster than the

Because with the snapshot you still have to have someone

go and restore the snapshot.

Well,

it's, you're not really doing a restore, right?

I mean, a, a

good snapshot system.

You're just doing pointers, right?

So what do, I'm not sure what

Oh, so I'm thinking more like, um, as an example, clustered high

availability with the DR Replicated copy and automatic failover.

Yeah, yeah, that's all fine, right?

That that's all I, I don't know if that's faster than a snapshot, but

it's very similar.

Basically, you have stuff that's, it's immediately, immediately,

available and ready to go, right?

So there are a number of ways that you can, number of ways

from, from days to seconds.

To, to meet different levels of RTO based on, um, based on what you're

willing to spend and how you're willing to design your backup system.

Right?

Can I bring up a story?

sure.

So I was listening to a podcast on my walk, and it's of this automotive company.

They sell bolts and nuts,

Okay.

right?

Um, and they were talking about how they were, they were a small shop

and they have like 30 people now.

And the guy, the co-founder or the CEO founder, he basically ran it.

And they had a bunch of systems and things like that, and he

was kind of managing everything.

And then they got hit with, uh, ransomware

Yeah.

and they lost all their data.

And then he realized he had a backup, but it was from three months ago.

Right?

So his RPO was three months,

Nice.

Well.

RPO.

No, his RPO never changed his RPA.

We haven't got to that

yet.

Yet.

Well that's what he had.

Yes.

And he basically said though, so they had a bunch of invoices and customers and

luckily they had everything hard copy.

He said it took them six months to manually enter, to manually enter

all the transactions that they were missing before those three months.

At least he was able to get, uh, to put that data back,

right.

Yeah.

Uh, by the way, this, this is just as good a time as any to bring up the

terms RPA and our, our RTA and RPA.

So recovery time actual and recovery point actual.

So a lot of people say, you know, and I do it, I do it occasionally,

so it's not like I'm, I'm

calling outy or Prasanna.

Um, we say, oh, we, you know, we recovered it in two hours.

So we had a two hour RTO.

The So recovery, it's recovery point objective, recovery time objective.

This is the goal.

This is the service level agreement, right?

The

SLA,

Oh.

So I guess in my, in that example case, they had no agreement because they did

yeah, that.

That's actually the most

common.

That's the most common, right?

No, no.

SLA, no, R-G-O-R-P-O.

We just do our best case and, um.

But how, how fast the system is actually able to do something is your RTA and RPA.

Right.

Your recovery to recovery time.

Actual and recovery point actual, uh, I've also in, in various times in my

career, referred to that as the RTR and R-T-R-P-R recovery time reality.

Yeah.

Um,

but

that?

How do you actually

figure out

the only way to calculate is to actually do it right.

So hopefully everyone is doing restore testing

or recovery

story testing is the only way to know for re for sure.

All right, so let's talk about, you talked about how, what, uh, aspects of

backup design are determined by RTO.

What this answer is much easier.

What aspect of backup design is determined or is Yes, is determined by RPO?

How frequently can you back up your data?

Yeah.

So if you're backing up your data more often, you are going

to have a better RPA, right?

Um, so if you have, if, what's the most common, uh, backup

frequency, would you say?

Probably once a day.

Once a day.

And so the most common RPA is at minimum 24 hours.

Well, the, the, you know, there are situations where

you might get better than that

if you, like you said earlier, if you had a failure right after

you just finished a backup,

but worst

um, you might, that's best case

scenario, worst case scenario.

Is more like 36 hours because you're, you're, you know, at the end of a

day before the, you know, and, um.

The, and, and that, that's assuming that last night's backup worked,

and I've done enough backups to know that that isn't always the case.

And I would also say I would apply Murphy's Law of backups, which is the

the degree to which, you know, a ba the, the, the possibility that a backup is

successful is inversely proportional to, um, how, how much you need that backup.

Yeah.

Is there also a Schrodinger's cat for backups?

Yeah.

Yeah,

exist, or you don't know if a backup exists or not until you actually,

Until you actually look at it.

yeah,

Um,

I think we need that on a T-shirt.

By the way, if you would buy a T-shirt from

the backup wrap up, right, with these phrases on it.

Let Curtis know on X or LinkedIn or somewhere, or leave a

Yeah,

on YouTube.

We've been getting a lot of YouTube comments lately.

Um, yeah, let me know on YouTube, by the way, did I tell you, you know

how it's how back when I was not feeling well or I hurt myself and

I said, no one cares.

Then I said, if anyone cares, please say something.

We got comments.

One of,

you know what?

One of them said,

What?

India cares about Curtis.

Aw.

That's what I got.

Um, so.

Yeah, so RPO basically determines your backup frequency.

If, if you've got an RPO measured in hours, you can't have a backup frequency

measured in, in, you know, many hours.

Right?

Um, and the, um, I, I will say that,

just talk about the different ways that people do backups, sort of normal.

Regular, what I would call full file incremental backups.

Pretty much the best you're gonna be able to do is daily.

Right.

If you're able to do some type of block level incremental forever,

where each backup, you're only backing up the blocks that have changed,

or even better, the deduplicated blocks that have changed, right?

Because that's gonna be an even smaller, uh, set of data.

Then you could actually do the ba It does two things.

One is it makes the, it makes the backup.

Quicker, which is good.

Um, which generally means that you can do it more often, uh, and then it, it

does allow you, it also reduces the, the impact of the backup, meaning that while

the backup is running, it's not having too much of a, of an impact on production.

And so that allows you to do it more often.

To do it, you know, once an hour is very common.

Uh, if you've got a, a modern backup system, you could do it once an

hour or even more often than that.

I.

Yeah.

While you're mentioning this about the incrementals and chain block tracking,

one thing I realized we didn't cover is depending on what technologies you use,

it will have an impact on your RTO because if you have say, multiple, uh, recovery

points, you have to recover from first before you can get to that final point.

Like if you have to recover a full plus multiple incrementals.

That is going to take you more time, which will impact your RTO as well.

Absolutely.

Um, I do want to talk, so what we'll round out this discussion with is that

idea that you brought up earlier, which

is the,

that, um, every stakeholder is gonna want an RTO and an RPO of zero.

Because if you ask people, if you ask it like this, how much data.

You know, how, how long are we allowed to be down and how much

data are we allowed to lose?

And the answer is zero and zero.

Yep.

How do we get from there to something that's more reasonable and possible?

$1 billion.

Yeah.

What, so yeah, so you go back, you're like, okay, all right.

We've taken the requirements, we've gone and we've met with the powers

that be, and we've decided that if we go with a fully redundant system.

Uh, with, you know, with, with, uh, synchronous replication and a hot site

that's, you know, this far away we can do, we can give you the RTO and an RPO of

zero and it's going to cost $1 billion.

Right.

And you do that with a straight face, right?

You just go, okay, okay, we got, you know, we got a thing, we got a thing, we got the

vendor, we got this vendor standing by to

take your check.

And uh, we can do it for $1 billion.

And then, um, um.

What I generally find is at that point, obviously I have a Plan B and a plan C,

and uh, I've also consulted with this vendor.

And this vendor says that they can do an RTO and an RPO of

four hours for only $1 million.

$1 million.

Sounds a lot.

Sounds like a lot,

but it's a better than a billion.

it to $1

So, so here's a question.

So as a backup admin, when you're going to these discussions with the stakeholders,

Mm-Hmm.

is it.

Worthwhile to go with a couple options, like you mentioned where you're like,

and what would those common options be?

Right.

Do you think it's zero?

Zero, right?

It's a four hour RPO.

Maybe it's a one day RPO.

Like

Yeah.

Um,

what?

What would make sense?

Yeah.

I think it's going to be driven.

Most backup designs.

In fact, I'm gonna say all backup designs are driven by cost and reality,

right?

So, you know, they want zero and zero.

Or let's say, let's say they want 15 minutes.

We're like, look, we can do 15 minutes, 15 minutes costs this much.

This is the way to do it.

Um, if they, if they say.

We wanna, we wanna, you know, a very tight RTO, but we're okay with

an hour's loss, data loss, right?

Snapshots and replication.

Great way to do that.

If they want very, you know, like as close to zero as possible, you've really

got to do CDP or something like it.

You gotta do synchronous replication.

And by the way, it's important to mention here that not everything has

to have the same RTO and RPO in fact.

In your environment?

Everything should in your environment, everything should definitely not have the

same RTO and RPO.

If that's the case, it means you've sort of settled you.

You've definitely got an application that needs more than that.

Uh, and you settled for simplicity, which is very common for people to do, but

that's not really the right thing to do.

You've got one or two applications within your environment that would really lose

a lot of money, and it's totally okay to have a different backup design for them.

Right.

You have the gold, silver, bronze, right?

Um, I, I definitely like, go ahead.

W, and I know you mentioned backup technology, like a different backup

technology that might also drive having different backup vendors as

well to satisfy these different needs.

Yes, it definitely will be.

I mean, my, as a

backup person, my preference is always one vendor if possible.

Um, and, um, you know, one design with options, uh,

because again, simplicity, um,

means recovery, I think.

Um, but.

but.

yeah, it, it is really important to understand that it's very common

for you to have multiple RTOs and RPOs within an environment.

I will also state, and this is somewhat controversial and not

everybody agrees with me here, it's also okay to have different RTOs

and RPOs based on scenario, right?

Like if we've got, um, if a server died or a server caught on fire or a server

got whatever, you know, server goes, poof.

seems to me that that, that, that RTO and RPO, um, would be

much, much shorter than if an asteroid hit Oceanside, right?

Um,

it's just there are different levels of disasters and there's different amounts

of understanding that you can have.

So

I think it's totally okay to have different kinds of RTOs

and RPOs for different kinds of

and, and I think this is where we kind of like from talking to Mike

about our ransomware recovery and other things like that, right?

I think this is where sort of the incident response plans come in, right?

Where different scenarios you may have different RTOs and RPOs.

Because they are different and there are things that are outside of your

control, like recovering from ransomware is very different because of the initial

steps you have to do to isolate and figure out what's going on, rather

than, oh, this server, the disc died.

Now I need to recover.

Or someone accidentally deleted a file.

Yeah.

And by the way, you know, speaking of recovering from ransomware, you know

when, when we've talked about that, when you get to the actual recovery, it's

very common for a person who knows what they're talking about in that world.

Say, listen, I want you to, you might be recovering the same data set 50 different

times from 50 different data points.

That's something you really gotta figure out in your backup design.

Right.

Because there are backup designs where that is not gonna happen anytime soon.

Right.

Um, but, uh, well, hey, once again, uh, we did not do a 10 minute episode.

Yay.

And we're all alive.

But hold on.

So going back to my initial question I had, or which is, I know you said RTO

and RPO are probably the most important things, foundational things in backup

yeah,

system design.

What did you think?

Do you think that second from that would be the 3, 2, 1 rule?

Well, the 3, 2, 1 rule is, um,

it is also foundational, right?

Um,

and.

I, again, is it more important?

Is it if you don't, if you don't follow the 3, 2, 1 rule and all your backups

are all in the same place as the production, why are they're not even

Back up.

Yep.

Yeah.

Agreed.

Maybe next episode, should we, we should dive down into 3, 2, 1 rule.

We haven't done that in a while.

Yep.

All right.

Prasanna, bossy mc.

Bossy

man.

Um.

my bossy pants,

I.

I hope you folks have enjoyed our episode this week on RTO versus RPO.

That is a wrap.

The backup wrap up is written, recorded and produced by me w Curtis Preston.

If you need backup or Dr.

Consulting content generation or expert witness work,

check out backup central.com.

You can also find links from my O'Reilly Books on the same website.

Remember, this is an independent podcast and any opinions that you

hear are those of the speaker.

And not necessarily an employer.

Thanks for listening.