The speed at which a backup restores is highly contingent on the method by which the backup is taken. So in order to really understand how this works out let's consider a few different use cases.
Full and Incremental Backups using Physical Tape
Let's assume you take a full backup of a 40GB system and assume that everything fits on a single tape. Doing a full nightly backup will take quite a lot of time as tape tends to be slow and we're copying 40GB over every, single, night. That means that if the copy takes 8 hours, then every night the system will spend 8 hours backing up. This gives us a total of 56 hours backup time every week.
If we do weekly fulls and nightly incrementals we will only spend 8 hours backing up the first night and then only copy the changes the following nights. Let's assume we have 5 GB worth of changes every day. Files get modified, database entries are added/deleted, etc. Using the above numbers each nightly will only take 1 hour to complete. That's a grand total of 14 hours per week backing up. This is awesome, right?!?
Well, not necessarily. In both cases you'll need to change the tape every day, so you can keep some number of archival backups. You come in in the morning, pull out the Monday tape, insert the Tuesday tape, and Bob's your uncle. What happens if you miss a day? Let's say your normal backup person takes vacation and their stand-in forgets. All of a sudden Wednesday rolls around and writes to the Tuesday tape. You've just lost your Tuesday backup. If you're doing fulls then your Wednesday backup is full and complete, your Monday backup is full and complete, your Tuesday backup is missing. That's probably pretty acceptable.
What about for an incremental? You see, the Wednesday backup tape only contains what changed between Tuesday and Wednesday. So in the A->B->C chain you're missing B entirely, leaving you no reasonable way to advance to C. Suddenly, you're not just missing a single day's worth of backups you're missing an entire week.
What about recovery times? Think about the steps necessary to recover each case. For a full backup you insert the tape, click the magic recover button, or enter the magic command, and wait for it to read off the tape and onto disk. That's it. Go grab some lunch, it'll probably take a while. An incremental requires that you step through each tape. So...
- Insert Day 1 full backup
- Run recovery
- Insert Day 2 incremental
- Continue recovery
- Insert Day 3 incremental
- Continue recovery
- And so on
So not only do you have the full time necessary for the full recovery, but also the time it takes to run each incremental as well as the tape change duration.
So what you're doing is trading backup window time for recovery window and some data loss risk. Technically you could also buy smaller (cheaper) tapes for your incrementals and realize some financial savings, however it's usually just easier to buy a box of the same tape and roll with it. To choose between Fulls and Incrementals you'll need to look at your environment and decide which works best.
Incrementals using Delta Disks
These days we have some funny things going on with things like virtualization. Generally speaking a VM snapshot works like this:
- The hard drive is really just a file called something like MyServer.vmdk
- You take a snapshot.
- A new file called MyServer-snapshot0001.vmdk is created, this is often called a delta disk.
- MyServer.vmdk becomes treated as read-only.
- All file writes are placed into MyServer-snapshot0001.vmdk.
If you use snapshots as backups then taking a backup is all but instantaneous. The only time spent is creating the new file and modifying the VM config to use it as well. Similarly, reverting to backup is as simple as modifying the config to not use the delta disk. The downside is that system reads/writes are slower since the VM has to use both files and know which data to read from which. Also, deleting old backups is tricksome because the delta disks must be merged back into the original vmdk. Depending on the virtualization environment this can be pretty time consuming and may make the system unusable during the merge.
Incrementals using Delta Copies
The easiest to understand implementation of this is an open source project called rdiff-backup. This is a mechanism that contains all of the advantages of both Full and Incremental backups but without the downsides of either. It is a little harder to talk about the advantages of because it is designed to make use of filesystem concepts that are often little or misunderstood. The workflow is something like this:
- Day 1: Copy the system to a backup location
- Day 2: Copy yesterday's backup location to today's using hard links.
- Day 2: Synchronize the system to today's backup location.
- Repeat steps 2,3
So what we're effectively doing is taking a full daily backup but using the backup time window of an incremental. This is because hard links act like, and are treated as, a full copy but are nearly instantaneous. Then the synchronization simply copies the changes. When operating on the backup sets each instance truly is a full backup, so recovery is as simple as copying the data over. There is no need to step through incrementals.
Similarly, because of how hard links work, rotating out old backups is as simple as deleting the backup set. Once the backup completes there are no interdependencies between them. This has the disadvantage of being highly dependent on the underlying filesystem that is used on your backup location. It works quite well on your standard Linux system, but may not generalize well. I have not heard of this method used in commercial solutions, but that is not my area of expertise so I am not overly familiar with commercial solutions.