Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!uokmax!munnari.oz.au!uniwa!DIALix!metapro!bernie From: bernie@metapro.DIALix.oz.au (Bernd Felsche) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: <1991May25.062316.21841@metapro.DIALix.oz.au> Date: 25 May 91 06:23:16 GMT References: <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> <43617@netnews.upenn.edu> <1991May24.013214.2526@servalan.uuc Organization: MetaPro Systems, Perth, Western Australia Lines: 51 In <1991May24.013214.2526@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >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. Depends on the cpio options... doesn't your cpio have -a ? Do you know how to use it? >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... This is a problem with any backup utility I know of, which accesses files through the filesystem. The "holes" are not physical. You have to look at the blocks allocated to check for holes. Mind you, there's nothing that stops a utility from doing it from the filesystem, is there? After all, any run of NULLs in a file can be represented as a relative seek. Heck you could *shrink* files for backup. > 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... More than a subtle difference. We do an image copy of our root filesystem every night onto a spare partition, on another drive. Even with the system idle, an fsck on the copy still reports problems.. nothing serious.. mostly FIFO file size errors. The copy takes 3 minutes. This is archived on tape once a week. -- Bernd Felsche, _--_|\ #include Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au