One common requirement for anyone
in information technology is that you always have
a good set of file backups.
One way to manage this backup process
is for your backup system to know
what files have changed since the last backup
and which files have stayed exactly
the same since the last backup.
The way that it's able to make this determination
is by looking at the archive bit that's
associated with each file.
If that archive bit has been turned on,
then that particular file has been
changed since the last backup.
If you're performing a full backup,
then obviously you don't care very much about
whether the archive bit is set or not.
You're going to back up every single file
from the entire file system.
And when you perform that full backup,
you're usually clearing that archive bit
so that the next time you come through,
you'll be able to tell all the files that have been changed.
This becomes useful if you're performing
an incremental backup.
This is going to grab all of the files that
have that archive bit set since the last incremental backup.
There's another type of backup called a differential
backup that will perform a backup of all of the files
that have that archive bit set since the last time you
did a full backup.
Here's how this works with an incremental backup.
On Monday, for example, we'll perform a full backup.
We'll backup every file from the file system
and we'll clear all of the archive bits.
On Tuesday, we'll perform an incremental backup,
which will only backup the files that have changed
since the last full backup.
On Wednesday, we'll backup all of the files that have
changed since Tuesday's backup.
And on Thursday, we'll backup all
of the files that may have changed
since Wednesday's backup.
This means if we need to perform a full recovery of this system,
we will need the full backup from Monday
and the incremental backups from Tuesday, Wednesday,
and Thursday.
A differential backup works a little bit differently.
We'll still perform the full backup exactly
as we did on Monday.
On Tuesday, we will take a differential backup
of everything that's changed since the last full backup.
On Wednesday, we'll take another backup of everything
that's changed since the last full backup.
And on Thursday, we'll take another backup of everything
that's changed since the last full backup.
With each of these differential backups,
we're backing up everything that's happened
since the last full backup.
So we'll be backing up everything
on Wednesday that was also backed up on Tuesday.
And on Thursday, we'll back up everything
that was also backed up on Wednesday and Tuesday.
So there is a little bit of redundancy
in these differential backups.
The benefit is when you have to recover the system.
Instead of taking all of the differential backups
throughout the week, you simply need
the full backup that was created on Monday
and the last differential backup that
contains all of the differences since the last full backup.
Let's summarize those backup systems.
We know a full backup is going to backup everything
on that file system.
It is going to take quite a bit of time to do that.
The restore time, though, is relatively low,
since you only need to take the entire set of tapes
and back them up at one time.
Once you perform a full backup, all the archive attributes
are cleared.
An incremental backup is going to backup
any new files and any files that have been modified
since the last full backup or the last incremental backup.
This means that you will have a low backup time, especially
on the daily backups.
But if you need to restore them, you
need to get all of the incremental backups that
were created since the last full backup.
And any time you perform this incremental backup,
you're going to clear the archive bits.
And a differential backup will be backing up all data modified
since the last full backup.
This is a moderate backup time and a moderate restore time
because you don't need any more than two sets.
The last full backup and the last differential backup.
And the archive attribute, as you're
performing these differential backups,
is not going to be cleared.
If you're working in the virtual world,
you've got other options for providing backup and recovery.
When you're working with cloud-based systems,
these virtualized environments are constantly
being built and torn down.
You can take a snapshot of that system
and it will save the configuration
and/or the data at any point in time.
That means if you ever have to go back
to a particular point in time, you simply restore back
to that snapshot and you'll have exactly that configuration
from that point in time.
This allows you to roll back to a known good configuration
where you might keep the data in place,
but you're changing the configuration
of the cloud-based system to an earlier point in time.
Or you may be able to boot from a completely new system
and restore that snapshot to another device,
providing another option for recovery.
Of course, there will be business decisions
made about how long it takes to restore
to a particular point in time.
A good value to know, then, would
be the MTTR, which is the Mean Time to Restore.
This might also be called the mean time to repair a system.
You also might be concerned about how often
these failures might occur.
So you may want to have some way to calculate the mean time
between failures, or MTBF.
This might give you an idea of when
you might predict the next outage that would occur.
Or if you're working with a third party
or you have a contract to maintain systems,
you may have a pre-defined service level agreement,
or SLA, that says that certain devices will
be available for a certain amount of time.
And if there is an outage, that outage
will be resolved within a certain amount of time.
That makes sure that everybody knows what the expectations are
when there is an outage.
And if those systems happen to be out for longer,
there may be a contractual penalty associated with that.