Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!munnari.oz.au!uniwa!DIALix!metapro!bernie From: bernie@metapro.DIALix.oz.au (Bernd Felsche) Newsgroups: comp.unix.wizards Subject: Re: Compressed Backups Message-ID: <1991Apr14.073740.23898@metapro.DIALix.oz.au> Date: 14 Apr 91 07:37:40 GMT References: <1991Apr8.194026.29651@gjetor.geac.COM> <1991Apr10.231744.1037@bilver.uucp> Organization: MetaPro Systems, Perth, Western Australia Lines: 38 In <1991Apr10.231744.1037@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >In article <1991Apr8.194026.29651@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >>Awhile back there was some discussion of doing compressed backups, roughly >>along the line of: > >># find . -print | cpio -ovc | compress -v | dd bs=64k of=/dev/rmt0 > >>At the time, there were some warnings posted that, with the usual compression >>algorithm, a tape error would make the whole rest of the tape unusable since >>uncompress would lose sync and the rest of the data stream would be garbage. >Sure. But if you change it around, to find the files, compress the files >and then feed them to cpio as individual compressed files, and compression >failure was result in the loss of that file only, would it not? One disadvantage is that compressing the files individually, is far less effective that compressing a large archive containing them. Furthermore, if you have many small files, archiving and recovery becomes painfully slow, because compress gets started many times. SunOS's bar utility has a compress option which actually calls compress via system(3). (At least it used to, a year or so ago.) This has the additional undesirable side-effect of bombing out, when trying to extract files like "p&l", because the shell interprets the "compress p&l" as something totally unintended. It also forks about insanely, if you have many small files. Obviously, it's a balancing act between available media sizes, convenience, cost and data security. With unlimited cash, I'd probably run an FDDI link to another building, containing a dumb front-end, and a redundant mirrored disk array. Most convenient :-) -- 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