Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!rutgers!rochester!kodak!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: Date: 25 May 91 15:59:45 GMT References: <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> <43617@netnews.upenn.edu> <1991May25.003146.13982@ingres.Ingr Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 56 In article <1991May25.003146.13982@ingres.Ingres.COM> rca@Ingres.COM (Bob Arnold) writes: > In article 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? Yes. > 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. Yes, but cpio doesn't produce a bad archive when it gets out of sync. > 1) dump will not traverse filesystem/NFS boundaries. So just how am I > supposed to back up the root filesystem with cpio? We don't back up the root file system. We back up /sys, /etc and /net, so we retain config files, but otherwise if the root file system gets blown away we use it as an opportunity to copy in a clean one. We work hard on keeping all our systems looking the same, and as a result backing up root is a waste of time. > 2) cpio's user interface is far inferior to dump/restore for both backup > and (especially) file retrieval. That's why we use pax. > 3) dump provides services that cpio doesn't: > a) tracking of multi-level backups Trivial. > b) lists of files that are supposed to be on the tape Redirect the output of cpio to a file. > c) access to devices on remote hosts We're on a network that provides transparent UNIX file system semantics on remote hosts, and another thing that puzzles us terribly is why people put up with junk like NFS and RFS. > 5) various vendor wierdnesses with cpio (these are more braindamaged > than most cpio's): That's why we use pax. And another advantage to cpio is that it sticks to the traditional UNIX tools approach. Why use one big integrated program when you get so much more flexibility from a script built out of tools. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"