Hey there! My name is Bradley Knapp and I am one of the Product Managers here at IBM Cloud.
And today we have come together to talk about
backup versus disaster recovery.
This is a really hot topic and what I want to emphasize,
more than anything else, if you stop the video right now,
these are not the same thing.
Please do not treat them that way.
Before we get to far into the video though,
I do want to encourage you, if this is the kinda thing to learn more about,
please do like and subscribe so you can get notified as we put new videos out.
But with that in mind, let's get into backup versus DR.
And so, kinda to start out with,
I want to talk about some differences, right.
So over on this side
we are going to put DR.
This is going to be our disaster recovery side.
And over on this side, this is where we are going to put backup.
These are not the same thing.
Now, they have generally similar goals.
And their goals are both good things.
Their goals are both to protect you
in the event of some sort of failure.
Now, what kind of failures should they protect against?
Very different things.
So, backup, what does..
what kind of failure does backup protect you against?
So, it's going to protect you against, you know, a host failure.
So the actual system that you're running,
if it goes down
you have a backup.
It's not the end of the world, the data is still there.
It will also protect you against some sort of malicious attack,
you know, we will call that hackers.
A very popular attack right now is call the encryption schemes, right.
Where someone will compromise access to your system
They will log into it, they will run an encryption algorithm, they will send you a demand letter.
We are seeing a lots of these going against small governments,
going against good sized governments,
schools, small businesses,
where they get access and then they are going to encrypt your stuff.
If you aren't willing to pay the bounty,
if you aren't willing to pay the ransom,
your only option is to restore from backup.
And that is ok, that is not a problem,
because you've done a good job, you've made good backups.
And again, so what is backup doing?
It is saving you from these kinds of failures.
We're going to call these small scale failures, right.
And maybe that's the big one.
We're just going to call them small.
Now,
if we go over here to our DR side, again,
DR is protecting you against a failure,
but a disaster recovery scenario
is a very different kind of protection.
Backup, you want to backup all of your data, right.
You want to backup everything, small applications, big applications,
development that you are doing.
Everything should be backed up so that the event of one of these
kind of a smaller failure
you do not lose all of the work that you've done.
Disaster recovery, not the same thing.
Disaster recovery, first of all, is really about production applications.
All right.
That's one thing. And what does it protect against?
Well, so backup is protecting against the host failure.
Over here on the disaster recovery side,
this is a whole region failure.
So, what is a region failure?
A region failure would be if
if wherever your production application is running
you have a natural disaster.
Right.
There is widespread flooding, there is widespread cold,
there is widespread..a tornado,
or a hurricane.
Something is going to take that entire region offline.
That is your primary region. That is where you are delivering your service,
or where your production applications live.
your going to declare a disaster
and you're going to fail over from that primary site
to your disaster recovery site.
Now, you can do that with backups.
But it takes a while, it's not a great idea.
And so whenever you've got a production application that requires
very high availability, right.
You can't except the downtime
Your DR site is going to be setup as a standby.
What does this mean?
It means you are constantly streaming production data
from your production site
over to your DR site.
So,
the amount of downtime that you take
that your system is down
is relatively low.
So if we were to compare these two,
you know a backup is a point in time.
Right.
It is, ok, every night at 2AM my application and data
is all going to be backed up and stored in the backup server.
Everything that has changed between 2AM
this morning
and now in the event of a failure
you'll lose it, right.
That's how backups work, it's a point in time.
Disaster recovery is streaming.
And so, maybe, let's call that out right.
Let's say that over here, alright, so this is point in time.
And on this side, this is that streaming side.
Alright, well, guess we have standby, so streaming.
So,
If you're streaming, you're only going to get a little bit
of lost data, as opposed to this point in time snapshot.
So again, it's a much higher availability.
It really solves that problem
of having minimal downtime. For which, for production applications
is absolutely critical.
And when I put standby here, that's
you will have a process to programmatically cross over from production
to DR.
Where we restoring from a backup is almost always manual.
it's almost always done by hand.
There are somethings you can do to automate it,
but you have to figure out, ok we've restored from our backup,
when then have to check and be sure that the backup restored correctly,
that all of the systems connected correctly again,
and that we are backup and running again.
It's a fairly manual process.
Where as declaring a disaster, failing over
should be
automatic, right.
It should be, have as little manual intervention as possible.
Other than someone saying, go.
Someone saying start.
Now, that said,
backups are good for other things.
So let's get our backup color back out here.
What advantages do backup have?
Well, it is a point in time.
And so one of the nice things about it
is that you can restore that
anywhere.
So, if you got an application, of if you got data that you are working on in location A.
You can back that up, you can snap shot it,
you can move that backup over to location B.
And stand it up over in location B and get it up and running again.
This is not a DR scenario.
This is purely about moving applications,
this is about portability
And so when you are evaluation your backup solutions
this is one of those things you need to be taking in mind.
Is this something that I want?
Do I want the ability to restore anywhere?
Do I want the ability to snapshot? Do I want the ability to clone?
And again backup, cloning and snapshotting are kind of technologies that kinda
fall within the backup piece.
But let's go ahead and put them on here because the are important.
So when you're in your development and test process
these are important.
You're going to clone data.
So you've got a copy of what is going on in production
so you can do development and test against it.
You're going to snapshot data.
So, it could be an application consistent snapshot,
it can be a traditional snapshot,
but again, it's trying to capture what you are doing in production
and then do some development and test on it.
This is not a DR kind of scenario.
And many of these tools,
people will talk about them as if they are DR tools,
"like oh, we do not need a whole disaster and recovery site", right.
We have a great backup and retention policy.
Well like I said before, the downside in that is backups take awhile to stand up.
And so, if you are trying to use backup for your DR strategy
what you must ask yourself, the most important question
is "how long can I afford to be down?"
Because if you are going to measure your downtime, right,
we're going to make a downtime distinction here.
Downtime..
..for your DR is minimal.
Along with data loss being minimal.
If your DR strategy is to restore backup in a different location
your downtime isn't going to be minimal.
We're going to call it medium.
Might be medium, might be high,
just depends how resilient you are, how much automation you put in place.
But really, the key for you take away is the difference between these two
is that they have two entirely different use cases,
two different goals.
And so, solving your DR problem can't been with backups.
And DR is not a backup of your production system.
You can't just have a DR site and assume that is good enough.
Your DR site
should be taking backups of the data that lives within it
so in the event of a huge disaster
where your streaming is interrupted or corrupted,
you have data that's here
and if you lose, you know host failures can happen in a DR site just like they can happen in a production site,
you have to protect against that.
So, hopefully that has been helpful and you can design your strategies
in a better way, in a more resilient way
and in a way that solves the needs for you and your business and company.
Thank you so much for stopping by the channel today.
If you have any questions or comments, please feel free to share them with us below.
If you enjoyed this video and would like to see more like it in the future,
please do like the video and subscribe to us so that we will know to keep creating for you.