SUMMARY: Backup while in multi-user mode
Dave Olson
olson at anchor.esd.sgi.com
Thu May 23 08:05:15 AEST 1991
In <1991May21.213844.12302 at ccu1.aukuni.ac.nz> russell at ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
| zwicky at erg.sri.com (Elizabeth Zwicky) writes:
|
| >Using tar instead of dump buys you extremely little. tar will skip
| >active files, which means they won't corrupt your backup. This is its
| >sole advantage, and its only an advantage over some versions of dump.
| >It will *also* skip files with names that are too long; depending on
| >the version of tar you are running, it may also exhibit various nasty
| >other problems dump doesn't have. On the whole, dump is safer.
|
| Would some knowledgable person care to comment on bru in light of Elizabeth's
| comments above. We use bru to back up our SGI 4D/240S with 6GB disk (five
| 1.2 GB drives) We back up one drive a night and do an incremental on the
| rest. The system is usually fairly quiet when the backup is done (in the
| small hours) with only a small number of batch jobs active.
|
| We have had no trouble, yet, and have had to restore a disk on two occasions
| in the last year.
This should be no problem, as long as you don't run into filename length
limitations. bru has a limitation of 127 chars for the pathname length.
bru behaves similarly to tar when files change size while they are being
backed up.
bru also tends to be somewhat :) wasteful of tape, using about 25% more
tape for typical files than tar, due to the checksums, etc. that it does.
Most versions of tar limit you to 100 chars of pathname (which
might be relative or full path); the POSIX version, which should be showing
up on various systems (such as IRIX 4.0) has 255 char limit. I have NEVER
seen a version of tar that skips 'active files'. Files that grow between the
time tar stats them and finishes writing them will only have the original
length; those that get shorter via truncations and rewrites will be padded
with nulls to the original size.
One of the main limitations of bru and tar relative to dump (for some people)
is simply that they typically take longer, since they go through the filesystem.
This is much more evident when many small files are backed up for most
unix systems, as the open time becomes dominant.
tar also suffers from the limitation (in many peoples minds) that it is
difficult to do incremental backups. bru has the ability to backup
files on mtime, but this misses ctime changes, such as owner or
permission changes.
--
Dave Olson
Life would be so much easier if we could just look at the source code.
More information about the Comp.unix.admin
mailing list