Imagine this.

You're in the middle of a really important conversation in Microsoft teams.

You spend several minutes typing up a response that

will finally make your point.

But the moment you hit enter the message disappears.

And it turns out.

So did everyone else's responses?

Then you find out that every single conversation in Microsoft, 365 is gone.

That's what happened to 145,000 KPMG employees, right in

the middle of the pandemic.

The Microsoft 365 admin was trying to delete a single user's chats

when they actually deleted the entire company's data instead.

And today's episode, we'll dive right into this jaw-dropping data disaster

and see how it serves as a powerful reminder of the importance of backing

up your cloud and SAS environments.

We'll be discussing how Microsoft retention policies are not backups.

This story proved my point.

This episode is the latest in a series of cloud disasters.

Companies that lost everything because they misunderstood

how backups work in the cloud.

We've already covered some major cloud vendors like AWS, Google, and OVH.

Now it's, Microsoft's turned.

If you hear this story and still think you don't need to back up Microsoft 365.

I just don't know what to say.

Hi, I'm W, Curtis Preston.

AKA Mr.

Backup.

30 years ago, my employer lost their purchasing database.

When it turned out, my backups were broken.

I vowed that would never happen to me again.

And now I try to do the same for those who read my books and listen to my podcast.

I want to turn you the unappreciated backup admin into a cyber recovery hero.

This is the backup wrap up.

W. Curtis Preston: Welcome to the show.

I'm your host, w Curtis Preston, AKA, Mr.

Backup, and with me, I have what I hope to be.

My personal non-ad advisor on taxes

Is it that time of year, Curtis?

W. Curtis Preston: is that time of year.

Um, although, although I have to say I have.

I I, this will be a complicated year, right?

Due to a variety.

A variety of things, right?

The interesting year of employment and non-employment and contractor

work that I did last year.

So let me get, are your taxes like already done?

Uh, no comment.

W. Curtis Preston: Okay.

I just, you just seem so put together with this whole tax thing that I

figured that by now you'd be done

so I, I was just waiting for the last of the paperwork,

but I am one of those crazy people who sort of pre-plan everything.

So,

W. Curtis Preston: Yeah.

You got spreadsheets and stuff.

so usually I know more or less where I'll land

based on pay stubs and it's just the final bits of like interest and

dividends and other things like that.

W. Curtis Preston: You probably wouldn't be sleeping at night if you're in

my situation right now because I'm.

well, yeah.

Yeah.

I don't know how you do that.

I, so I should say that 99.99999% of the people are like you,

W. Curtis Preston: I think, I think you're right.

Yeah.

In fact, in fact, I know based on my work with, uh, Intuit back 25 years

ago, that like they were saying, if I recall correctly, it was like

something like 90% of their business on TurboTax occurs within like the

last three days before April 15th.

Prasanna Malaiyandi (4): Doesn't surprise me.

One challenge too is there's a lot of fraud.

So someone takes your social security number files.

A fake tax return.

Gets the refund.

W. Curtis Preston: that's, that is really hard to recover from.

Yeah, you know what else is real hard to recover from?

What?

W. Curtis Preston: deleted data in a SaaS provider that you don't have a backup of.

See that segue?

You're proud of that segue.

Look at

good.

W. Curtis Preston: So this will be a part of our continued series on

why you should back up the cloud.

And you know, the cl there, there's a bunch of different parts of the cloud.

Uh, today we're gonna be talking about a, a SaaS provider, possibly

of the biggest SaaS providers,

Prasanna Malaiyandi (4): I think they're one of the most valuable

companies in the world right now.

W. Curtis Preston: So that would be Microsoft.

And I remember in the, you know, my days at Druva, this was what

we saw as like one of the biggest greenfield environments because hardly

anybody backed up Microsoft 365.

don't need to back up Microsoft 365 Curtis,

W. Curtis Preston: Right?

Right.

you reach

W. Curtis Preston: Uh.

strangle me through the video.

W. Curtis Preston: Yeah, and, and the thing was, it was, it was super

difficult for me as a person who has dedicated their career to backups.

I really don't understand the people that have migrated to a SaaS provider

have migrated any portion of their.

IT infrastructure to some type of other provider of any kind, whether it's a,

you know, I, a s, past SaaS, whatever, and didn't check this box, right?

Didn't ask how does backup and recovery work there?

Right?

What's the thing that didn't look in the service agreement, didn't do any

testing of any backup, let's delete.

Something and then restore it and, right.

I, I like, I mean, I, I've known for a long time that people hate backup.

Right.

Nobody, nobody wants to do

I am sorry Curtis.

W. Curtis Preston: yeah.

Nobody, yeah.

Nobody wants to be the backup person.

Uh, that's how I got my job.

That's how I got my first job, was the, you know, Ron Rodriguez didn't

want to be the backup guy anymore.

And so that's how I got my job.

Right.

And that's how, that's how many of our listeners got their jobs.

Uh, and it's how.

Much of the cloud migration has happened, right?

It's people move to something like Microsoft 365, and I do know for a fact

that some Tams technical account managers at Microsoft 365 have uttered words to

the effect that they don't have to worry about backup, and that's one of the

reasons that they should migrate to 365.

They're, they're wrong.

They don't do it in writing,

This isn't unique to Microsoft 365 a SaaS or path,

because do you remember back in the day with virtual machines, right?

And VMware, right?

They had the same message as well, right?

And it wasn't until people were like, Hey, I'm now using this for

production workloads and I really should care about how I back it up.

And then that spurned sort of, okay, Veeam came along along

with other backup vendors, right?

Figuring out how to optimize it and make it better.

But the initial ones you never had backups.

W. Curtis Preston: Yeah.

Backup never leads the charge in anything.

Right.

Um, and, but, but it's still, it's still depressing to me sometimes.

Right.

And, and in this case, there are people, I can think of one particular person

I won't mention in my name, but I can think of one particular person that is a

fellow book author that, you know, just really doesn't seem to see the need.

To backup 365, even in his blog post about the incident that

we're gonna talk about today.

He said, you know, some people will probably tell you that this is an

example of why you need to back up Microsoft 365, but I wanna tell you

that even if you had backups, uh, that wouldn't have helped in this case.

And he's right, but doesn't change the

Yeah.

W. Curtis Preston: So enough with the preamble.

What are we talking about here?

What happened back in uh, 20, you know, August of 2020, what happened?

Isn't that right around the pandemic, Curtis,

where aren't we all locked down?

Not going

W. Curtis Preston: we were all, yeah.

So while we were all locked down,

Yeah.

So.

W. Curtis Preston: of little companies.

so this was a large, very, very, very large

company called KPMG, which is a consulting slash auditing firm.

They do both,

W. Curtis Preston: Right,

and uh, they decided one day, Hey, I'm going to

go change a retention policy for my Microsoft teams for a particular user.

W. Curtis Preston: right.

And they went and made that change.

And apparently they didn't realize it affected all users.

And by the way, that small company you're talking about, it's like 145,000 people,

W. Curtis Preston: You know, 45,000 people

And so it.

So it impacted the retention for those 145,000 people.

And so all these folks who are basically like, you know, auditing

companies and have a bunch of sensitive chat messages and other things.

Yeah.

All those messages went byebye.

W. Curtis Preston: Yeah, just poof.

And I'm sure that they reached out.

I mean, we don't, it's not in the story, but I am absolutely sure

that they reached out to Microsoft, said, is there anything you can do?

And the answer is, uh, no.

Because what you experienced is a feature, not a bug.

yeah.

W. Curtis Preston: And

the, the, go

no, go finish.

W. Curtis Preston: The true irony of this is that the feature that they were using.

That resulted in the deletion of data is the feature that people, including the,

the guy to which I was referring, they pointed this feature as a substitute

for backup, that you should use this fe.

That if you had, if you properly use this feature, you wouldn't need backup.

But apparently if you improperly use the.

Yeah.

So maybe Curtis, why don't you talk a little bit about the

feature itself and what it does?

W. Curtis Preston: Yeah.

So the feature that we're talking about is retention policies,

and they are complicated.

They're, the last time I checked, if you went and looked at the,

the justice feature in the documentation, there's 25 pages of

documentation on this one feature.

Uh, you know, that, that Microsoft 365 has, and basically what it's designed

to do is to, in general, the idea is to make sure that things that should

be around are around and subsequently things that shouldn't stay around, don't.

So.

A typical retention policy might be 90 days.

We set a retention policy on email 90 days, which means that after 90 days, what

sent email a received email of any kind, again, based on the policy gets deleted.

Right.

You could also set it to be a year, you could set it to be seven years,

whatever.

You can set different retention policies for, uh, email, for

SharePoint, for OneDrive.

You can set all these different, uh, policies.

You can also set a single policy.

Everything in Microsoft 365 is kept for.

End days and no longer, right.

Um, you can set it at a group level, you can set it at an individual level.

And the, the reason why, uh, and it has an optional, um, uh, and what,

what I'm gonna call, and I really mean it feature, um, which is a

checkbox that says once you set it.

Uh, you can't change your mind.

So once you say Everything in this environment should be

kept for a year, you can't.

Then 60 days later, change your mind.

Say, I, I, I'm sorry.

I meant, I meant something Way less than a year.

Sorry.

You've turned it on for a year.

Right?

that means any data created stays for that year.

W. Curtis Preston: Right.

if I created new data after changing into 60 days,

new data would stay for 60 days.

Old data would stay for one year.

W. Curtis Preston: right, right.

And so what can happen if you use this policy is so, and the, the reason

why I say this is those that are proponents of using retention policies.

Instead of backup, they basically say, look, Microsoft is really resilient.

They've got delayed copies and all this kind of stuff in there.

And so, so really like, like Microsoft will protect the

Microsoft environment, right?

And that if they have to recover the Microsoft environment, you will get

recovered as a consequence of that.

So you don't, these are the proponents of, of, of this, this

is not me, this is, you know.

Other folks.

W. Curtis Preston: Um, they'll say, you don't, you don't have to worry about that.

What you need to worry about is a ransomware attack or a

massive accidental deletion, like what happened at KPMG, right?

Yeah.

W. Curtis Preston: And so you can say, um.

Uh, everything gets kept for X amount of days, and you can check the box that says,

um, you know, and I can't change my mind.

And then after, you know, 30, 60, 90 days when you find out what that does to

your storage and you're like, holy cow, I didn't realize this was going to do this

to my storage, and subsequently my bill.

Yeah.

W. Curtis Preston: You can't change your mind.

I mean, you can change your mind, but you can't change your mind for that period.

It's not retroactive, right?

You told it, you know that you wanted to keep it and you wanted to do the, you

know, the uh, the compliance feature.

Since you just mentioned compliance,

so retention though, right?

It's typically associated with a compliance policy.

W. Curtis Preston: Right.

And even if the user goes and deletes that email before

the retention period is up, because it's sort of intended for compliance,

that email is still kept around until the retention policy expires.

W. Curtis Preston: Right.

Yeah.

When, when, when I delete an email, all it does is set the don't show it to Curtis

Yeah.

W. Curtis Preston: It's still there.

Right.

Um, the, and, and the other thing is that.

It's designed, you, you said it's designed for compliance.

It's designed, it's the complete opposite of backup.

Right.

So you know how we talk a lot about backup versus archive.

This is much more about archive and retrieval and e-discovery than it is about

recovering Curtis's email box because

To no point in time.

At no point in time.

W. Curtis Preston: Yeah, at a point in time, what it can do is you can

go then do an e-discovery case.

First off, you need different permissions.

It's different than like the default system admin, uh, permissions.

You need separate permiss permissions to do this, and then you can

go in and say, please extract all of the email that Curtis.

Has ever received or received in this time period.

And then they can throw that in your inbox all in one big pile, not in the folders

or whatever, that you had it before.

And by the way, not just email, but the same is true in SharePoint or whatever.

Um, it's just a big pile of stuff.

And then they put it back, and then you gotta go figure out

what what you don't need, right?

and usually you use retention policies because keeping data

around is actually sometimes a bad idea,

W. Curtis Preston: Right, right.

This is a, it's a legal, it's a legal issue, right?

And so you say, look, we're not gonna keep data longer than a year.

Um, period.

You know, I know that when I worked at Druva, they had implemented a data

retention policy on Slack, for example.

Right.

Um, you know, they only would allow Slack messages for I think it was like 90 days

Yeah.

W. Curtis Preston: So, so a couple of things about retention policies.

One is, it, it's not good at restore it, it any more, any more

than a backup tool is good at, at e-Discovery, this is an e-discovery

tool that's not good at backup.

It's not good at Restore.

And so

if you got a large ransomware attack.

It wouldn't be good at that, right?

The other thing is that it can result in significant increases in your cost, right?

And your storage, as opposed to just using a backup tool, which would

also have an increase in cost, but a different increase in cost, right?

And more, and a more predictable increase in cost.

Um, and then, and to the point of this story, it can

sometimes really screw you up.

yeah.

If you don't understand and aren't careful,

W. Curtis Preston: Yeah, so as I understand it, so the way that they

would've done this, and this, by the way, this is inference not information.

When you've got 145,000 people and you have, um, one person whose

private chats you wanna delete, and you've got a retention policy that

says for 145,000 people, we keep.

You know, private chats for six months, whatever, whatever the number is, right?

90 days, you can't, you can't delete those private chats as long as that person is in

the, um, in that policy.

So you have to create a different policy that says private chats

get kept for one day, and then you move that user into that policy.

Yep.

W. Curtis Preston: Apparently they just, they did the wrong

They just edited the policy.

W. Curtis Preston: they create, yeah.

They edited the policy, uh, and then poof instantly.

And again, they didn't have the, the flag.

See if they had, had the flag turned on.

And

Their old data would've been fine.

W. Curtis Preston: Yeah, the old data would've been fine.

Um, they, they wouldn't have been able to, to, to mess it up like this.

So one message could be, if you're gonna use retention policies,

you better turn on that flag.

'cause they all, they're all they, they are all you have.

Well, it wouldn't save you though from

new messages created, so you

W. Curtis Preston: No, but at least you wouldn't have deleted six months.

No, no, no.

But it would've been

W. Curtis Preston: this out in about five minutes, you

But would you though, because now anything new that

you type would be following that new policy and maybe you don't realize it.

W. Curtis Preston: Yeah, I just, I just think it would be, it would

be less of a tragedy than Right.

Um, and, and I, I do think it's important to say that had they,

there are no APIs for restoring.

Um, teams messages.

There are APIs and there are ways to get these messages.

They are, and some of them are frankly, very klugy.

Um, I, I remember, I remember participating in some of these

conversations, you know, when I was at Druva, getting some of this data

is very klugy because it wasn't really designed to be gotten right.

If you had done, if they had done that, they wouldn't have been able

to restore the team's messages, but

Prasanna Malaiyandi: would've had it at least.

W. Curtis Preston: they would've at least had it.

And if there was anything important in there, which there shouldn't

be, there shouldn't be important stuff and private messages.

Um, but remember, we live in a world where people use their recycle bin for storage.

Right.

Um, right.

You've seen that,

Yep.

W. Curtis Preston: Um, you are like, Hey, your hard drive is filled, and you, you

click the recycle bin like, whatcha doing?

You just deleted my storage area.

Yeah, that actually was the last thing that happened to me

at the bank was, was deleting.

I rebooted a server

It was

W. Curtis Preston: well, somebody rebooted a server and it was, it was hp

where HP that slash TMP was in ram and we found out a whole bunch of developers

had stored their code tree there.

And they were like, this is really important.

I'm like, then you shouldn't have put it in temp.

And they were very angry because we didn't back up temp

Who would?

It's Tim.

W. Curtis Preston: temp and, uh, we lost months of development work.

Um.

So we live in that kind of world, right?

And so, um, people do sometimes put important stuff in there and

anything that was important there were in messages, which shouldn't

have been, but anything that was there would've been instantly, um, deleted.

Sort of like, uh, opening the door, uh, when you're out to space,

Don't do it.

W. Curtis Preston: don't do it.

So, so let's go back to this, right?

So they lost a bunch of messages because someone accidentally

set the retention policy.

What should they have done?

What could they have done to make this less painful?

W. Curtis Preston: Well, I, I'd say a couple of things.

One, the first and most obvious to me was if they had a backup, then this

would've been less painful, right?

They would've been able to at least retrieve, you know, important data.

I.

And by the way, not all, not all products at Backup 365 are able to

get anything out of teams, right.

Teams messages.

Uh, some have to different degree, different levels of success.

Right.

But, but they would've had the possibility of getting that data back.

And number two is, it is a little surprising that an admin would

do something of that level.

I.

With a mouse.

Right,

Without any controls or any checks or anything else like

W. Curtis Preston: yeah, yeah,

at least approve or look over, Hey,

are you doing the right thing?

W. Curtis Preston: yeah.

You would think that something of that level, you know, I, I guess he wasn't

thinking or she wasn't thinking that, um, they were just thinking one person.

It's just one guy.

I'm just doing one guy.

But that's where a process becomes so critical, right.

And documenting process and.

W. Curtis Preston: yeah, yeah.

So they could have, they also could, had they enabled the, the

retention lock, that's what it's called, the retention lock feature.

They would've at least kept the data from before.

Um, and they would've, they would've minimized the pain if they turned

on the retention lot feature.

But I'm not a big fan of the retention lot feature because.

Its potential significant increase in, uh, in storage costs.

and especially, it's so hard to predict how much

space you have or would be consuming before you enable that feature.

Like any sort of capacity planning or sizing, calculators, I've seen even for

general storage, they're not accurate because your workload is going to

change and it's going to depend on your environment and how people use the tools.

And so it's just a best guess.

And until you actually turn it on, start using it, you're never gonna know.

W. Curtis Preston: Yeah, I would think that if, if you're gonna use the retention

policies instead of backup, right?

Which you shouldn't do, but if you did, should turn it on for, let's

say three months and see what it does to your storage and then, and

then make a decision at that point as to whether or not you wanna.

Essentially make this permanent.

Uh, and then when you see what it does to your storage, then maybe have

a conversation with a backup vendor and say, Hey, can you do this with

less of an impact to my environment?

Right.

Um, now some people, you know, you know, so I read, uh, with, with great delight.

I read the comments in Reddit, there's a Reddit thread

about this, and there's also.

A comment thread from the register article.

I, it's one thing I love about the register is that they have

comments and boy do people get in.

What's

We'll, the links in the show notes.

W. Curtis Preston: Yeah.

Thanks to those.

Yeah.

Um, you know, and you know, of course you got the standard stupid cloud, you know,

it's where you want to put, you know, I'm like, dude, this could have been exchange,

right?

Uh, this could have been an exchange environment.

Right.

Um.

Then the other, of course, is, well, why didn't they go, why

didn't they go to their backup?

Like, people just completely ignorant that, and, and I,

that that's the proper word.

People like, they're like, oh, that's pejorative.

It's the proper word.

They don't know that Microsoft 365 doesn't have backup.

If you are not providing it, it doesn't have it.

Given how big KPMG is and what sort of

things that they provide to their clients, that's a little shocking.

If they didn't know that there's no backups.

I'm sorry.

That's just bonkers.

W. Curtis Preston: It is bonkers, but it's a bonkers that I run into all the time.

Right.

Um, yeah.

so I know that we're looking at this as

people lost a bunch of data.

W. Curtis Preston: Mm-hmm.

And people lost their chats.

Right?

It was probably a lot of sensitive information or

important information was lost.

I was just going in my head about what, that must be amazing because

it's like you hit a reset, you don't have to worry about deleting

conversations or anything else, right?

It's like clean slate.

It's like you start a new job somewhere.

It's like no previous chat messages, no baggage, no nothing

that you have to worry about.

W. Curtis Preston: Yeah.

Well, the, the other, the other thing, when I think about this.

Uh, again, when I talk about this other person, you know, they're like,

well, it was just private messages.

You shouldn't have been putting anything of value in private

do that all the

W. Curtis Preston: That is that people do it all the time.

Right.

But they're right.

They're right.

You shouldn't do.

Right.

But this could have just as easily been email,

Or SharePoint.

W. Curtis Preston: Or SharePoint, right?

So retention policies are global.

If you want them to be right, you can make them as granular as you want.

Retention policy for one person, which is what they were trying to do, they could

have just as easily deleted all email

yeah.

W. Curtis Preston: in the environment.

They would've had no backup, they would've had no recourse.

'cause the, the whole point of retention policies, by the way, I mean this is maybe

something I should have mentioned before.

The point of them is that if you say don't keep it longer than

X, it gets rid of everything.

It, you know, it, it, it keeps it longer than, you know, if you said it's to 90

days, it, it deals with the, recycle bin.

Right.

But wherever that entity is, that record, that email,

Once it's 90 days, it's boom.

Gone.

W. Curtis Preston: it, boom, it's gone.

And in this case, they set 90 to one or zero.

And that basically that means that there was no recycle bin

for them to go get this out of.

And that means if they did the same thing with email, they would've wiped out

the entire organization's entire email

infrastructure

Or if they did that with One Drive, then

all the documents are gone.

Right.

So here's my question though, is assuming that they wanted to, because.

Given that they wanted to set this user's retention policy to zero, that pretty

much means they want all the data gone.

W. Curtis Preston: Right.

Why didn't they just delete the user?

W. Curtis Preston: Uh, because it would, the data would've stayed.

Oh, okay.

W. Curtis Preston: Yeah.

Again, that's the whole point of retention policies.

Right.

Um, and, and I don't know, you know, I mean, we can.

We can theorize as to what did this user say in their private messages

that they've really wanted gone.

Um, we can theorize, by the way, there are theories I, I, I should just mention

them as long as we're talking about When I look, when you look at the thread,

there, there were, uh, pending legal matters where these private messages.

Perhaps could have been helpful, but now they're not available and this story would

at least be a legally defensible reason why, why it deleted our admin screwed up.

This wasn't spoilage, this wasn't purposeful deletion because of of a

lawsuit, but it also violates if they had a lawsuit that included this data.

It, it could potentially create, uh, an adverse inference, um, thing.

And I'll just explain that for those that don't, basically if you're being

sued or being prosecuted for something, if the judge believes that you have

either destroyed evidence or have behaved poorly the, basically the judge

can infer from that behavior something adverse to your case, and they could

literally, like in the case of a jury.

They can literally turn to the jury and say whatever the plaintiff said

was in those private messages, just go ahead and assume it was there

because why the hell else would they delete the private messages?

Right?

That's what's called an adverse inference instruction.

Um, and or if you know, if the judge is by themselves, they can just do it,

but, and I do wonder though if given the fact that

they weren't doing backups of this data, I wonder if that does qualify for that.

Right.

Because yeah, you can blame that the admin was, did something by mistake,

but there's no reason you shouldn't have backups of business data, you know?

W. Curtis Preston: Well, you know, I agree with you there.

They possibly could say, well, even if we had backups, we wouldn't have had the

data or whatever, because it's teams,

But you have the data, you could extract it as on, you'd

maybe not restore it directly back into teams, but at least you have the data.

W. Curtis Preston: Yeah.

I, I think that, well, any adverse inference that could be inferred

from their behavior is in the sole discretion of, of a judge.

Right.

And so the judge d different judges are going to have, uh, different levels

of like, you know, do they, do they believe that people are inherently good?

Right, right.

Uh, you know, they're, who knows what it, uh, this was four years ago.

We could probably find out, but, uh, I didn't care that much

about the part of it, but I just wanted to say that this was.

Part people were specifically pointed to specific cases that, uh, this is in

the, the register thread, by the way, for anyone who wants to look it up.

Um, this certainly is a nice way to get rid of a bunch of data with a nice story.

That doesn't sound like you're trying to do it purposefully.

I'm not saying that that's what happened, but I'm saying some people

so, so here's the thing.

In summary, Microsoft 365 isnt magic.

The cloud isn't magic.

You, you need to back up the cloud somehow, right?

Just like, it's not like people thought that, especially certain

people thought that I was saying this just because I work for dva, right?

Well, I don't work for Duv anymore.

Uh, the, the, it's not magic, right?

You know, it, it needs some kind of backup.

I don't, I don't, it doesn't have to be a third party.

I would prefer it be a third party.

Right.

So you look at like, so Microsoft is starting to talk about snapshots

and some sort of recovery.

I don't yet know how that will all play out, but in general, and, and if it meets.

The

W. Curtis Preston: The usual, like 3, 2, 1 requirement.

'cause again, going back to the 3, 2, 1 rule, having three copies of your data,

two of which on, you know, different media with different risk profiles, one

of which being stored somewhere else.

The thing with 365 and a lot of SaaS providers is that they don't

do the two or the one, right?

It don't do any of this.

They don't have a separate copy of your data.

That that's, that's basic.

It's not magic.

The cloud doesn't solve all new problems.

In fact, it creates new ones and I'm pro cloud.

Right.

How are you feeling Curtis, about this?

W. Curtis Preston: I know.

I was in a pretty good mood.

The beginning of this.

You to.

and I think this just goes back to humans make mistakes.

You gotta back it up.

W. Curtis Preston: Humans are the number one reason we back up.

It's, I mean, that's been more, that is more true today

than it ever was 30 years ago.

The number one reason we were doing restores would be 'cause

somebody deleted a file, right?

They fat fingered a file, they fat fair, and get the current version of

the file and they accidentally saved it.

Right.

Yep.

W. Curtis Preston: That, that was the number one reason we did 30 years ago.

And every once in a while we would also lose a server.

Because remember back then we didn't even have a raid, So if you lost a hard drive,

was very

W. Curtis Preston: you lost a server, right?

Um, you move 30 years up and it's still stupid.

User errors and ransomware, which is another human caused

reason that we do restores.

Um,

Because also isn't most of the ransomware attacks started

with phishing more than anything else.

W. Curtis Preston: Yes.

Yes.

it's an employee who accidentally clicks on a link

that they shouldn't be clicking.

W. Curtis Preston: Right.

I, I saw, I'll, I'll, I'll tell a little story that I saw today on, um, on, um.

TikTok and it was a guy who, like, he, he was like, he said, you would not

believe what my wife's company did today.

The video was actually made yesterday, so it's, this would be, uh, Valentine's Day.

SO for those of you that don't know many companies, if not most companies do

automated phishing tests, they send you.

Emails that are essentially phishing emails to see if you will click on

them or to see if you will notify them.

And, um, he said they sent an automated email or they sent one of these testing

emails to everyone in the company that said you have a Valentine's Day delivery

from Edible Flowers at the front desk.

And, uh, you know,

Click here.

W. Curtis Preston: and then, and then there was a click, right?

And he said for like, you know, a few minutes.

Everyone in that company felt they were loved that, that they found out that

it was just,

W. Curtis Preston: was a

phishing email.

Instead of getting love, what they got was yelled at by it.

And

W. Curtis Preston: goes, accept.

He said, accept my wife because my wife knew.

There's no way I'm spending $200 on a, on some cantaloupe that's

made to look like a flower.

That is hilarious.

W. Curtis Preston: But yeah, that's just, I mean, the sad thing is, I mean, like I

see both sides of this argument, right?

Phishing emails.

Right.

They, they, they come, they, they are timed two things, right?

They, they would, a, a bad guy would do this.

They would leverage Valentine's Day, they would leverage Christmas,

um,

at the company or something like that, right?

W. Curtis Preston: exactly right.

Um, and so on one hand I totally understand why they did, why they did

what they did, but it's also messed up.

And then this guy that posted it, there were a lot of comments and people were

like, yeah, we were told we got a bonus.

We were told we got this.

We were told we got that.

And it was all, uh, a phishing test.

That's No, no, no, no.

It was a phishing

test.

Like it was the.

And so instead of getting a bonus or Edible

flowers, they get to go for a one hour training session on fishing.

W. Curtis Preston: yeah, yeah.

So you need to back up your stuff.

You need to back up Microsoft 365.

In this case, this is just the best, this is the current best example we have.

If we have a new one, we'll make another episode.

Um,

last.

Oh, one last thing to add.

Realize KPMG is a humongous company and they had issues.

If you're a smaller company right?

Don't feel bad that you're like, you haven't done anything yet, right?

So, but now that you know, go figure out how you are gonna

back up your SaaS applications.

If you're using Microsoft 365, figure out how you are gonna back

it up so you don't end up like KPMG.

W. Curtis Preston: Absolutely.

I will poorly quote Maya Angelou.

We did what we did when we knew what we knew, and now we know better.

We can do better.

Uh, it's, it's a great quote, um, even if I didn't quite get it

right, but that's Maya Angelou.

May she rest in peace.

Well, thanks persona.

Another fun episode.

was fun.

This was fun and I hope you sound a bit more cheerful now towards the end

versus, uh, about five minutes ago.

So that's a good sign.

W. Curtis Preston: I was angry and thanks for those of you that are listening

and, uh, look forward to some more.

You should have backed up your stuff, episodes coming here in the

coming weeks, and that's a wrap.