Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!oliveb!amdahl!rtech!ingres!rca
From: rca@ingres.com (Bob Arnold)
Newsgroups: comp.unix.admin
Subject: Re: SUMMARY: Backup while in multi-user mode
Message-ID: <1991May25.003146.13982@ingres.Ingres.COM>
Date: 25 May 91 00:31:46 GMT
References: <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> <VERBER.91May21181220@avalon.mps.ohio-state.edu> <43617@netnews.upenn.edu> <VERBER.91May22112356@revere.mps.ohio-state.edu> <KJIBZ8B@xds13.ferranti.com>
Reply-To: rca@Ingres.COM (Bob Arnold)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
Lines: 59

In article <KJIBZ8B@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>What I don't understand is why people are still using "dump" to do backups?
>A pretty minimal script using "find -newer level-file" and "cpio" works just
>fine on active file systems.

Is this a serious question?

If it is related to the discussion about potential problems with dump,
find | cpio is vulnerable to sync problems too, because the find is
running ahead of (and much faster than) the cpio.

A more generic answer:

1) dump will not traverse filesystem/NFS boundaries.  So just how am I
supposed to back up the root filesystem with cpio?  Like this ?!?!:
	cd / ; find . -print | cpio ....
Try that on a big NFS server/client sometime.  To make life even more
miserable, many systems without BSD dump also lack BSD find's "-xdev"
or "-fstype nfs -prune" options.

2) cpio's user interface is far inferior to dump/restore for both backup
and (especially) file retrieval.  dump/restore has all this, cpio doesn't:
	a) messages telling the user how much work has been done so far
	(yeah some people might not call this a feature, and dump does
	it in a funky way, but it's better than nothing if you like it)
	b) good media load error handling (write-protected media, etc)
	c) interactive selection of files for retrieval
	d) decent end-of-tape handling (do you want to restart the volume?)

3) dump provides services that cpio doesn't:
	a) tracking of multi-level backups
	b) lists of files that are supposed to be on the tape
	c) access to devices on remote hosts

4) many versions of cpio can't handle multi-volume backups.

5) various vendor wierdnesses with cpio (these are more braindamaged
than most cpio's):
	a) at least one new version of cpio doesn't handle device nodes
	b) at least one version of cpio can't write portable headers
	(the "c" option)

I say all this as someone who has written a backup script to put
multiple filesystems on a single tape.  It works on perhaps 30
UNIX variants.  The part of the script that actually puts backups
on tape is 18 lines when it uses dump and 282 lines when we are
forced to use cpio (both counts include comments).  The extra code
is basically to provide as much as I can of dump's functionality
(sort of as a wrapper for cpio).  Overall, I could probably eliminate
two thirds to three quarters of my code if I didn't have to deal
with cpio.  Now, if I only had the choice :-)

		Bob

--
  __   _    _   Bob Arnold		ASK / Ingres Product Division
|/  \ / \  / \| 			1080 Marina Village Parkway
|    /    /   |				Alameda, CA, 94501
|    \__/ \__/| rca@ingres.com		415/748-2819