If you're responsible for backup and Dr.
At some point, someone is going to tell you about their amazing product based
on continuous data protection or CDP.
They say they can meet an RTO and RPO of zero, which sounds great.
Why don't we do all backups and Dr.
Using this method.
Hi, I'm W.
Curtis Preston, AKA Mister backup.
And I started this podcast to turn unappreciated, backup admins
into cyber recovery heroes.
This episode will answer all your questions about CDP, which
some say is the next great thing.
And Dr.
This is the backup wrap-up.
Hi and welcome to the show.
And once again, I have a guy
who cost me money.
Prasanna Malaiyandi how's it going, Prasanna?
I'm good.
I'm worried about
what I'm going to
be blamed for
now.
Well, I think, I think that, you know,
the, the fact that I
have new AirPods is your fault.
What do you
So,
uh, no.
the fact that
you lost your AirPods.
I think that you
manifested it.
You were suggesting that I needed new AirPods and I think my current AirPods got
upset
and then they literally flew out
of my pocket.
They're like, doo doo doo doo doo doo
Yeah, it was the weirdest thing.
Like, I, I had, like I, I, I've
done.
really good job
with holding on my ear pods.
And then I was,
I was
at a restaurant and, um, you know, having
a date with my lovely wife was great and
I pulled, pulled
the thing out of my
pocket and literally the case, like, flipped,
like, open and the AirPod just went flying.
And I don't, it was, it was such a weird thing that I didn't even realize
it happened when it happened.
It wasn't
until I got home and I realized that both my AirPods were no longer in it
And, uh, yeah, so I just like, in a moment like that I lost my AirPods.
So I think what you need is a case that has one of those clasps on it.
Right?
So you have to undo the clasps in order for it to open.
oh,
Right?
Because just the normal
Silicon ones, I don't think will be sufficient for you.
Yeah,
apparently
not.
But, hey, I've got the new
the new fancy AirPods Pro Generation 2 USB C,
which really should be called Generation 3.
But, You
know, because I had to
very
specifically make sure that I bought the one with the USB C.
well, it's
because the actual thing is the same.
Yeah, well, yeah, but you know what I'm saying.
I mean,
I know
like I was going to buy it at Costco, but Costco only has
the, uh, the older
Shantoos.
Yep.
Yeah,
but,
uh,
Tough life you live, Curtis.
Uh, I'm just waiting to listen to what I'll be blamed for next.
Absolutely.
So,
uh, we're speaking of blaming.
We got blame to go around.
I,
I, I, think we should take credit for this, for this piece of
news.
What do you think?
Oh,
Curtis.
Yes, it's our ability to
expose to the listeners, hey, here's what ransomware is, that...
Yeah, I think you're right.
We...
You think, you think,
But is it a good or a bad thing, though?
That's my question, this article.
well, I actually think
it's a good thing.
Let's, so let's talk about
it.
So the, the headline, and it's from a story in the register.
ransomware
attacks register,
It's a bit, it's funny I realized that the word register was in the
title and it messed me up there.
Ransomware
attacks register record speeds thanks to successive InfoSec
industry.
So when I
first heard that, I
was like Wait,
I, you know, that one, that one literally, uh,
threw me.
So the subtitle here is dwell times
drop to hours rather than days for the first time.
So first off,
do you want to explain what a dwell time is for those of our listeners
that don't know?
Yeah.
yeah, so in the past with ransomware, I think
before
it used to be
measured, like you said,
in days, like four and a half to five and a half days in the
last couple of years.
Right.
But this is basically the amount of time that
ransomware is in your system.
So someone
has attacked, infiltrated your systems, they've dropped a package.
It hasn't done anything though,
Right.
It's just sitting
there and waiting.
Right,
and there
is now while it's waiting it could be
discovering other things, figure out what's important, what's
not but while
it's waiting there's always a
risk that
it could be detected, it could be destroyed, and so previously, like you
were saying, four and a half five and a
half days for the dwell time, that it would just sit in
your environment, not doing
anything.
Yeah,
I remember
when, I don't know if there's a difference.
Well, there's definitely a difference between the average and the mean, but
I remember when the mean dwell time was measured in many days, right?
Like, like
it was like as high as
45.
Right.
And now they're saying that the, uh,
um, you
know
this time, and I don't know if they're using mean or average,
but, uh, it says it's down to
24 hours.
And they're saying, and in more than 10 percent of the
incidents,
It was deployed within five hours The ransomware
was, you know, the actual ransomware part was done within
five hours of the initial attack,
which
is good, right?
Because, like the title said, that means people are detecting it faster, right?
And ransomware crews and ransomware as a
service affiliates, right?
They realize, yeah, we can't just let it sit there.
We have
to Be in and out
as quickly as possible.
Right, yeah, and and that's, that's why the headline,
they're saying, well, because
we've gotten
better at
detecting it,
they've, they've basically
had to realize they've had to,
You know,
once they're in and
they got to
do bad stuff right away.
Otherwise, they're going to, they're going to get detected.
Um, go ahead.
Another interesting fact I
saw in the article was, I know we always
talk about like double extortion,
right?
Where
someone comes in, they encrypt your.
Environment, but they also exfiltrate data, right?
So now
you have to pay,
right?
Because otherwise,
who wants to have their data released?
I think, actually, as we're
recording this,
there is a company that
is potentially going to have
their data exposed
because they
decided not to pay the ransomware operators,
right.
right?
And that's the
double extortion.
Now, in the article though, they said that the times, number of times that
they're seeing double
extortion from the people they've surveyed
is only 13 percent of the
time.
That seems really
low,
but given
you only have 24 hours, maybe
it makes sense.
They don't have
enough time to do more damage.
Right.
Yeah, that, that,
and I see that
as good news, as I'm
sure
you understand, because the, the actual,
the thing I'm worried
most about is the Um, exfiltration because
backup just can't help in
that, right?
Uh, once the data has been
exfiltrated,
all all bets are
off.
So I saw
that as good.
And that part came from the annual threat intelligence report from Microsoft.
So
that
that is really interesting though, is that, um, uh,
the other reason why I think this is a good thing
is that the shorter the dwell
time,
the easier the
recovery.
So when you have a dwell
time
measured in days or
weeks,
And you're doing something along the way,
especially if you're encrypting data
along the way,
how do you recover from
that?
Right?
There's no,
the, the the good point
in time
is three weeks
ago,
right?
Do you do you really want to recover?
your primary file
server, for example?
This was the one I was always
worried about.
If you
encrypt VMs, if you encrypt databases,
it's easy to notice
the moment you encrypt anything, everything stops working
and you know when the
point in time
is.
But if you talk about a file
server
or someone's workstation that has a lot of files
on it, if you're able
to encrypt...
data over
time
and not be noticed, Restoring that is
significantly more
complicated than restoring
an encryption attack that takes place over hours.
So I think this
is a much better uh, scenario.
It does mean we have to continue to
stay vigilant
and to make sure that we're continuing to detect
so that they continue to have dwell times this small.
And this
also goes to the importance of backups,
right?
Cause if it does hit, like you were saying, you want to
be able to restore.
And so if you don't have a
backup that you can restore from.
Then you're going to lose data.
Right.
There, There was another thing here that they were
saying that, you know, because of ransomware as a service uh, businesses,
that they
actually,
it says in June,
they broke the single
month record for ransomware attacks.
Thanks to a single exploit, uh, the MoveIt
MFT exploit, which I actually don't know much about, but that
single exploit allowed them to uh,
break the record of the number of attacks in a month.
That
doesn't sound good.
None of this sounds good, I guess.
It's just,
I do like
a quicker attack because
a quicker attack is, I think.
Easier
to
defend against,
or let me rephrase
that,
a quicker attack is easier
to recover from.
Yeah.
And also a
hundred percent
agree with you, Curtis.
So,
what,
so do you still want to claim credit because of our podcast that
we're helping
improve?
to how
much
we have gotten the word out there that long
dwell times are bad,
that the attackers have
made short dwell times.
You
So any attackers
so any attackers
out there, if you would like to come on the podcast and talk about this,
please reach out and
let us know.
Can you
imagine?
Can you imagine that?
Um, once
again, another thing
from here, once
again,
the two highest
profile attacks of 2023 were the result
of unpatched infrastructure, right?
Um,
we like to talk about on the podcast, right?
yeah, yeah,
MFA, patcher systems,
do
backups.
Exactly.
That would stop the vast majority of
ransomware attacks that we see.
Well, with that, that is the news of the day.
This week's episode is a continuation of our Backup to Basics series,
and this week, we're going to be talking about a Product category
that at one point was red hot.
Was it not?
Do you remember when this product category was red hot?
Like everybody had to have a CDP product.
Do you
I want to say it was like 2002, 2003.
Yeah.
What I remember was being at Storage Networking World and half of the
booths were CDP products, remember
is CDP Curtis or our
yeah, we're, we're gonna, we're gonna talk about that in just
a second, but just the, the.
The sheer number, I remember thinking all of these can't succeed and little
did I know that pretty much almost none of them, uh, would succeed.
Uh,
I want to say there's like four left.
In the world.
Yeah, there's, well, and, and most of them got acquired and
are, are simply a checkbox on, on another product's portfolio.
So what is CDP?
It stands for continuous data.
Protection.
And this was a, you may recall in a previous episode, we talked about
replication and what, as far as I'm concerned, what is the primary problem
with date with replication as a community.
Data protection or a basically a replacement for backup.
What's the primary problem with it?
Whatever you do here happens here.
Exactly.
It is very efficient in replicating stupidity, right?
Uh, or, or, or ransomware attacks or anything in any sort of cyber attack.
So replication is great at giving you a, An RPO of zero, right?
A recovery point objective of zero, but it's also going to replicate
things that happen on a logical level.
Um, and so CDP was born and I describe CDP as replication with a back button.
What do you think of that?
That definition.
I like it, but I used to think I used to, you know what I used to call CDP?
What?
I was like, it's TiVo for your data.
Yeah.
That, but that was, uh, I remember, I remember vendors describing it like that.
Uh, the problem is now nobody knows what TiVo is.
I know that's why I said for the five listeners who may know what TiVo is.
And for the two of us, since we both had TiVos, right.
We understand that name.
And also if you do watch Psych, there is references.
Are there TiVo references in psych?
Oh, yeah,
All right.
Well, you would know better 'cause you've been, you've been binging psych lately, so
but, but, but yes, I agree with your point.
It is a back button for replication.
And specifically what you mean is replication.
Do you have that one copy with CDP?
You can go backwards from that one copy.
To other points in
yeah.
The, the reason why I call it replication with a back button is that, is that
the process of getting the data.
We've discussed that.
I see all of these things as backup.
A lot of people see backup as, well, putting something on tape or a backup
that changes its format, right?
A lot of people try to define sort of old school backup as something that requires
a restore, you know, different ways to try to define what old school backup is.
And...
I just see that as a, that is the old way we did backup.
This is now a new way that
we do backup.
Backup is just a method of putting the data in a different place
so that we can restore it in, in time of something bad happening.
And this is one of the newer ways.
And the, the thing is, unlike traditional backup, CDP is not a batch process.
Traditionally backup ran once a night.
Sometimes you might run it multiple times a day.
You could run it once an hour.
You could run it every five minutes.
Traditionally backup is a batch process.
CDP by definition, that C is that it is happening continuously.
All the time, just like replication.
Although we had some, there were some finer points there where we,
where you and I were trying to argue about on what continuous means, and
the idea is that it is happening truly continuously every time.
A block of data that is changed on the primary system.
It gets replicated to the target system Now, immediately, you know,
Yeah, we can debate that.
That's
this happens, but, but basically this is, it's not a batch process.
It's happening continuously throughout the day.
And then we can talk about how that is stored on the other end.
Uh, how are you okay with that part of the definition?
I'm good with that.
And I think the one other thing we should touch on is.
As technologies have evolved, so has CDP in the sense of we could
talk about where in the stack you're actually triggering or forwarding I.
O.
and the data from.
Typically, right, and way back in the day, right, all these CDP vendors when
you were probably at the SNIA, right, it was all, okay, here's an appliance.
that you put in, right, the writes might come into it, get split off, go to two
different places, right, that's one method that some people would do to make sure you
have two copies, continuously replicating.
Another method that some vendors have used is you sort of write to your
primary, the primary forwards it off to an appliance or to something else which
then writes it on the target system.
Right.
That's another mechanism people did.
All of that is sort of infrastructure level down at the
storage array or networking level.
Actually, some people even did it at like the storage area network level, right.
Where they would have that appliance in the middle, right.
And basically that's that first use case where you would write
to two different storage arrays.
The other thing moving up the stack, right, is with virtualization, people
were like, hey, the same challenges you had with sort of storage level, CDP,
let's do that at the VM level as well.
And so you had technologies that would allow you to split right at a VM level.
You could forward it off to another ESXI cluster in a different location and have a
continuously replicated VM somewhere else.
Right, basically they all, the concept was the same.
The question is, at what point are we going to split the right?
And then take one copy and send it where we would always send it to the
primary storage and the other copy of that right gets sent to some magic
process or box or whatever that will then store it for CDP purposes and.
Sometimes it can happen in the storage array.
There, there have been boxes that you can buy that go between your
storage array and your server.
Sometimes it might be an independent, you know, that box might be
an actual appliance, it might be a piece of software, right?
We had Datacore on here.
Datacore was one of those vendors that you can put the box in, you know, their
software on a box in between your.
Uh, storage array on your server, and it might be in, like you said, it might
be in the hypervisor, it might even be in the cloud, it might be something
that's being done in the cloud.
But the idea is that basically as the, literally as the data is being written,
it gets piped off into two places, and then the second of which is the CDP copy.
Do you consider, since we're talking about CDP, do you consider database
level things like Oracle's Data Guard as CDP or Exchange used to have
something like, what was it called?
CRR and all the rest where a write comes in and they forward over the
log, because that technically is CDP,
That is, that is application level replication.
It is not application level CDP because I don't think that with an active database
that you can just go backwards in time.
I know that if it crashes you can do, you can do media recovery against it.
But I don't think it's built.
So I'll just say if that's built into it, then sure.
Right.
But if it's just replicating the changes and doesn't have the ability
to go back in time, then no, right.
It's not CDP.
That is a very crucial aspect of CDP,
yeah, and one way to think about this is, I know with databases, we
think about redo logs, right, which allow you to go forward in time.
With CDP, you actually want undo logs, right?
How do I go backwards in time from the most recent version on the target system?
That's a really good point.
And I don't think anybody calls them undo logs.
So everybody calls them either redo logs or transaction logs.
No, I mean, in, in the
Oh, database.
um, they call them redo logs or they call them transaction logs, because
the idea is that you, you have a.
It allows you to have a backup, a traditional backup from this
point in time and then use those logs to redo the transactions
that happened during that point in time and since that point in time.
But with CDP, you are correct, the most important thing is to be able to go
back in time, which is not something that a typical database replication
scenario is going to be able to do.
You mentioned the ability to go back in time.
How far back in time should we be able to go with ACDP system?
Depends on what your requirements are, right?
I would say with the CDP system, it depends on what other environments
or infrastructure you have.
For instance, if you have backups, right?
That you're taking periodically, separately, outside of the CDP system.
Your CDP system may only need 7 days worth of data, so you can recover
within those 7 days at, sort of, uh, I.
O.
granularity.
Right.
Or a record granular or whatever we want to call it.
Right.
Uh, but as long as you have that backup system, that's fine.
Going back, say 30, 90, or trying to replace your backup system with the
CDP system is a little crazy because I think we need to talk about what's
required on the target system or on the target side in order to handle CDP.
Right, because in order to be able to go back in time, I need much more
storage at the target side than I need at the primary side, because
if I'm doing a hundred terabytes of storage, And I'm, and I'm
going to do CDP for that.
How much do you, because realize at that target side, I need to store the
hundred terabytes and every block.
That changes in that 100 terabytes during that
Date.
continuum that you've set,
Yeah.
And so that's why you would see sort of, and I think on the target side,
we should probably differentiate depending on what technology, right?
Your target system itself may not need all the extra space, but maybe that
target appliance, which is dealing with these transactions coming in or
these change blocks coming in, that might need to hold the space, right?
Uh, sort of as a log.
And this is really, this problem right here is why CDP, I think,
failed in terms of the dream of CDP.
The dream of CDP, because I remember meeting with CDP.
CEOs, and they were like, this solves everything, We can
recover to any point in time.
Why would you do it any other way?
And the answer is cost.
It's the cost because, because the thing you have to think about is
you have to store the data, right?
Not only with the metadata about what came in, the data that's there,
but if these are undue, right, you also need to store what the previous
data was as well, because you have to be able to go backwards in time.
And so you have to store all of this information in that appliance and.
Some people say that you might have like a 2 percent change rate per day.
That doesn't mean that that's 2 percent that's 2 percent over the entire day.
But if you're adding up every single transaction, right, that might turn
out to be like 5 percent actual change.
Right.
Or 10%, right?
if you have anything, if you have a block updated, if we're talking about
block level CDP here, which is generally what we're talking about, if a block
changes multiple times during the day, you have to store every version
of that block throughout the day.
And, uh, you're right.
It could be a significant percent.
And by the way, you have no idea what that number is until you deploy CDP.
Right.
The other,
and
the other thing I know you were just mentioning about sort of, you don't know
what you'll need until you deploy it.
You also have to deploy it on pretty fast and expensive hardware, because if
you think about it, you're getting this constant stream of rights that you have
to store and you have to replay it down to your target storage location as well.
And so your destination system might need to be beefier or the infrastructure
required might need to be beefier than what you even have on your production.
Right?
So going back to that cost aspect, that starts to add up pretty fast.
yeah, this, we can go back to the episode on replication.
The synchronous and asynchronous aspect is important to understand here.
So generally CDP will be done asynchronously.
Do you remember synchronous CDP?
I think there was one vendor who did it, but yes,
okay.
So you could do, but I do, I think most people do it asynchronously.
And the point is, asynchronously is fine.
Obviously your RPO won't be zero.
It'll be something close to zero.
But the problem with asynchronous is if the target system gets behind
in those rights at some point, you know, the buffer is getting back.
At
your back pressure is going to have to, yeah,
Yeah.
That's a good term.
The back pressure.
I like that.
Right.
You, you will eventually have more rights in the buffer than the size of
the buffer, which would then essentially it then becomes a synchronous or
you have to start dropping rights.
Because
which you don't want to do.
be slowing down the primary system.
So you'd end up having to dump the buffer and you'd end up
losing bits along the way.
And that's just, that's just not something that you would want to do.
Now, one of the benefits I would say, though, with the CDP like
approach is you can do this sort of CDP to Dissimilar systems, right?
So you might be going from like a NetApp to an EMC, or you could be
going from a pure to a Hitachi.
So it gives you flexibility because the CDP applying software package,
whatever else, just needs access to devices on both sides, right?
It's doing all the replication, it's managing everything.
So for cases where you're looking to deal with uh, different costs or
availability of equipment, right?
It is an option rather than sort of being locked into a particular vendor.
Right.
Most of the CDP vendors that I know.
Uh, are, are independent of the storage, right?
So you can use whatever storage you want on, on both sides.
The thing is, I mean, we've, we've been, we've been harping on
it for a little bit, but I mean, the, the idea of CDP is amazing.
The idea that I can just go back to any point in time is amazing.
And I don't have to do anything special on the front end.
Um, but it does come with these downsides.
And so there were some things that happened over.
As CDP was deployed in more and more environments, customers, I
think, demanded certain features.
One of them was this term called right coalescing.
Do you want to talk about that a little bit?
Yeah.
So write coalescing is, I know Curtis, you talked about before where you had
multiple changes to a single block.
That would happen.
Uh, and that's great.
But at the end, would I need to replay something?
I don't need to know all the versions, right?
I could just say, look, just give me this version of the data.
That's all I care about.
And so being able to reduce down some of that data.
So maybe instead of having every transaction for the last
seven days, maybe for the last.
36 hours, I have every transaction, and then after that I'm going
to coalesce writes down.
So I have singular points in time rather than having every single
point in time available to me.
Because honestly, if I go back seven days, do I really care about this I.
O.
versus this I.
O.?
Right?
Like, how do I even find that point in time, you know?
That's the biggest challenge as well.
you'll be happy to have anything.
So you could start with true CDP.
You could, you could always replicate every change.
The system holds on to a certain amount of, you know, all of the
changes for a certain amount of time.
Configurable by the customer.
And then it starts coalescing and saying, okay, we're just going to
make sure we have all the blocks we need to represent this point in time.
And you might go with hourly snapshots after they're not snapshots, but
they're not snapshots in terms of what we traditionally think of as
There are point in times, yeah.
There are points in time.
So you have hourly points in time that you can recover.
And then maybe you go to daily and even weekly.
And that's where some CDP systems, that's what, that's the way some
CDP systems were trying to push out that amount of time that they could.
Essentially replaced the backup system.
But even then it's just not, doesn't really think the way of a regular
backup system would, and so it still ends up storing a lot more data.
And just being more costly in general.
I know, I remember another challenge with CDP systems is with backup.
I know we talk a lot about application consistency, right?
Making sure I have a application consistent point in time that Oracle,
for instance, can quickly recover and I don't need to worry about media
recovery and all the other processes.
With CDP systems, A lot of them missed out.
Now, they've gotten better, but back then, none of them really supported
application integration in a proper way.
Yes, some would do VSS integration to allow you to do like poor bands
backup, but for the most part, they were CDP systems operated
at an infrastructure level.
And so, it didn't have that capability that, honestly, like, as a backup
person, you cared about the application more than the storage, right?
You needed to make sure I had an application consistent backup that I
knew was good that I could recover from.
Yeah, exactly.
One of the challenges is that you say, well, you give me
infinite recovery points, right?
I just want one good one, one point when I know that the the CD,
a lot of the CDP products started integrating more with the database.
So that while they could still give you the infinite point, they could
say, Hey, we also put the database in backup mode at these points in time
so that we know that that point in time is one that is truly consistent
that you could, uh, recover from.
You, you could also use the other points in time, but we're giving you this one
that we know for sure that it's good.
It's special.
so, yeah, it's, it's special, right?
It's still not a snapshot, but it's a point in time when we can say
that, uh, when we can say that we know we can recover to that point.
One other thing about backup, right?
I know we always talk about test your backups, test your
backups, test your backups.
CDP becomes difficult to test in most environments.
Unless you have a lot of additional space and storage, because you don't
necessarily want to stop the copy being updated on the target site.
So now the question becomes, how do I now spin up a separate copy with
that particular point in time that I'm interested in so I can test and verify,
is my Oracle database backup, right?
Is that a good point in time or not?
Exactly.
Yeah.
So it was like, it gave you, it, it gave you almost too much.
Right?
the thing that it gave you that nothing else could give you except
for replication was that RPO of zero.
But it did come with other op it, it came with other.
Complications that you had to, to deal with.
It's like, I often say in IT, we never fix problems.
We just move them.
Right.
So, so we, we solved one problem.
We created, we created some others.
So the other thing I want to talk about is how the.
The, how the data was stored on the target end.
There are two ways, as I understand it, that data was stored on the other end.
There were sort of two ways that the recovery system manifested itself.
One was that there was a volume that we were continuously updating so that if you.
needed to do a recovery, that volume was already replicated to the point in time,
the most recent point in time that you wanted to restore to, and then it also
had a log and the ability to undo that.
Uh, that volume, undo the changes to that volume so that you could take this,
this LUN, right, bring it back in time.
That was the one thing that was, that was really cool.
The, the advantage to that method was that if what you wanted was
right now, you had it immediately.
If you wanted to go back a little bit earlier and the farther back you wanted
to go, the more work had to be done.
And so the longer the recovery took, but that, uh, was the
primary, I think that was the most common way CDP manifested itself,
Yeah.
And I think, like you mentioned, that's a great...
opportunity because most of the times you're probably recovering to the latest
or somewhere near the latest point in time, rather than, hey, I need to go back.
Let me restore all my data from three weeks ago and now replay all
my backups going forward, which leads to a much longer time to recover.
Exactly.
There was this other way where they didn't create the volume that there was no volume
that they were continuously updating.
They essentially had all of the bits necessary to create
the volume at any time.
And then, I, I, this feels very NetApp y, and, and, right, although, and by that
I don't mean this is the way NetApp did it, it's just, you know, the way with
NetApp is, is a given snapshot is really just a bunch of pointers to blocks at
a particular point in time, right, and it's so, when you restore a volume To
a particular point in time, all you're doing is moving all the snapshots.
What they're doing is they have all of the bits and pieces that are necessary to
represent the volume at any point in time.
And then you,
Stitch it
you just had to create all the pointers, right?
There was no, there wasn't to restore so much as there was this,
I don't know what to call it.
It's unlike anything I've ever seen.
I really need a whiteboard.
I think too.
To illustrate this method, the real advantage of this was that
the recovery time was always the same regardless of whether or not
you wanted to go to the most recent point in time or three weeks ago.
because you're just at that point, just manipulating pointers and metadata and
not actually copying and restoring data.
And I know that some of those systems They also, we started talking, we started
using this term copy data management when we started talking about some of
the systems because they could say, hey, here's this, here's this volume from
this point in time and from this point in time and from this point in time, and
you can have all three of them at the same time because you could not do that.
That was the other feature.
Of the other method.
You could not have the same volume at multiple points in time.
This method allows you to have as many, no, you think you could.
There are ways with newer technologies to get that.
One method.
Some vendors used was to update that copy, take a snapshot
and present the snapshot out.
Right, so that's one method.
Now, not always the most optimal, but yeah,
right.
Yeah.
I was just thinking that like a single volume can't be presented at multiple
points in time, but you're right.
If you do a snapshot, then yes, you could do, you could do exactly that.
but it's more management
did it like that?
I said, I wonder what vendor was really good at doing snapshots.
So CDP, Continuous Data Protection, is the system that allows you to have an RPO
and an RTO of zero without the risk that you have with replication, where, where
if you have the, something bad happening to your primary data, Uh, from a logical
basis, you, you drop a table, you do something stupid, you get a cyber attack
that it gives you that power that you had with replication, but it also gives you
the power to be able to go back in time.
So it gives you basically the best of both worlds.
It gives you an infinite number of recovery points, but an
infinite turns out might not.
I like it.
Anybody living space.
Yeah, that exactly.
See, you know where I was going.
yeah, exactly.
Uh, but it.
It turns out that infinite is, is not as amazing as it seems.
Infinite number of recovery points comes with its own challenges, but the biggest
challenge I think with CDP is just cost.
That very few people were comfortable with The cost of using CDP as their only data
protection method for a given set of data.
And so they would, what you would most commonly see is we're only going to
use it for our most critical apps.
Or we're going to use it, but we're also going to use a traditional backup.
Because that's what we're, I don't know, I don't know about you, but I,
I'm always on the lookout for something that can do, that can give me everything
that I want, give me that long term retention to be able to go back when
I realized that I did something stupid three months ago and also have an
RPO and an RTO of, of close to zero.
on a unicorn.
I want a unicorn, but there are, there are ways, and we're going to talk about
some of those ways, to give you an RPO and an RTO way better than what we
traditionally had without perhaps the cost and the, the downsides and the
logistical challenges that CDP offered.
I think in the end it cut, there are CDP products, and for certain
applications, for certain environments, It's like the way to do it, right?
It's just, I think what you're seeing is the complexities of this
and the costs associated with this.
This is why it's still a niche play.
And that's why there's only a handful of these products available out there.
What do you
I agree.
Yes.
All right.
Well, hopefully, uh, for those of you that have always wondered what CDP is, now
you know, and now you know why it didn't solve all problems in data protection.
But I would just say, if you want an RPO and an RTO of zero, and you don't want to
have the issue with replication, right?
Which means, right, we've already talked about the, if you don't want to have
the issues that replication causes, then Uh, CDP is really the only game in town.
So hopefully this honest assessment of CDP will allow the very small
percentage of you that need it to know that sounds exactly like what I need.
Uh, and with that, that's a wrap.
The backup wrap up is a production of backup central.com where you'll find my
blog and a list of services I can provide.
This is an independent podcast.
And any opinions that you hear are those of the speaker and not necessarily
any companies that they work for.
We'll see you next week on the backup wrap up.