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

backup recovery and cyber recovery.

In this episode, we cover something that should be required listening for

anybody responsible for protecting business data, the 10 essential features.

Every backup system needs.

There's way too many companies that think they have backups when they really don't.

And by the way, when I say backup system, I mean the overall system,

not just a computer system.

Because many times, um, you know, backups are actually SaaS based

and things like that, right?

Remember, no one cares if you can backup only if you can restore.

Let's make sure that your backup system has at least these 10 things

that you need to get started.

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 there were no backups of the production

database that we had 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.

Hi, I am w Curtis Preston, AKA, Mr. Backup, and I have with me a guy

who remembers to wear this shirt that I'm supposed to be wearing.

Prasanna, Molly, how's it going?

Prana?

Oh my gosh.

Are you in my head?

I literally was just thinking about that as I was looking.

I was like, why does he

I'm in your head.

I'm in your head.

Yeah, I, I, um, I, you know what?

I'm not even sure I know where the shirt is.

Oh,

Um, I dunno if you know this, I can be a little bit disorganized sometimes.

You really?

I know that comes as a great surprise.

But, um, we went through all this thing to get the shirts

Uh, by the way, for the listeners, I was asking Curtis for four years

Yeah,

to get swag to print

Yeah, we finally got his shirt.

And he's wearing it.

Both of us need to put our mic in a different place though, so that you're,

see

so that you don't cover up the Yeah.

Um, by the way, no one has, no one has reached out to me for swag.

Listeners, if you want t-shirts, if you want something, please reach

out to Curtis and let him know because I would like some more swag.

Yeah.

Do a backup, wrap up socks.

Yes.

Actually I should say merch, not swag.

Yeah.

Merch.

Yeah.

Swag is, yeah, merch is, you gotta buy it.

Yes.

the difference.

We're not giving away free stuff over here, people.

Um, all right.

We're gonna cover a lot in this episode, so we're gonna cover it pretty high level.

Uh, but we're gonna talk about the 10 backup.

Things that every business needs,

Could we

right?

facts?

What

Fast facts.

fast facts?

Yeah, fast facts.

The 10 backup things that every, uh, business needs.

And the first one.

3, 2, 1. The 3, 2, 1 rule, which we've already, which, yeah, which we covered

in the last episode, which is now really the 3, 2, 1, 1 0 rule, right?

Three copies of your backup, two different media, one of which is somewhere else,

one of which is immutable and zero errors because you did validation, uh, which

actually is gonna be another one of our, another one of our things, right?

So if, if your backups don't conform at least to the 3, 2, 1 rule, then

you know they're not really backups.

Yeah, exactly right.

Um, so the, the next thing is, uh, scheduled backups.

So why, why does that matter?

Prasanna?

Well, if you aren't doing frequent backups or scheduled backups, then

you're probably avoiding or skipping or don't have a backup you can

restore from, and you're probably not meeting the needs of the business.

So you wanted a

schedule.

You don't wanna have to go push a button, right?

It should run automatically based on what you and the business have decided.

Yeah, if you're not doing scheduled backups, you're not really doing backups.

Right.

Um, you know, you're, you're gonna, you're gonna have, you're

gonna have to remember to do them.

And so they should, they should just run right.

Get, get humans out of the system as much as possible.

So if you're not doing regularly scheduled backups, then again, I, I, I

don't, I don't even know why we're here.

Well, I, I think it's also important, automated is another key word there,

Yeah.

right?

It should not be because I, for instance, do scheduled backups of my

personal data, but it's me doing that manually every day or every month.

That, that's actually a really good point, right?

I'm glad you brought that up.

It needs to be automatically scheduled backups right.

Um, and, uh, yeah, this should happen.

And when we talk about, um, uh, another thing that we need to be doing all the

time, that is a little thing called, uh, recovery testing or backup testing,

backup testing, or recovery testing.

I guess the only reason, the only reason we back up is so we can restore.

No, I, you know, I, I used to say a lot.

No one cares if you can back up.

They only care if you can restore.

Yep, and you need to make sure you're doing your recovery testing

because you don't know if that backup is going to be successfully

restored when you actually need it.

The only way you know ahead of time is you have to do your testing.

You might have forgotten to do part of an application backup.

You might have forgotten a piece of your infrastructure.

You need to back up as well in order to successfully restore down the road.

The only way you know is you do the testing ahead of time.

Yeah, exactly.

And um, you know, I can think, I can think back in the day when, um, I

remember I was at a, uh, a large, uh.

Cell phone manufacturing company, and we'd been bagging it for months.

And then we went to go do a recovery test.

Uh, we found out that the tape drives, uh, they weren't so good at reading,

they just, they just knew how to write.

Um, you know, you can't, unless you do the, the recovery testing,

you're not gonna find that stuff out.

Right.

There's just, we, we could, we could, we could spend.

Hours and hours and hours telling you stories of bad things that happened.

When you don't do testing, you're, you're only going to find out, uh,

you know the, what's wrong, right?

think you did talk about this a few episodes ago, but your about

how there was a new compression

Yeah.

The compression feature.

Yeah.

We didn't, yeah.

never tested it, and your

Yeah.

from tape was slow.

Yeah, it was ultra slow and ultimately we found out that it actually

wouldn't even work because of the way that the feature, uh, worked.

It was, it was assumptions made, um, that, that were just not true.

yeah,

It was a really bad design, but, uh, again, you're not gonna know that stuff

until you actually do, uh, testing.

So the next one is going back to what I talked about earlier about why you

needed sort of automated schedules, backup schedules, is you need to

also define your recovery objectives.

Yeah.

And do you wanna talk a little bit about that?

Because I know people forget about this or they think, oh, as a backup

admin, I'm responsible for this.

But I think it's important to sort of like really talk about this.

Yeah, this is one of those things where you cannot, you, you really

cannot design a backup system.

Without recovery objectives, right.

I mean, you can, right?

You can just, you can define, you know, but, but it's like, um, you,

you, you really have to define the recovery objectives upfront.

And if you don't define them upfront and you don't agree to them upfront, then you

can't properly design the backup system.

You.

And, and, and so you end up sort of just doing what we always do, which is

like, oh, we're gonna do, we're gonna do it and we're gonna recover every day.

We're gonna bring, you know, gonna back up every day.

We're gonna, we're gonna send it off site and we're gonna do the thing.

And then you go to do the restore and then you, you, you, you go to do, um,

the restore it and, and it works, but it fails from a perception standpoint.

And that's because if you don't have recovery objectives.

The, the recovery objectives that are in the mind of the bosses are going

to be very different than the recovery objectives that are in your mind.

You're like, Hey, this was awesome.

The restore happened.

Uh, it, you know, it, it only took, uh, eight hours and, you

know, and, and it, and it succeeded and we restored all the data.

And you're like, you're feeling, you know, hunky dory and then the bosses

are chewing you out because they thought it was gonna take an hour.

Yeah.

And I think one other thing I want to touch on is as a backup

admin, I the one who's coming up with these recovery objectives, or

New.

Yeah, good point.

Yeah.

The, it needs to come from the business, right?

Any of this, these SLAs, recovery objectives, need

to start with the business.

We want, we, we don't wanna lose any data and we don't wanna lose any time, right?

So that's, that's where we always start, right?

A RTO and an RPO of of zero.

That's recovery time objective and, and recovery point objective of zero.

And then you need to walk that back based on, okay, you can have an RTO and RPO of

zero, it's gonna cost you $50 billion.

Uh, and then, you know, and then they walk it back, right?

So you, again, you, this is about setting expectations.

And also using those, those objectives to both define and design the backup

system, but also to pay for it,

Yeah,

right?

Because, um, you know, it, it, uh,

it's really hard to get money for backups.

and we talked about this I think like three episodes ago.

Yes, we did.

Yes, we did.

Um, so the next is about isolating, uh, you know, backups

from a security perspective.

And we did just talk about this with the 3 2, 1, 1 0 episode.

We talked about immutable backups.

Uh, there there is a term that we didn't talk about, which is another

really important term when we talk about, uh, isolating backups.

You know what that term is, right?

The

least privilege.

Access

No,

patch management.

no.

MFA.

Keeping back up secure.

Oh

I know it there.

There's like eight, 800 things you could be choosing.

Air gap.

Yeah.

But of course, and, and again and again, air gap backups, we can't really

have air gap backups it in the truest sense, uh, because that technically

means that it's offline and it's, it's, there is literally a gap of air.

There is no connectivity from A to B.

Uh, you can't really have that with modern backup and recovery design,

but you can just have, you can.

Approximate it as much as you can.

Right?

Again, just realize that from a cyber cybersecurity perspective, um, that

the threat actors are immediately gonna go after your backups, right?

And so you gotta separate them.

I.

So I was also thinking when you brought up this, uh, topic, was

thinking from sort of separating out, I know we talked about, active

directory, so sort of having something separate from a backup perspective

Yep.

as network isolation if needed.

So you're isolating your backup traffic from your production

traffic, just keeping it isolated, walled off from everything else.

So if something happens on your production network, it's not easy

to get into your backup network.

Yeah, and the thing you mentioned earlier, uh, and your incorrect

answer to my question, it's, um, least, least privilege, right?

Using the concept of least privilege, give, giving each person the, the,

the absolute least, least amount of privilege that they need in order to

do their job in the backup system.

Uh, and then isolating it, uh, as much as you can.

Uh, encrypting backups also, right?

Uh, in case somebody gets to them from via some other source.

Because remember, backups, they're not only used as a way to, uh, to restore,

but, uh, a threat actor can use them as a way to exfiltrate data from your

environment, which is, uh, very, very bad.

So the next one.

Yay.

My turn is SaaS backups.

Right.

Make sure that

SAS needs backups.

Huh?

No.

If you haven't listened to our last episode, you should go

listen to that on 3 2 1 1 0.

Yeah.

SaaS needs backups, so make sure you are backing up your SaaS applications.

Don't just trust the vendor that they are going to be doing your backups or

Yeah.

backup.

Because again, if you, if you just listened to our previous episode,

they're not backing up your data.

There.

There are some vendors, uh, Microsoft 365, uh, Salesforce that do offer a

backup service that you pay extra for.

That is different.

And, and I don't want to criticize any of those specifically, um, because I don't,

I don't know anything about the specific.

The specifics of those products.

What I will say is just me personally, I would rather have the data on a third

party service rather than as part of the, you know, that And can you think of

a company of why I might feel that way?

I

The company,

of a story of a cloud event that we covered

there were many cloud events we covered.

I am just

specifically where the vendor had the copy of the data.

Co-located with the data

Oh yes.

OVH.

OVH.

Yeah.

Yeah.

right.

know, go look.

You know this, this was a company that had made a number of very bad

decisions, and since they were.

Bad at making, they would argue that, look, we were doing a budget

service and this is, we made budget decisions based on the fact that it

was a budget service and I don't care.

Right.

My point is they made a number of bad design decisions, and

though they made, also made bad design decisions on the backup.

And so that's where I was like, if it's a company that messes up, you want a

backup that's from somebody that didn't mess up, and so that's why I would rather

have the backup be with another company.

Yep.

Um, yeah, let's talk about documentation.

No, no one likes documentation,

No one likes documentation, right?

Um, and, and the big thing here, I mean, you, you need to, you need to.

Be able to describe how the different parts work.

The real, the real thing here is the concept of runbook, right?

And that that should be part of your disaster recovery plan, which is

part of your cyber recovery plan.

Um, part of your incident recovery plan.

Uh, that, that a person, again, this is a high bar to set, but a person

that is technical and understands.

What buttons are right, um, should be able to follow your

runbook and do and do the thing.

Yeah.

shouldn't need the backup person or the DR person to be the one running the recovery.

It should be somebody that, that is competent should be able to look at it.

Uh, and also there should be.

Uh, some sort of, um, identity management system that would allow this person

to then get into the, the places that they need to get into as well.

I was thinking about the hurricane that hit a tropical island.

Yeah.

Story.

And in that story, go back and listen to the episodes.

Basically, hurricane hit an island wiped out the connectivity to the mainland.

They needed to restore the data, but all the active directory and

identity systems were in the mainland, so they couldn't restore the data.

to fly people from the mainland back to the island in order to be able to

actually do the restore and great story, go back and listen to the episode.

The interesting thing though, Curtis,

I thought what they did was actually they had to get connectivity back to the, I

thought that's what they did, so that the

but I think they had to actually do,

I, well, I know they, I know they flew people.

I just, I think in order for it to work at all, I think they had to get, they

used satellite connectivity to get access to the internet so that they could then.

Access that, the, the thing on the mainline, I thought that's what happened.

It's been a while since I

a copy of the active directory

did.

They,

or

that's highly possible.

Maybe I should go listen to the My own, my own

But

episode.

is where

I.

important that there are certain scenarios that local backup folks who are managing

the site may not be able to handle.

And so it is okay if needed to bring in specialists to

deal with certain scenarios.

Which again is why you want to have documented procedures and runbooks

so that those specialists can, uh, can follow them and get stuff done.

So next on our list is retention policies.

What are retention policies, Curtis, and why do, like, don't

we just keep data forever?

Come on.

Storage is cheap.

I have been at clients that kept data forever.

In fact, I remember one, it was a financial firm in, uh, New York City

and they had a forever data retention policy, and they were very proud in

talking about the number of features and ways in which things had to be

added to, uh, Veritas net backup.

Just because of them.

They were very ex.

you should be proud of.

Yeah.

Right.

Uh, d data retention should not be too short.

I, I've, I've seen that, that's, I've seen on that end, uh, you

know, the, the crazy end of forever.

I also knew one of the friends of the pod, uh, Stuart Little,

uh, he worked at a company where, uh, he was, they were a client of

mine and the boss there had this.

Like total opposite opinion, which was two weeks.

His retention period for all backups was two weeks.

This hurt my little backup heart, right?

Because I can think of so many scenarios where two weeks is not enough, but he,

he was just very adamant to not, um, have backups subject to like e-discovery

Yeah,

and so.

sense,

Yeah, it makes sense that that was why, but I, I just

felt two weeks was excessive.

So somewhere between two weeks and infinity, you should be defining

what your retention periods are.

But I think one thing to mention is not all your data has to

have the same retention period.

there's two things we need to talk about here.

That's one of 'em, right?

Why?

Why don't, why didn't it have all the anger retention?

Because some data you don't want to keep for long period of times, other data for

compliance reasons or other purposes, you have to keep for a long period of time.

It doesn't make sense to keep all the data for the longest period of time.

You have to keep data for.

Right.

And, and all data's not created equal.

You don't back it up at the same frequency.

You don't back it up at the same retention.

Uh, there are, there is data that is.

Uh, of, of high risk, sorry.

There is data of high risk in terms of high risk of

lawsuits and things like that.

Uh, the longer you keep data, the more data that you might be

required to, uh, provide in some sort of, uh, e-discovery situation.

it's also just cost too, right?

kept everything forever, your costs are going to skyrocket

from a backup perspective.

Yes.

I don't care what method you're using to store your data,

you're paying by the gigabyte.

In some way, shape, or form, right?

And so if you store everything, then, then, you know, um, your, your,

your costs are gonna be significant.

Uh, so that, that's one thing that you need to keep in mind is that not

all data needs to be, uh, stored the same amount of time, and you should

be, do you know, you should be doing it based on the, the data type and the

risks and all of these things, right?

The other is that you should not be deciding this, just like recovery times.

Uh, you should not be deciding retention periods.

This, this should absolutely not be a decision that, that the backup

person is making, and it, it, it shouldn't be a technical person at all.

This, this is a business discussion based on, uh, compliance, based on

legal liabilities, based on costs.

These are all business decisions that should not be

coming from the backup admin.

It should be coming from, uh, you know, the people with the purse strings.

Yes, but if you're being told, go back up this data and it doesn't have a retention

period, I think it is up to the backup, a admin to say, Hey, I don't see information

I need in order to be able to do my job.

Can you please tell me what the retention period is for this data?

Right.

Yeah.

I would, I would say in the absence of being given that I would, I would

set the retention period to like seven years and then go back to them and say,

Hey, I've set this for seven years.

You might want to, you know, let me know.

No,

You know, something less than that.

Right.

Uh, the next is, and again, some people when we talk about 3, 2, 1,

1 0, and I say, well, you know, this is sort of what defines a backup.

Other people feel that without what we're about to talk about, again,

you don't have backups, and that is monitoring and alerting, right?

So.

If you're not, you know, we talked about you should have a, a regular

backup schedule, you should have defined recovery objectives.

You should also have a system through which you know that the backups are doing

the things that they're supposed to do.

I

Right?

Curtis a months ago.

It should be fine running

Yeah.

right.

This is definitely not set it and forget it.

I will say that.

Right.

Um, I I will, I'll tell, I'll tell a funny story.

Um, we.

Back before you, you know, it was a lot hard.

It, it was, it was just hard to get centralized backup reporting back when

I was doing this like 30 years ago.

And we actually wrote Custom Pearl Code that went and grabbed a bunch of

backup statuses, um, and created a web based, uh, reporting system for, in

this case it was net backup and, um.

Again, I'm just gonna say this is, mind you, this was a long time ago.

in the day.

Uh, and, and I, and I, I did what I was told, but they asked, uh, for a,

what we called management view feature.

And so that was if you went and you, you like pushed this button,

all the backups, uh, went green.

So, so in case management was stuck, so we had like the regular view,

which is our view, and it would show you like each, each backup.

And then there were like, it was like a week of little green boxes,

and then you, you could see the red boxes and then, you know, you could

see that, you know, there were, there was red or green after the red.

And, um, but yeah, they, they, they asked for a feature where you could

push a button and, uh, it made it look all better for, for management.

Oh boy.

and so that, that's, that's monitoring and then also alerting is like,

you know, backup failures, things like a, a, a good modern system.

You should be able to define your recovery objectives, and then it

should tell you if you're unable to meet your recovery objectives, right?

If you're unable to be, if you say you have a a four hour RTO.

But you're not even able to complete backups within four hours.

This is a problem.

If you say you have a four hour RPO and you're not backing up at least

every four hours, then you're gonna have, you're not compliant to the, the

objectives that you have specified.

Also from a monitoring and alerting perspective, one of

the things with ransomware

mm-hmm.

in encrypts data.

When it

Yep.

encrypts data, you're gonna end up with larger backups than normal.

Yep.

you have monitoring and alerting in place, maybe it could detect

anomalies and say, Hey, by the way,

Yes.

all of a sudden your 10 gigabyte backup turned out to be one terabyte.

What's going on?

Yep.

Uh, and, and the other thing also it that, that's a great, that's

a great, uh, recommendation.

The other also is of course, that you're running out of storage,

Yeah.

right.

This is a problem.

Right.

And I'll also say that a lot of.

Reporting systems.

They're really good on reporting what happened.

They're not so good sometimes at reporting what didn't happen.

There needs to be some aspect of your reporting system so that

you can check the total inventory against the total backup inventory.

Again, a compliance check to see that every, uh, system, uh, is

automatically included in the backups.

Yep.

and how are we doing on time?

I think

Yeah, yeah.

We're good.

Yeah.

VMware and other

Yes,

make that easier because they do provide that inventory to the backup system

yes,

But

yes,

when you have physical systems, when you have SaaS applications,

other things like that, it may be a little bit more difficult.

absolutely.

And so wrapping this up, we have endpoint, uh, device protection.

A lot of times on this podcast or what a lot of people think about,

it's like their database applications or virtualization environment.

But have a lot of endpoints out there that you need to be protecting as well.

And Curtis, I know you've brought up sort of cybersecurity.

Do you want to talk about some of the issues that come up in endpoints?

Yeah, well the, you know, basically you have this incredibly powerful thing

in your hand that has access, right?

And, and also.

When we talk about things like, uh, biometric access and all

that sort of stuff, right?

You, you have all of that.

Everything is relying on this device, right?

And also perhaps your laptop.

those

Oh, thank for the thank you.

Uh, and then also your laptop.

Like my laptop has touch, ID built into it, right?

Um, so it's an incredibly powerful device, but, and also it's a device.

Upon which we rely so much.

Right?

And so you need a system through which you can recover that device if it

goes, uh, if things go poorly, right?

And whether it's, it's, it's, it's hacked.

Um, it, or you just drop it, you know, in a sink somewhere, right?

Shut up.

I know.

Shut up, shut up.

I know what you're talking about.

Um, and, um.

If you do something stupid, you know what?

You know, when I cracked, when I cracked my screen, uh, several years ago, I went,

I went and got it repaired and, and then while walking to my car from the screen

repair place, I, I tripped and I literally fell onto my phone and I cracked the

screen again and I just had to go back.

Um,

Curtis.

Hmm.

yeah, that sucks.

Um, but anyway.

The question you should ask yourself as to whether or not you need to

do endpoint backup as whether or not your endpoint has data on it.

Right?

Data that only resides there, right?

If you're, if you're using, if you're using an iPhone or an Android.

And that's what we're talking about from an endpoint perspective.

And you're just using Google Photos or, uh, you know, iPhoto, and that's what

we're talking about that is generally synchronized up to the cloud, right?

Yeah.

Um, but if you're using a third party app to do photos of your job sites,

because there are third party apps that do photos of your job sites.

Where, where are those photos are?

Are they only on the phone?

Are they synchronized up to the cloud?

Uh, is there a system by which you can find out that all of the,

that synchronization is working

Yeah.

you don't find out too late that these really important job site

photos were only on Steve's phone and now Steve's phone just got ran

over by a truck because Steve got ran over by a truck and, uh, poor Steve.

Yes.

Poor Steve.

Right.

So that's the question.

If you have endpoint devices where data is being created on those endpoint

devices as opposed to just using them.

So 99% of what I do, al almost a hundred percent of what I do really is

In

I'm using a, some cloud service.

To do the thing, like right now we're using a cloud service to record this data.

The, this, this recording until I edit it, it only sits in this, um,

you know, this little cloud service.

It's not, I'll just tell you that right now.

The, the, during the interim, if we would be like, uh, we

would be like, uh, those guys.

What were those guys?

The, the, the storage container, uh, people, the life uncontained.

Oh, yes.

Yeah, we would be like dim, uh, we would lose, we, we would

lose a couple of episodes.

I think, uh, if, if squad cast decided to, to go tango uniform, but what I

was saying was that I use this and then I'm gonna use, I'm gonna use uh

uh, descrip, which is gonna pull this over to Descrip and it's gonna edit it.

And that happens in the cloud.

There is a cloud, there is a local copy of Descrip.

It runs on my laptop, but that's just, um.

Like a cash

You it, it's a cash copy, right?

So if that's the way you're dealing with stuff, then you don't really

have to worry that much about endpoint device Pro, you know, backup.

Yeah.

You need to worry about it from a device protection and data protection

standpoint to to access to those systems because they could be used

to access the, your critical data.

But you don't.

If you're not creating data and storing data on that endpoint, then

you don't have to worry about it.

But if you are, then you should.

Yeah.

Well, and also everything you've mentioned I agree with only

applies to backing up the data.

It has nothing to do with endpoint device or detection and response EDR tools and

right,

right?

right.

That's

Yeah.

that you still probably need, even if you are using a hundred percent

cloud services, because those endpoint devices are a gateway to your network.

Yeah.

So yeah, EDR tools, uh, which again, we discuss in the

ransomware book, uh, learning, ransomware response and recovery.

Those are, they're, they're the canary in the coal mine, right?

They, you most likely will be getting ransomware via an endpoint.

So having EDR on your is a great way to find that before it becomes a problem.

So.

I wonder what other countries use instead of canary in a coal mine.

Are we the only country with coal mines?

We're not the only country with coal mines.

You just, maybe we don't have the, they, they don't have the,

um, surely they also used canary.

What is a canary?

Why do we say canary in a coal mine?

Do you, do you, do you know the etymology of that, right?

miners used to take canaries in with them, and therefore, if oxygen was.

Running out or whatever else.

If there was an

Yeah.

they were about to pass out, then the canary would pass out first or die,

Yeah.

therefore they knew there wasn't enough oxygen, so then

Time to get out.

Exactly.

Um, I just had a memory of, um, Zoolander when Zoolander, he was,

he was, when he worked in the coal mines that he came out like one day.

He goes, I think I got the black lung.

Love, love that movie.

Alright, well there you go.

10 backup elements that you need to have in any company.

Right?

Let's just review 'em again, the 3, 2, 1 rule, the regular backup schedule,

backup testing, and verification, defined recovery objectives.

Backup security and isolation, SaaS backup, uh, documentation

and runbooks, uh, retention policies, monitoring and alerting.

And finally, endpoint backup.

Uh, this is good.

I like this episode.

I like, you know, episodes with lists, fast facts.

All right, thanks.

Prasanna for being my canary in a co

or bird brain being my bird brain.

anytime, Curtis, for you.

All right.

And, uh, thanks to everyone listening, uh, that is a wrap.