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.