Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Studying for Security+ with Darril Gibson's book he says that "A full backup is the easiest and quickest to restore"

Now I've been looking for another test exams and I found the MasterExam of the CompTIA Security+ All-in-one book. One question was A disadvantage of a full backup is? and the right answer was It takes the longest time to restore.

So either Darril or Mc Graw Hill's book is mistaken.

What do you think? Is a full backup the quickest or the longest on restoring?


migration rejected from May 23 '13 at 20:09

This question came from our site for information security professionals. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as not constructive by Xavierjazz, Brad Patton, Breakthrough, Ƭᴇcʜιᴇ007, Tanner Faulkner May 23 '13 at 20:09

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

You're not new here, so I'm gonna spare you the "read the FAQ" drill. Just because it was written in a security book doesn't make it fit for Security.SE. This question is clearly off-topic. – Adi May 22 '13 at 12:44
up vote 7 down vote accepted

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...

  1. Insert Day 1 full backup
  2. Run recovery
  3. Insert Day 2 incremental
  4. Continue recovery
  5. Insert Day 3 incremental
  6. Continue recovery
  7. 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:

  1. The hard drive is really just a file called something like MyServer.vmdk
  2. You take a snapshot.
  3. A new file called MyServer-snapshot0001.vmdk is created, this is often called a delta disk.
  4. MyServer.vmdk becomes treated as read-only.
  5. 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:

  1. Day 1: Copy the system to a backup location
  2. Day 2: Copy yesterday's backup location to today's using hard links.
  3. Day 2: Synchronize the system to today's backup location.
  4. 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.

Isn't the second and third method closer to snapshots then backups. Snapshots can prevent some data loss events (deletion) but not other data loss evens (theft, fire, hdd damage, deliberate malicious action...). (BTW. the delta-disk snapshots can be achieved using lvm, btrfs or zfs with deletion handled in background). – Maciej Piechotka May 22 '13 at 16:49
@MaciejPiechotka: The examples you give for loss events are the same no matter what backup system or type you use. They are also mitigated much the same methods. The second is exactly snapshots, which is why I used the phrasing snapshot in the description. The third resembles snapshots in its final form but is implemented as full+incremental. – Scott Pack May 22 '13 at 16:56
Isn't rdiff-backup just a wrapper around rsync --link-dest? (It sounds like it's meant to handle more things automatically that you'd need args on rsync for, but that it otherwise does the same thing...) – Izkata May 22 '13 at 20:59
@Izkata: It pretty much is. It's just got the extra fiddly bits around the edges to be more resilient than a single command can be. It's clever and simple. – Scott Pack May 22 '13 at 21:09