[AUDIO LOGO]
Besides just setting up a secure infrastructure and making sure
you have all your security settings
and controls where they need to be,
how you respond when things go wrong is
a large part of a proper secure architecture design as well.
So we're going to talk about disaster
recovery in this video.
So let's talk about two concepts real quick,
both business continuity and disaster recovery.
Now, both of these tied directly in as well
to the availability parts of our CIA triad.
It's important with these, though, that you also
don't neglect confidentiality and integrity
when responding to disasters.
And we'll talk about that more as we go.
So first of all, what is business continuity?
It's basically how the business can maintain its functions
when something goes wrong.
How do you maintain business processes and functions
during a disaster, during a whatever sort of disruption?
This includes plans for how all of the business processes
will continue during the disaster.
So part of your secure architecture design
is going to include plans on how the business does this.
This includes plans on how to respond to a disaster
and also how to recover from one as well, which brings us
into disaster recovery.
This is basically a process and plans
for how the business will minimize
whatever the effect is of major disruptions or disasters.
You have plans for how the organization will specifically
prepare for, respond, and recover
from whatever disasters occur.
These plans include who is responsible for what.
And a lot of these plans are going
to include how our systems are going to--
how systems are going to be restored,
how is our data backed up in preparation for a disaster.
And how will all of that data be restored as well.
So you have system restoration, which
is tied more towards servers and hardware and applications.
And then, you have your data restoration,
which is just for files and information
in support of all those servers and applications we'll support.
But it all boils down to, how does the organization return
to normal?
How do they get back to where they were
before the disaster happened?
So a big part of what we're going to talk about
for our secure architecture design purposes,
when it comes to disaster recovery and business
continuity, is going to be backups.
So it's a pretty well-established fact
that data is important to any organization.
You need your data for the organization to function.
That's a pretty well-established fact.
But it's also a well-established fact
that data will eventually be corrupted, deleted, modified.
Something is going to happen to your data.
It's not if.
It's when.
Something will happen, whether it's from a cyber attack,
just age of the data, accidental deletion, anything, hardware
failure.
Anything can happen there that will affect
the integrity of your data.
So it is going to happen that something
will be corrupted or deleted.
And that's where your backups come in.
You need policies.
You need procedures for how your backups are performed.
What data is going to be backed up?
How often will these backups actually occur?
And then when needed, how is that data going to be restored
when it comes to that point?
Now, one thing that ties in to a lot of your inventory and asset
management with your backups is the system tiering we've
talked about in other videos.
Most often, your critical systems
are going to take that priority and may actually be even backed
up more often as well.
But in order to be able to identify
what your critical systems are, you
need to have a proper asset management and inventory setup,
and you need to have those systems properly tiered so you
know which ones are critical.
There's a lot of different considerations
that go into setting up a backup program successfully.
What types of backups are you going to be performing?
Where are the backups going to be restored?
What is the destination for these backups?
How often are the backups going to occur?
How often do you back up your data?
And then, how long do you keep that data
after it has been backed up?
How long do you keep those backups?
So let's start talking about the different types of backups
you have.
There's four main types that we're going to talk about here.
We'll start with doing a full backup.
In a full backup, all data that's in scope for the backup
is backed up.
All of the data is backed up, regardless
of when anything has changed or anything like that.
Everything on a particular system
or whatever data is in scope for this backup scenario
is backed up.
This is usually going to be your first step for any backups
before you follow it up with any other type of other backups.
This also is going to be the type of backup that
takes the longest amount of time to perform.
Since you're backing up all of your data,
it's going to take the longest amount of time out of all four
of these backup types.
It is the easiest type to perform
a restore against because there is only one
step for your restoration.
You just restore that full backup,
and all your data is back in place.
So as we go through these types of backups,
we're going to go down the list of backups
in the order of the more granular types of backups.
So the next one we got is what's known as a differential backup.
This is when you backup any files that
have changed since your last full backup was performed.
This is going to be faster, of course, than a full backup
because you're not backing up everything.
You're only backing up what's changed
since your last full backup.
When you're doing a restore on this,
it's usually two steps in the restore.
You have to restore your full backup and then whatever
the last differential backup was in order to get up
to date as much as possible.
So you have two steps in your restore process as opposed
to your one step for your full backup.
Now, similar to a differential backup,
you have what's known as an incremental backup.
This is when you backup any files that
have changed since your last full backup
or since your last incremental backup.
So a way an organization may work it is they
may do a full backup once a week.
Say on the weekend, they do a full backup.
And then every night, they do an incremental backup.
And then on the weekend, again, they do another full backup.
So this is one that, like I said,
backs up any files that have changed
since your last full or last incremental.
This is the fastest type of backup
because it's backing up the fewest amount of files
at one time.
But there can be multiple steps you
have to go through in order to restore these types of backups.
First, you have to restore your last full backup and then
all of the incrementals that add up to whatever point in time
you're trying to restore back to.
So say it is a Thursday.
You do incremental backups all week,
but you do a full backup on a Sunday.
So you have to restore Sunday's full backup and then Monday,
Tuesday, Wednesday, Thursday-- maybe not Thursday's-- but all
the way up till Thursday, you have to restore all of those
incremental backups as well.
So there's multiple steps to do there, depending
on how many incremental backups have occurred
between the point in time you need to restore
to and your last full backup.
So it's the fastest to perform, but it
is the most steps required.
And I think I said a minute ago there were four different types
of backups.
There was actually three types of backups.
I never said I could count.
So don't quote me there.
So let's talk about how often you
might want to perform backups.
Really, you can perform backups--
your organization can decide to perform backups
as often as you like.
There are some standards that happen though.
There are some standard time frames that I've seen used.
You have your annual backups.
These are usually used more for archiving purposes.
At least that I've seen, they're rarely
used for actually doing production restorations just
because they tend to be older than anything that's practical.
But you may have annual backups that are taken just
for archiving purposes.
What's more common is to have a monthly backup.
This, in addition to the annual, is usually still a full backup.
And it's often used as a starting point
for incremental or differential backups.
It can also be used just as your monthly archive backup as well.
You may never use your monthly backup to do a restore.
It depends on what your full schedule is.
Weekly backups are very common.
Usually, when your weekly backups are done,
they can be full backups.
But they're also very often incremental or differential.
All of this is going to depend on what schedule you
choose in your environment.
And that's going to be based on your organizational needs.
All of these depend on when you choose to do your full backups.
So if you choose to do full backups once
a week, then like I said, those are full backups,
and your incrementals happen in between.
Maybe you only do monthly backups
as full backups for archiving purposes.
Maybe you choose to do full backups only once a month,
and everything else is incremental or differential.
It really just depends on what you want to do.
Usually, your weeklies are going to be
used for a lot of your full restores.
If you have to do a complete disaster recovery
scenario where you have to rebuild servers
and data from the ground up, a lot of times,
you're going to have your weekly backups in there.
And then, you can have your daily or nightly backups,
depending on--
they can be called either one.
These are usually going to be incremental, sometimes
differential as well.
They are useful if you need to do things like small restores,
like single files or single folders need to be restored.
Your nightlies, while they are used for disaster recovery
scenarios for when everything goes down,
they're often also used for the smaller restores as well.
So again, a lot of how the restoration process
is going to work depends on what kind of schedule and scenarios
you choose for when you do full backups
versus incremental backups or differential backups.
So we've talked about when to back up.
But now we need to talk about how do we store these backups.
There's a few different ways.
I'm not going to give you a number because you
know I can't count.
There's a few different ways to store your backups.
Usually, with your backup system,
you have a centralized server that's
in charge of the backups.
And the data flows through there to send
to some sort of storage.
So you can have direct attached storage.
This is usually going to be either
internal or external drives that are directly
connected to that system.
This is the easiest way to do the storage for your backups,
but it is not the most secure.
It is often the least secure method.
The reason for that is because if the data is
easily accessible on the network like that,
it is easily corruptible.
It is easily attacked by attackers as well.
So it's the easiest to perform but the least secure.
And you have network-attached storage.
This is good for when you're doing
different types of centralized backups,
when you are trying to keep the backups in a central location
but not just on individual hard drives.
Now, one downside to this is if you do have all your backups
stored on network-attached storage,
then if that site or network fails,
your backups may not be accessible
until you restore the network connectivity first.
Another option you can do is cloud backups.
You can store your cloud--
you can store your backups in the cloud.
There we go.
This has the benefit of combining easy storage
with offsite storage as well.
The cloud is not on your premise.
That's why it's called the cloud.
So it's off site.
And it's fairly easy.
But it does require, again, that network
connectivity for both the backups and the restorations.
And it can be slower to backup or restore the data, depending
on what type of internet speeds you have at whatever site
you're trying to restore or backup from.
And then, you have just straight offline backup storage.
This is the most time-consuming method
of storing your backups but also the most secure method.
A lot of times, this is done through either optical media
or magnetic media, such as tape backups.
Even though that's an old technology,
they're still in use because they are easy to do.
They're easy to take offsite and easy to store.
And they can hold a considerable amount of data.
This is very often used for your most critical data that
needs to have no chance of it being corrupted or attacked
by any sort of cyber attack or anything like that.
And you can also do external drives.
You can take backups and put them on external hard drives
and store them offline as well.
So you can combine maybe your direct attached storage.
And then once you perform the backup,
it turns into offline storage.
So there's several different options for that.
So in addition to backing up your data,
you may need to have backups for physical facilities,
for data centers, and things like that.
And that's where we get to the concept
of hot, warm, and cold sites.
This refers to additional networks,
data centers, facilities that are used in disaster recovery
scenarios.
A lot of times, depending on the type of site and the importance
and the purpose of this site, it should
be geographically distant from either your main office
or where your main data center is.
Now, how far away it is, again, is really
going to depend on the purpose and the importance of the site.
But usually, they are not in the same building or anything
like that.
They usually have at least some isolation.
So let's talk about a hot site.
This is a full replica of all of your production systems.
Your data center is basically duplicated in another site.
These systems are online, and they
are ready for cutover and use immediately.
One of the downsides to this-- yes, it
has good-- it has definitely upsides because everything
is available right away.
It is basically a perfect mirror of your production
environments, including data configurations, everything.
It is a full replica.
It's ready for use right away.
Very expensive to keep a hot site up
like this running all the time.
It can be very expensive because you basically
have two primary data centers at that point.
The hot site requires regular maintenance, regular patching,
regular data synchronization, everything.
Anything you do in your primary site, your primary production
data center, you must also do in your hot site.
Otherwise, it is not technically a hot site and cannot be used
as such.
You can't have it cut over immediately
with minimal downtime.
That's when we start getting and talking about what's
known as a warm site.
This is when you have equipment ready on site.
It's ready to go, almost.
It may take some time to set up.
Maybe this equipment isn't actually powered on.
Maybe it just has the base configuration.
You still might need to do a lot of the configuration.
So the site is ready.
The equipment may be in place.
But the equipment may not be powered on.
It may not be fully configured.
And you still need to bring your data over
from either your backups or your production systems,
depending on what the scenario is.
So this is in between your hot and your cold site.
It is the happy medium, if you will,
whereas this compares to a cold site.
This is essentially a building that is ready for use.
There's no equipment ready.
There's nothing ready to go.
You're going to have to bring equipment over.
You're going to have to get it set up.
The network may not even be established.
You'll have to bring your data over.
But at least it is a physical facility
that is ready to go that you can begin standing all of this up.
So you don't have to start from scratch
in trying to find a location for disaster recovery purposes.
And a lot of times, why you would use a cold or a warm site
is if your primary site is going to be down long term.
This could be for things like natural disasters-- tornadoes,
hurricanes, earthquakes, floods, any of the above there.
That's a lot of the times when you're going
to use a warm or a cold site.
A hot site a lot of times could be
used for just other sorts of failures in your primary site.
Maybe you have a critical or core router
or switch that went down that's severely impacting network
connectivity.
You may have to switch over to your hot site,
whereas your warm site and your cold site
take more time to bring online.
You use those for things that are going
to be a lot more long term.
So there's a lot you need to consider
when you're building a secure architecture, not just
in designing the architecture and the security itself
but how is the organization, the network, and the security going
to respond properly to disasters.
How does the organization keep its business processes
running properly during a disaster?