Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!att!fang!tarpit!bilver!bill
From: bill@bilver.uucp (Bill Vermillion)
Newsgroups: comp.unix.wizards
Subject: Re: Compressed Backups
Message-ID: <1991Apr10.231744.1037@bilver.uucp>
Date: 10 Apr 91 23:17:44 GMT
References: <1991Apr8.194026.29651@gjetor.geac.COM>
Organization: W. J. Vermillion - Winter Park, FL
Lines: 45

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?

In other words, isolate failure points so a failure will affect only one
file, not all of the files stuffed into one volume.
 
>Also, if you can back up the same data in half the tape, you can probably back
>up the system twice as often and be better covered with the same volume of
>tape.  In fact, you could show mathematically that you're just as well covered
>this way with say a single-tape compressed backup daily as opposed to a
>two-tape regular backup every other day, so long as the probability of the
>compression itself preventing restore is less than 50% (the actual probability
>would be considerably less!).  The exact ratio would vary with the "density"
>of your disk contents, but we have some large data files that give better than
>90% compression.

I have a couple of '386 sites using Xenix that have CTAR installed.

One used to take 2 and a fraction tapes.  Ctar has a compress option that
compresses the files before tar'ing them to tape.   Doing this they went
from  2.25 60 megs tapes to about 2/3 of one tape.   Of course the
compression takes it's toll.  So backup onto the one tape takes about as
long or longer than the backup to the 2+ tapes.

But all is well.  We just tell the system to backup at 11pm, hours after
the lastest workaholic goes home.  Then it reads the entire tape back to
verify itself.  And then mails the results to the administrator.
Requiring almost no effort of the adminstrator makes sure that tapes get
made every day.


-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill@bilver.UUCP