Today I want to explain the different backup methods and their (dis-)advantages a bit more in detail.
But let’s start with some background information:
The Archive Bit
The archive bit is a file attribute used in Microsoft Windows to flag newly created and changed files. This attribute can be interpreted (and changed) by backup products.
The operating system sets the attribute “A” on all changed or newly created files to “1”. Afterwards a backup software can easily find out that this file needs to be backed up, because it is unprotected in its actual state.
In Linux and Unix based operating systems, the archive bit is unknown and can therefore not be used. Instead the time stamps of the files are used to determine whether a file needs to be protected.
Time Stamps
Besides the idea of using the archive bit for selecting files to be backed up, Backup Exec also supports the idea of backing up files by their time stamp attributes.
To do so, Backup Exec saves the information, when the file backed up was accessed the last time.
If the next instance of the backup job runs, the time stamps of the file to be backed up are compared to the values, Backup Exec has stored in it’s database.If this is the case, the file is backed up. If it isn’t, the file is safely ignored until the next run of the job.
Hint:
You can change the method Backup Exec uses to protect files and folders on a per-job-base.
The selection is found in the register “Files and Folders”.
Knowing the above terms, we can now have a look at the different backup methods:
Full Backups
As its name implies, a full backup makes a copy of every single file from the selected source to your backup target. If you selected to use time stamps as your information base for partial backups, the values of all backed up files are recorded. If you chose to use archive bits, a full backup makes a copy of all files, regardless of the state of the “A” attribute but sets the attribute on all files to “0”. In other words, all archive bits are deleted.
Differential Backups
A differential backup protects all files that have changed since the last backup, according to their archive bit or time stamp. However, a differential backup does not change the archive bits of the files or their recorded time stamps in the Backup Exec database.
Therefore, a differential backup always saves all files since the last full backup.
As an example: A company makes full backups every Friday evening and differential backups every Monday til Thursday. So the differential backup on Monday will back up all files that were changes or newly created since Friday. Since the archive bits (or time stamp records) were not modified during the differential backup on Monday, the run on Tuesday will again back up all new and changed files since Friday. This means, that the Tuesday backup is pretty sure larger than the one from Monday.
In case of a restore, you’ll need to recover the files from the last full backup (from last Friday) and the last differential backup (from yesterday).
Incremental Backups
Just as differential backups do, incremental backups protect all files that are declared as changed or new by their archive b it or time stamp. But in contrast to their differential counterparts, incremental backup jobs delete the archive bit of all saved files (or change the time stamp’s record to the actual date and time). This leads to a different behaviour.
Taken the same example as above but now with incremental backups instead of differentials, the backup on Monday will protect exactly the same files, as a differential backup would. (Every changed or newly created file since last Friday). But since the incremental job has now reset the archive bits or overwritten the time stamp records, the Tuesday instance of the job will only protect files that are created or changed since Monday evening. Therefore it is not possible to say, whether the size of Tuesday’s backup is smaller, larger or of the same size than the backup from Monday.
In case of a restore you have to recover the last full backup (from last Friday) and all incremental backup sets created since then (in the correct order).
This means that files that change frequently are not only backed up every day (which is obviously wanted) but also have to be restored from every single incremental backup. This may not only result in a much larger amount of data to restore but also in a much longer recovery time, compared to a backup concept using full and differential backups.
From real life:
I often get asked, whether I’d recommend differential or incremental backups. My answer is always: “that depends”. But what does it depend on?
Well, actually it depends on the question how you are planning to do restores. Differential backups may take (significantly) longer than incremental ones. On the other hand, restores are, usually, quite faster, if you created differential backups instead of incremental ones.
So, if your backup window allows you to do differential backups, it might be a good idea to do so. Please keep in mind, that the only reason, why we do backups at all, is to be able to run a restore, if we have to.
But if the size of differential backups is too large for you to un every night, you’ll need to switch to incremental jobs – or to invest in your infrastructure…