Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!uokmax!servalan!rmtodd From: rmtodd@servalan.uucp (Richard Todd) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: <1991May24.013214.2526@servalan.uucp> Date: 24 May 91 01:32:14 GMT References: <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> <43617@netnews.upenn.edu> Organization: Ministry of Silly Walks Lines: 51 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. 1. "dump" preserves the access times on files, and "restore" restores the files with the access times set correctly. "cpio" neither records the access times in its archive nor leaves the access times of the files on disk unaffected. Thus, "cpio" screws up any schemes one may have for locating user files that haven't been accessed in, say, 6 months and automatically moving them off to tape and deleting them. 2. "dump" handles files with holes in them correctly (the holes don't take up space on the backup, and "restore" restores the files with holes correctly). "cpio" doesn't. Having all your dbm files suddenly explode in disk usage after having been brought back off of tape is considered bad form in some circles... 3. Just how were you planning to do restores of those incremental backups? Seems to me that the naive approach (extracting the incremental cpio just like the full cpio backups) won't work correctly on directories which have had files deleted between the making of the full and the incremental backup. Say you've got a directory "foo", which had files "a","b", and "c" in it at the time of the full backup, but between that backup and the incremental someone deleted files "a" and "b". In restoring the filesystem after the crash, you read in the level-0 cpio backup, which puts "foo/a", "foo/b", and "foo/c" on the disk. Now you read in the incremental cpio backup, which (because "foo" had files deleted, shows up with a newer mod time than the level-0, and thus gets backed up) has the "foo" directory and "foo/c" on it, and thus foo/c gets written to your disk--but "foo/a" and "foo/b" are not deleted. You have not restored the filesystem to its state as of the time of the incremental backup. This means that you need to do some extra work to make sure that all the stuff you got rid of once gets gotten rid of again. (Note that if you're really unlucky, and had a lot of old stuff deleted and new stuff added between the full and incr. backups, restoring the incremental cpio file will fill your disk.) This just adds to the hassle a sysadmin has to deal with when restoring a filesystem, when usually the sysadmin has entirely too much to deal with anyway... Basically, there's a subtle difference between the goal of "dump" and "cpio". "Dump" is a *backup* program; its function is to save the state of a filesystem in such a way that it can be restored exactly later. "Cpio" is an archiving program; like "tar" or "zoo", its function is to package up a bunch of files in a halfway portable fashion so that they can be transported about easily from one place to another, from one system to another. You can try to press "cpio" or "tar" into service as a backup program, but it's not really the same thing... -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp