Compressed Backups

[Bernd Felsche]

In <1991Apr10.231744.1037 at bilver.uucp> bill at bilver.uucp (Bill Vermillion) writes:

>In article <1991Apr8.194026.29651 at gjetor.geac.COM> adeboer at 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 <std/disclaimer.h>
Metapro Systems,              / sale \  Fax:   +61 9 472 3337
328 Albany Highway,           \_.--._/  Phone: +61 9 362 9355
Victoria Park,  Western Australia   v   Email: bernie at metapro.DIALix.oz.au