Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!sgi!shinobu!odin!anchor!olson From: olson@anchor.esd.sgi.com (Dave Olson) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: <1991May22.220515.20581@odin.corp.sgi.com> Date: 22 May 91 22:05:15 GMT References: <1991May20.123129.14433@forwiss.uni-passau.de> <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> <1991May21.172208.281@erg.sri.com> <1991May21.213844.12302@ccu1.aukuni.ac.nz> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 50 In <1991May21.213844.12302@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: | zwicky@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.