Cover V07, I02


New Messages

Please send letters via email to

Subject: Error - elaboration needed on 'dump' article
Author: John B. Batzel

In the article "The Other Backup: dump" (Sys Admin 6(11): 27-42), Mark L. Nassal writes of the dump level option:

0 through 9 - Determines the dump level. Zero represents a full backup. The entire file system or directory is archived regardless of the last dump date. dump levels 1 through 9 are used for incremental backups. Only new, or files changed since the last backup are copied during an incremental.

This doesn't adequately describe how the dump levels work. Not understanding the difference between "level" dumps and "incremental" dumps could be catastrophic for administrators. A level 0 dump means "everything." Any other dump level means everything new or changed since the last backup AT A LOWER DUMP LEVEL. This is very different from the concept in the PC world.

Under DOS, files have an archive bit. This bit is set whenever the file is created or changed. When you back up your PC, the backup procedure turns the bit back off. This is an incremental backup. It backs up everything in a series of connected steps.

If I run a full backup Monday, then incrementals on Tuesday and Wednesday, and on Thursday I need to restore a file, I don't know which tape(s) that file is on. It's on Monday's for sure, since that was a full backup. Did it change Tuesday? Did it change again Wednesday? If it changed Tuesday and was backed up on Tuesday's incremental, then Wednesday's incremental will think "Oh, that doesn't need to be backed up." I'd need the entire week's tapes to make sure I have the latest version of the file. I could start with Friday's and work my way back until I found it, but that could still mean sifting through the entire week's tapes.

Under UNIX's dump system, I can run a full (level 0) dump Monday, then level 1 dumps Tuesday through Friday. Tuesday backs up files new or changed since Monday's backup. Wednesday backs up files new or changed since Monday's level 0 backup, not since Tuesday's level 1 backup. Thus, on Wednesday if I need to recreate a disk or directory, I need Monday's level 0 backup, and only the most recent level 1 backup. This is a level backup system. It backs up everything you need to bring you back up to this level from ground-level (level 0).

Level dumps have their downside. If a file gets modified Tuesday, it will appear on each backup tape from Tuesday through Friday. This "wastes" space on the tapes, but makes it much easier to recover the correct version of the files in question. Still, it saves space compared to doing a full dump every day.

At my workplace, we cannot afford to do full dumps of large filesystems every day. Our procedure, in short, is to do a full level 0 dump, once, and do level 1 dumps from then on, until the amount of information that has changed since the level 0 dump will no longer fit on one set of backup tapes. At that point, we do a new level 0, and do level 1s from there. To restore a file or filesystem to a particular date, we need the level 0 backup and that day's level 1 tape. Note that this works best for filesystems with some amount of data that doesn't change much. If everything changed every day, there would be no point to doing things this way.

The dump levels available through the UNIX dump/ufsdump commands are very useful. In and of themselves, they form a powerful part of a powerful backup utility.

John B. Batzel
Systems Programmer
University of Pennsylvania
Computer and Information Science Department
Philadelphia, PA 19104

Point well taken. Levels do indeed add considerable flexibility for the administrator.


Subject: November: Backup or Die
Author: Brad Knowles

As usual, you've produced an excellent issue, but a couple of points bear augmenting. I note that Jonathan Feldman's article "Inexpensive Network Troubleshooting" points people to:, but that version is out of date. A more current version can be found at:

In Bjorn Satdeva's "Questions and Answers" column, he points readers to a program called nslint, but does not provide an URL where that program can be found. May I also recommend another resource, the DNS Resources Directory maintained by Andras Salamon at: If you look on the "DNS Tools Page" at, you'll find a link to where nslint can be found.

In addition to nslint, another useful tool is dnswalk (by David Barr) and/or "doc" (originally written by Steve Hotz & Paul Mockapetris, but which I now maintain). I plan to upgrade "doc" in the near future to work correctly with the version of dig found in BIND 8.1.

Brad Knowles
comp.mail.sendmail FAQ Maintainer Emeritus
The comp.mail.sendmail FAQ is now at

Thank you for your helpful comments. -AA