This week, we're talking about one of the most fundamental technologies

underpinning today's data protection systems and that's replication.

What is it?

How is it different than other methods?

And if it's so great, why don't we just use it for everything?

And of course what's the difference between synchronous and asynchronous.

And why does that matter?

Hi, I'm W.

Curtis Preston AKA Mr.

Backup.

And I've dedicated my 30 year career to helping people like you keep your data

safe from all that would do it harm.

This is the backup wrap-up.

Welcome to the show with me, as always, as a guy who seems to never

be happy until I have problems.

Prasanna Malayandi.

How's

I'm good.

I'm just trying to think what problems do you have right now?

Talking about, I'm trying to edit the podcast and you're giving

me problems about my network.

That's,

what I'm talking about.

yeah, it's.

What I do, you need someone to ask the hard questions,

Somebody's got to do it.

The network's going all right.

Those that have followed, I do have this new tool.

I have, um, the, uh, Firewalla.

version 125 of Curtis's home network, architecture.

Yeah.

but I now have this Firewalla that gives me a lot more

information than I had before.

And unfortunately it verified, my new ISPs, thing that I use too

much internet and I have to buy.

the unlimited package, which is sad because it's another 50 bucks a month.

But anyway, so let's get to the news of the week

I'm going to let you take the first story, uh,

Yeah, yeah, yeah, so the first one is an article that came out recently.

it is about a backup compa I guess, would you call them backup or data

protection company that recently, Raised around a funding, it's called Alcion.

I actually used to work with the founder previously at an old job.

and they actually raised a round of funding and it was actually led by

Veeam, which is interesting because Veeam, as we all know, is also a backup

company and they are investing in Alcion, who is primarily targeting backups

for Microsoft 365 for SMB customers.

today?

That's their initial target market.

I'd say that the biggest difference between the two companies,

one is a software product, the other is a SaaS offering, and

that makes them very different.

And I guess Veeam felt that it was different enough.

I like the quote in the article.

It said something along the lines of that, that from Veeam, that

this problem of ransomware is a big enough problem that we're going to

need the whole industry to solve it.

And so they invested in what.

is essentially, I would call it a partial competitor, right?

They do compete for the Microsoft 365 space, I also know the founder as

well, and, I think they've taken an interesting angle with a very AI based

approach, a very security based approach,

Yeah.

And one of the things that I'm actually looking forward to is seeing if this

is going to force other vendors to reconsider how they approach the problem.

And.

Everyone in all the vendors raise a bar when it comes to ransomware

protection and detection and other things like that, which we all

need.

Right?

Anybody that's listened to this show knows that we're concerned about that problem.

my second news story, it's from the enterprise strategy group, which for

those of you that have known ESG for a while, they were, A few years ago,

acquired by TechTarget, and there was a, 2023 survey of IT professionals.

The most interesting number that I see here is that they said 65 percent

of the almost 400 respondents said their organization were using some

sort of cloud based, backup system.

And the way they worded it, that could be either a cloud based

service or they're storing a copy of their backups in the cloud.

That, to me, really, that's a very different number, wouldn't you say, than

a few years

Yeah, everyone would be like, I don't trust my data in the cloud.

How do I get my data up into the cloud and bring it back and all the rest of that?

In fact, I think one of the interesting things was even just

the title of the article, right?

It's like cloud backup and disaster recovery evolved toward maturity.

You know, that just kind of says it all, right, versus before you're

fighting tooth and nail with customers, trying to persuade them, Hey, it's

okay to store your data in the cloud.

But

Yeah, so the not so good number was saying that half of the surveyed orgs

recovered 75 percent or less of their cloud data per incident on average.

That sounds really bad.

that is not, I agree with, Christoph Bertrand, which said that's just

not acceptable for, such a mission

I guess the question I would have is, it would be, we probably need

to compare that to what's your recovery rate of on premises backups,

because that's not going to be 100%.

and then I think it's also not fair to compare it because how

long has traditional backups, been around and had time to evolve

versus cloud backups, right?

It hasn't had that time to evolve and mature.

Fully as these other products

Yeah, I would say that part, having formerly worked at a cloud data protection

vendor, I would think that the problem that I see with this number is that they

do conflate people storing backups in the cloud versus people using a cloud service.

I would be very surprised to learn that.

People that are using a fully cloud based service, if they, if their recovery's

failed, because the other, it's really, the cloud just happens to be a part of it.

All of the same sort of misconfiguration problems that lead to problems

with traditional backup are going to bleed over into a cloud.

Just because you're using cloud

but it's the cloud.

It's magical.

Come on Curtis.

Yeah

Yeah, it is magic.

the one other interesting number from this survey, and there were

some other interesting numbers, but just for brevity purposes, this other

interesting number, they said 16 percent of the, respondents said that they.

reviewed their, their cloud data protection strategies annually.

that is, that's a very different number than back in the day.

Back in the day, that number was like five years, maybe three years.

Certainly not annually.

Backup historically has been an incredibly sticky process.

And, this idea that they would review it annually, I think it's a

I think it also makes sense though, because you like with the five

year, three year, five year, right?

You have to worry about hardware depreciation, right?

Upgrade cycles all the rest With cloud, right?

There might be new technologies, cheaper ways to do things, right?

Your workloads might change.

what you had running on premises might be migrated to the cloud.

now you have to reconsider it.

How do I back it up?

And so I think that's probably why looking at these things more

frequently, like annually, probably starting to make a lot more sense.

Well, that is the news of the day.

on this episode of the Backup to basic series, we're going to be talking

about replication, different kinds of replication, the good things, the bad

things, and what they, you know, what they have to do with backup and, and

I, I,

it a backup,

I, I, I I thought you were going to talk about like the replication

technologies that they have in like Star Trek and, Right?

Where it's like, create me,

No, that's, that's not replication.

That's...

What is that called?

what are those things?

Transporters?

Oh, oh, no.

the making, the stuff, right?

The food

Do they call them replicators?

Yeah.

I think they call them replicators.

We are, we are not discussing replicators like in Star Trek, although that does,

those do sound magical, by the way.

And by the way, like if you could do transporters, of course you

could do replicators, right?

Because all replicators are is storing a backup copy of the food and then

saying this is what it is, right?

Do you think that they have backups of those backups?

The copies?

Yeah, no, the copies of the food because imagine you wipe out the

copies and then you've basically killed off humanity because they

wouldn't have any way to make food.

I

Or maybe they're immutable, or maybe they're immutable copies, you know?

Maybe they're immutable copies.

I would, I would hope that no one can go in and change the

food before it gets replicated.

Um,

On to a more serious matter.

let's do a more serious matter.

Well, so we, we've moved on the previous episodes.

We talked about sort of regular kind of backups and they were, they were backups.

That require a restore basically is, is what we were talking about.

We've now moved on to types of backups where the restore

is essentially already done.

Right.

Um, and replication.

And so I'm, I'm, I'm putting these and, and by the way, you know, for those that

don't know what I'm talking about, we are basically working our way through.

This book, Modern Data Protection, which is my book, which is available,

you know, wherever books are sold.

And, um, you know, I might even put a, put a link in the show description there.

Um, and the idea here is what we're talking about is methods of backup.

And again, remember when I say backup, I I'm very broad in that term, methods

of backup that support instant recovery.

What do you want to talk about?

What instant recovery is?

Yeah, so, normally when you think about, you took a backup, you

need to, something happens, you need to get back your data, right?

If you had your data stored on tape, you gotta go fetch the tape, you gotta pull

the data off of tape, copy it somewhere else, and now you actually have your data

and you can do something with it, right?

With Instant Recovery, It's really, your data is already available for you.

You don't have to have any sort of processing that you have to do before you

can actually start accessing your data.

Yeah, I mean, it's a beautiful thing.

I think that maybe, I dream that sometime in the future, this is

the way all restores will be done.

And the cloud really does make this possible.

We could talk about that all day long, but we just need to work through

the different ways that, um, we're going to create an always on readily

available copy of the data, and the first that we're going to talk about is

Before you get there though, I think one important point to cover is, I

know you said in the future maybe everything will be like this, right?

I think if you had a gazillion dollars, yes, Because there

is a cost associated, right?

Which I think is important to cover, right?

With sort of using these various technologies that might make it more

difficult now Like you said, maybe the cloud helps with some of these but there

is still a cost associated with Keeping data on something that is instantly

available Versus say using a tape or some sort of offline Media where the

cost may not be just the cost of the storage but think about from power cooling

Right all those other aspects as well

Yeah, I was speaking in the future when these problems have all been solved.

Um, I think even today that there are services, there are cloud storage

services, that if used properly and judiciously, can provide you A ready

to go copy of your data pennies on the dollar that costs you, you know,

next to nothing to, to have and to possess and to have it ready to go.

You will then pay through the nose if you use them, right?

I'm thinking of course of like Glacier, Deep Archive, Instant Recovery.

Right?

There are services that are still storing the data on disk, but storing

it in such a way, I don't know, we don't, you know, neither of us have

ever worked at AWS or any of the cloud providers, but they're storing it in

such a way that they've made it so cheap.

To, to, to have that copy, to have it offsite, to have it in,

you know, in another region.

I just think that as that continues to happen, that we will eventually

get to a place where all DR copies can be held like this.

Can I have a dream, Prasanna?

Can I have a dream?

Can

You can have a dream, but I think, but yes, but before, sorry, before

we also continue on, I think we also need to define what we

mean when we say instant, right?

Because instant,

when we say instant recovery, right?

I think it's helpful to talk about that because instant is a spectrum, right?

Like you were talking about for your Glacier instant restore feature, right?

It's not like, Oh, I want my data.

It's available within the Cloud.

Like, snap my fingers, it's there.

Right?

It does take time, but that time may be acceptable to you, right?

It might be, say, minutes, not days.

yeah.

So instant is kind of like continuous.

It's a binary condition.

It's sort of like immutable.

It's a binary condition.

It's like pregnancy, right?

You're either pregnant or you're not.

And so it's either instance or it's not.

But it's yet another one of these terms where it's not truly binary.

Right?

It's just, we're defining instant recovery in this point is, I don't need

to do a restore to do the recovery.

The data's already been restored.

It might take a few minutes to make it accessible to me.

Yeah, sorry, and, and just for people who may not have heard our previous

episodes, do you want to quickly cover differences between restore and

recovery since you just talked about it?

A restore is essentially the act of bringing back the, you know,

the data and putting it in place.

The recovery is the process of sort of bringing that data online and using it.

And, and sometimes that recovery involves massaging other things.

It involves massaging the data and it involves doing other things.

When you're done with the recovery.

Everything is working again.

When you're done with the restore, everything is ready to be working again.

Uh, so depending on how good or how complicated the restore is,

the two may be, they, they may happen at the same time, but in a

complicated situation, you do the restore and then you do the recovery.

this case, uh, the recovery would be this instant of, um,

you know, like I said, just,

Everything's ready to go.

Or sorry, everything.

has, is available.

Yeah, exactly.

Uh, we don't have to do a restore.

And I would say that in a true instant recovery, the size of the, of the thing

being recovered should not be a factor.

Whereas in a restore, it very much is,

Oh yeah.

right?

Yeah.

Yeah.

Okay.

So with that in mind, we're going to talk about the first method that could be used.

And, and is used actually, it is used quite a bit to do an instant recovery.

Uh, as we often do on the show, let me take you back in the day.

Yeah.

So back in the day, there was a very sharp dividing line between.

Backup and recovery and disaster recovery.

And for backup and recovery for what we also call operational

recovery, you had a backup system.

You went to tape and, and when you did a restore, you, you came back

up, you came back off of tape.

Anyone with a tight recovery time objective would never build,

uh, their DR system based on tape back in the day, right?

Even as we move to disk based backup and recovery systems, anybody with a

tight RTO is not going to build their disaster recovery system built on

having to do a restore first, right?

So back in the day, if you worked at like a financial trading firm or

something like that, and you wanted to have a disaster recovery plan because of

course you wanted that because you had the OCC that was looking into you and

Regulation,

could say we're not a bank, right?

You used replication.

You had a backup and recovery system that did operational recoveries

and file recoveries, and maybe even recovering an entire server.

But if you had data that truly mattered, you used replication.

And, and I know you worked at a company

Yeah, that, was my first job out of, out of

college.

Yeah, So, let's talk about what replication is, uh, how does

it typically manifest itself.

Do you want to just...

Sort of define what replication is?

so replication is basically taking data, making a copy, and sending

it off to some other system, right?

At a high level.

Now, there's various nuances and combinations that other system

could be the exact same vendor, the same model, all the rest.

As the original, it could be a different vendor, right?

A different system.

Right?

So there are different ways you could do it.

There are different protocols for transferring that data.

You could use protocols that some of these vendors have built in

for communicating between them to make things more efficient.

Because when you have to send data across from one system to another,

doing it over and over, because it's not like it's a one time operation, right?

Depending,

Yeah.

If I could interrupt, I think that's one word missing from your definition.

If I could insert at the beginning of your definition, the word continuously.

Right.

Because anybody can copy the data over.

I think replication implies that we're continuously copying it

over.

The idea is that it, that it's happening all the time, right?

We're going to talk about the difference between asynchronous and synchronous.

So sorry for the confusion for those, but basically you have some data, you

know, in A and you, and you have a copy of that data in B and that copy,

that, that B copy is continuously, for lack of a better word, updated to

be the same exact thing as what's in

Yeah, so going to Curtis's disaster recovery scenario, right?

Something happens on system A, right?

System B has a version of what system A looked like at a point in time,

and you can fail over to system B, and that's how you're instantly

up and running, because system B

I think one thing we should also cover, which I want to talk about

earlier, I know you threw out the term recovery time objective.

I think another point to talk about here is also recovery point objective, right?

Yeah.

Well, go ahead.

You brought it up.

So yes, in the case of when you're doing synchronous replication, yes, there's

still going to be an RTO on that.

But that RTO, you should be able to measure in seconds to minutes, depending

on how long it takes you to bring up system B and make it available for

your applications and other things.

So that's kind of

like RTO side.

Do you wanna talk about the RPO, Curtis?

Yeah.

So the RPO is, is basically the amount of data that you

agree that you can lose, right?

The recovery point objective is we say we can lose an hour's worth of data.

We can lose a day's worth of data.

We can only lose five minutes worth of data.

This is.

You're setting your recovery point objective.

What, to what point must you recover?

And the fastest RPOs in the business are going to come from these types

of products that we're going to talk about in the next couple of episodes.

The first of which being.

Uh, replication with a, with a, you know, a replication

system, you could get an RPO.

Uh, you could meet an RPO that's as close to zero as possible,

actually seen zero,

Yeah, I'm sure you can do zero.

It's just that

so

I'm gonna

could happen,

So it's in a very, very unique case.

So I don't know if you're aware of this, there is a mode on

some systems called domino mode.

It's out there in the industry, right?

And basically what you're saying is, every time I accept a write

on system, A, I'm gonna make sure it's replicated, it hit system B.

It's acknowledged before system A acknowledges a client.

Yeah,

you're guaranteeing every

basically, it's like a two phase commit for storage.

A two phase commit is a term from database, um, world, which makes

sure that it's written both to the log and it's written to the, you

know, before you acknowledge that the, the transaction has happened.

It's High

latency, very expensive, but if you have those requirements, there is an option.

But like you said, most

people will...

So the question is what matters more to you, performance or never losing any data?

So let's, speaking of which.

Let's talk about the difference between synchronous replication

and asynchronous replication.

Um, synchronous is basically what you just described that, um, well,

it's not necessarily what you

Yeah, not fully to domino

we are going to, we are going to replicate every byte.

As it's happening, right.

And literally every single, you know, the moment it, a change happens here, the rep,

the change is going to be replicated to the, to the destination, to the target.

Right.

And, um, the, the good side of synchronous replication is you're going to have.

The smallest RPO is possible, right?

Including, I guess I, I, I, I guess I was aware of it.

I didn't know that that, that I didn't know the term dominant mode, but,

but I was aware of that, that idea, the, this is going to give you your,

your tightest, uh, RPO as possible.

The challenge with, uh, this is a little thing called the speed of light.

The, um, it takes, so, you know, one of the things that we.

That we know is that we want the recovery copy to be some

distance away from the primary

in the same rack.

not in the same rack, not in the same town.

Um, there are sadly some stories from 9 11 where there were companies

that had their hot site, which was a synchronously replicated copy of

their data in the, uh, other tower.

And so there were companies that ceased to exist on 9 11 because they lost both their

primary and their secondary copy, right?

You don't want to have the two copies in the same place where a disaster

could wipe out the entire town, a flood, a earthquake, whatever.

And so you want to have some distance between.

uh, the two.

Now after 9 11, the, I don't know which, um, which governmental organization,

but after 9 11, the, the fed, the federal government, not the fed, which

we say the fed or you know what I mean?

The federal government started to dictate that A recovery that, that a, that a

synchronous copy of the data needed to be stored more than it was like 250 miles.

And, and everybody basically came back and said, that's not really feasible.

It's possible, but not feasible because going 250 miles.

At the speed of light, every single time you replicate, every single time you

update a block on every piece of storage, um, basically really pulls down the, um,

the performance of the primary system.

And the other thing to also mention is when you're doing synchronous replication,

you want to make sure that you're...

Destination system, right?

Your replica copy is as performant as your primary copy, right?

Because otherwise, if it starts to lag and slow down, eventually you're going to

start falling further and further behind.

And usually these technologies, after a while, they'll just stop accepting writes.

And they'll kind of fall back into like an asynchronous mode and

have to then catch back up, right?

Which you don't want because that affects your RPO.

Yeah, you don't want.

Yeah.

So yeah, so it's got to be basically the same, if not better

performance on the backup system, which is crazy talk to most people.

Right?

Um, but that, but that is if you want an RPO of zero.

Synchronous replication is literally your only choice, right?

Let's talk about asynchronous replication and that is basically

not that we're, we're not, we're going to build essentially a buffer.

Uh, of writes as the, know, and we try to not let the buffer get full, right?

The, basically the, what it does is it disconnects the, the writes on the

other side with the writes on this side, we may, and we'll try to keep up

with the pace, but writes can continue to update and you might get a spur of

writes, uh, on the, on the primary side.

And then they fill up the buffer and then, you know, the, the buffer gets emptied.

And that I think works as long as essentially your, you know, your bandwidth

and your latency is, is sufficient.

Um,

And,

go ahead.

and I just want to chime in that I know you called it async and async

threw me for a while because in my mind async is different, but that's

just based on my background, right?

Um, other vendors might refer to this as like semi synchronous, right?

Where it is not fully synchronous.

Right, but

Well, not synchronous.

Asynchronous means

know, I know, I know, but this is just some vendors.

So if you are looking at vendor terminology, right, and looking at

their vendor technical specs, what, so here's a question for you, Curtis.

What are some things that a user can look at for a vendor's technical

specs to determine if they support async replication, like what

we're talking about right now?

Well, I mean, I don't know what other words they would use to describe

it,

I know NetApp uses semi synchronous.

For what you're describing.

whatever.

That's just mark.

That's just marketing BS.

Okay.

It's either synchronous or it's not synchronous.

You're either replicating everything as it's happening or you're not.

Okay.

Like, so the question is, so the question to the vendor, it's not, is, can my target

copy ever get behind my primary copy?

And the answer is yes.

And it's like, well, well, how much are we talking?

Right?

So the question is, because that's going

the, so that's

actually the key, yeah.

Yeah, exactly.

So if you can build up a buffer of an hour of changes, you could lose an

hour of changes on the, on the target end if you lost your primary, Um,

and.

what if you said like, I want, so, okay, so then I'll take back my comment.

In your mind though, if I said I want to have a replica copy

updated and my RPO is 8 hours.

That's still async.

Well, what else would you

Okay.

No, just, just checking.

Yeah.

I mean, again, you're either synchronous or you're not

So then, so then I take back my comments, right?

So if I look specifically, that's why I just wanted to make sure.

You stand corrected,

Yes.

So if I look at, sorry, I used to, I'm more familiar with NetApp and NetApp's

replication technologies, right?

But if I look at NetApp, right, they have synchronous, which we talked

about, which matches perfectly with what we were talking about.

They have semi sync where it allows some amount of lag.

I think it's up to 60 seconds.

Right.

But it does like what you said, buffering, and then they have

sort of their async, right?

Where it allows you to go beyond, I think it's from five minutes to, you can set a

replication every five minutes to days,

And those are just two different, those are just both asynchronous with different

settings, as far as I'm concerned.

Um, and, and you could also, like, if you were a net app and I don't think they do

it like this, but if you waited until you took a snapshot and then replicated only

the bits necessary for that snapshot, that's still kind of asynchronous,

just a technology.

That's a means.

yeah.

But generally here, we're not talking about snapshots and things, because

that's what we're going to talk about.

In a following episode, generally what we're talking about is two,

you know, block devices that are being continuously updated to be

exactly the same with possibly a lag.

If there's a lag, then it's asynchronous.

If there's no lag, then it's

Does it have to be, so I'm going to ask another question.

So

you are

I know I am.

So you said block devices.

Would you consider anything that also replicates a VM at a VM block level

Yeah.

Yeah.

I mean, in the end, it's still a block device underneath, right?

It's not what we're replicating.

It's just that, um.

We don't, we don't have this conversation when we're talking about object,

Or files.

We don't, we don't, well, even, even file replication, we don't really talk

about synchronous and asynchronous when we do file replication, I don't think.

I think that's always asynchronous.

At least I don't think so.

I think this is generally a block discussion, right?

There may be exceptions to that rule, but generally this is a block discussion.

Even if this is a NetApp, right?

Really what you're replicating underneath the NetApp is file.

It's a file device, but underneath you're replicating blocks.

Um, all that, all that discussion just from one word.

Um, so, you can also have a hybrid of these two things.

Can you think of an example of that?

Is

Yeah.

So take your bank example, right?

So you're a financial customer in New York.

You want to make sure that your data is synchronously

protected to someplace nearby.

So maybe you go over the river to New Jersey using synchronous

replication, and now you need to make sure that you're protected in case

something happens in the East coast.

And so you might use async replication and send that copy off to say, Utah.

that when we go through the woods?

Yes.

See what I did there?

Over the river and through the woods?

Um, yeah, so you might, and that was, I remember back in the day,

we had a synchronous copy that was literally like right next door.

I mean literally, when I say next door, I mean Like it's the next

rack over, um, that was, uh, like an A or asynchronous replication.

And then actually, will you remember Symmetrics and or,

or, or EMC and, and NetApp?

They, you'd have like three.

You'd have like four storage arrays, right?

You'd have the,

Oh, you can have

a lot more.

Yeah,

you'd have the synchronous that was right next to it, the asynchronous

that was down the street.

And then another asynchronous that was the other.

Yeah,

and sometimes there are customers who could use it for like data

distribution use cases, right?

So I need to

make sure that my database is available locally in different countries.

So I'm just going to replicate it all.

yeah.

So synchronous, both forms of replication have a lot more applications

than just backup and recovery.

Um, so I'm glad you mentioned, you know, or you VMs, there is another.

Not file and not VM thing that gets replicated, which is very, where

we still have sort of the same discussion about synchronous versus

asynchronous, and that is databases,

Application level synchronous

right?

And, and, and I'd say that in that case, basically.

When we, again, that can definitely have two phase commit, right?

So in the database.

You're replicating a transaction or, or something.

I don't have a better word.

I know not every database has transactions, but I

don't have a better word for

It's the atomic unit, whatever it is, or sorry, the unit of

Yeah, an atomic unit of a thing, you changed a thing in the database, right?

And you're replicating that, rather than the blocks underneath.

And, well, you could be replicating the blocks underneath, and that's

what we're talking about over here.

But at this point, we're talking about database level,

application level replication.

And when you do that, you have the choice of either immediate

consistency, or eventual consistency.

Which is essentially analogous to synchronous and asynchronous.

And, and what made me think about it was when you were talking about that,

there are other reasons that people replicate and, um, there are databases

that allow replicating data, you know, across the world and the best.

Example that a lot of people are used to is the DNS database, right?

That is an eventually consistent, replicated, um, system.

If you've never, if you've never made changes to DNS.

Let me tell you, it can take a minute.

I recently, literally in the last week or two, I've been making changes to

various websites that I own to, you know, change their, uh, DNS entries

and CNAME entries and things like that, and they don't all immediately happen.

Um,

And yeah,

but

they will eventually get there.

That is essentially the database equivalent to, um, to, uh,

asynchronous replication.

Now, let me ask you a question.

Prasanna,

mm hmm.

if replication is so amazing and we can have the tightest RPOs, and, and, and

I think we can agree that Tighter RPOs are better than looser RPOs, right?

An RPO of zero or a minute is way better than an RPO of 36 hours, which is what

we typically get with a backup system.

Why don't we do replication for everything?

And by the way, money is not the issue.

You knew what I was going to say, uh,

It's not, well, it is an issue besides money, right?

Because replication is

yeah, so the

don't we do that?

so the biggest problem with replication is for most of the replication technologies,

when you replicate it, you only have that one copy on your target system, right?

And so, If you had a user who dropped a database table and you replicated that

command over to your replica, guess what?

It gets dropped on your replica as well, and you have no ability to recover.

And

so that's one of the biggest limitations of relying on replication,

or at

And same would be true of any change on the, on the primary system, which

includes things like ransomware, right?

So if there's a, if there's a hacker goes in.

and deletes all your tables, or just, you know, corrupts your, your data,

deletes all your files, whatever.

It just, if a virus does, whatever, whatever, you know, if there's any

kind of cyber attack on the primary system, it simply makes that attack more

efficient,

And because the entire purpose of replication is to create a duplicate

copy on your target system, right?

Immediately, if you ask for an RPO of zero, you're going to get an RPO of zero,

now, now I will say, I will put a caveat that, wait until we talk about snapshots,

we will come back to this specific point,

Right.

There, There, are, there are back backup data protection based systems

that use replication at their core.

And don't have this problem.

This is just, just replication, right?

It's like, why don't we use raid for everything?

And then we don't need backup.

Well, same exact reasons, right?

Exactly.

Uh, raid does help with media failure and equipment failure.

And, um.

Site failure and power failure and, and, and, and, but it is completely defenseless

against cyber attacks and stupidity.

Or logic issues.

Well, I'm just, you're being nice.

See, this is why this is,

Well, I was thinking software bugs, not user logic.

Oh, okay.

Well, that's still stupidity.

It's just, you know, Different

Yes.

person who made the bug.

Um, well, this has been fun.

Uh, but yeah, this whole thing of, um, this idea that replication is where

we're continuously updating the data.

Now, now that you see like this idea of, of, um, you know, why we were wrestling

over the word continuous, right?

Because.

Is asynchronous continuous?

I think it's still a continuous process.

It's just continuous with an asterisk, continuous with, with, with a buffer.

Um, and I think that, well, in fact, I know that today is.

Way better than it was back in the day.

You back in the day, you had to have the same vendor on both sides.

It, it, it sold a lot of EMC, right?

You had to have the same vendor because the replication was based on the box.

And now there are a number of products.

one of which we've had on here, right?

We had Datacore on here, which, which does replication between, you know,

uh, disparate, different architectures.

You can have a very expensive primary system.

And a less expensive target system.

You can use it as a way to upgrade and move your technology.

You can move your older systems to be the target system, knowing that if you

need to use it in a disaster, you will suffer a performance loss, but you

don't have to, like you did back in the

day.

You don't, you know, when you primer, you don't have to have the same, you know,

and so you get, you could cost savings.

You don't have to do it that way, but it gives you the flexibility.

And I think that modern day replication systems are much more

forgiving of things like You know, outages and, and things like that.

Right.

Um, and, but, you know, but they still don't protect you from, you know, mistakes

and cyber attacks, which is why we have to talk about the alternatives, which we'll

do on later episodes, but, uh, so you were, you were unusually, not unusually,

you were excessively argumentative in this episode, but I thank you anyway.

that, that, I try, I basically spent all of my, almost all of my career

working on replication technology, so.

Yeah.

And I, I, yeah, you worked at a company that was like, it was trying

to say, well, there's asynchronous and there's near synchronous.

And I'm like, those are two words for asynchronous.

As I was editing this episode, I realized that.

I was being a little too pedantic about continuous or not continuous.

The thing with replication that really sets it apart from other data

protection technologies, is , one is that the copy is an actual copy.

It is a, it looks exactly like the original, unlike what we do in the

backup world, where we tend to put stuff in a container or something like that.

Um, that's one big thing.

That's separate separates replication from other backup technologies.

And then also the idea is that it is, it is incrementally updating that.

Whenever we do it, whether it's continuous asynchronous or even periodic.

I really forgot about how, like there are vendors like NetApp.

That actually do periodic replication.

There's nothing wrong with periodic replication.

It's still replication.

Um, so you've got continuous asynchronous and then periodic

that, what, what sets replication apart from everything else is this.

Whenever we do the next replication.

What we're doing is we're transferring the, the, the things, whether it's

database records or blocks, we're transferring the things that have changed

since the last time we replicated.

So I hope that.

Helps Muddy the waters.

Just a little bit.

You're either synchronous or you're not just like in.

In the following episode, we will be talking about a

term near continuous, which I actually coined, but, uh, a lot

of people think isn't a thing.

I don't know

if

think, they're like, you can't have...

Then again, they'll say that continuous is a...

Um, is, is, is a binary, uh, condition.

So anyway, well, um, I want to again, uh, say thank you to our listeners.

You are why we do this.

Remember, this is an independent podcast and the opinions that you hear are ours

I hope this episode has been helpful.

That's a wrap.