Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!ucbvax!bloom-beacon!eru!hagbard!sunic!nuug!isncr!ra
From: ra@intsys.no (Robert Andersson)
Newsgroups: comp.sys.ncr
Subject: Re: Whats wrong with cpio -oTV /dev/rtp
Message-ID: <1990Nov13.083006.8943@intsys.no>
Date: 13 Nov 90 08:30:06 GMT
References: <1124@cnw01.storesys.coles.oz.au>
Organization: International Systems A/S, Oslo, Norway.
Lines: 30

nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes:

>Whats wrong with using cpio -oTV /dev/rtp ?
Two things.  
The first one is that several tape drives and controllers
and/or NCR's driver software handles end of tape unreliably.  In porting
stuff like GNU tar and afio to the Tower I was bitten by this problem.
End of tape appears to some times be reported back to an application,
and sometimes not, and when it is indeed reported, exactly what partial
data made it to the physical tape is rather vague.
The second one is that it is slow, not near making the tape stream.

>find . -print | cpio -o | compress | cpio -oTV /dev/rtp
Not recommended.  I try to do backups as cleany as possible, compress
is not 'clean' in this respect.  Suppose your building burns down, the disk
is gone, but you are left with a tape that is *partly* destroyed.  Now, if
it was compressed, being able to read parts of it wouldn't help.  Having
it uncompressed, you at least have hope of saving some of your files.

If backup *speed* is your main concern, use the afio program available 
from the comp.sources.unix archives.  It really makes the tape stream,
and cu backup times by approx 40% on our machines.
If you want to cut down on the *number* of tapes, some sort of incremental
backup scheme is probably the way to go.

Regards, Robert.
-- 
Robert Andersson       Voice +47 2 371055       International Systems A/S
ra@intsys.no           Fax   +47 2 356448       P.O. Box 3356
...!{uunet,mcsun,nuug}!intsys.no!ra             0405 Oslo 4, NORWAY