nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) (11/12/90)
Looking through the NCR SA scripts (Tower 32 UNIX V2 1 & 2) for tape backup/restore of files I found that they handle multiple volumes by building a list of the first set of files which will fit on the first tape and then the next etc. Whats wrong with using cpio -oTV /dev/rtp ? Is the only reason they did it that way because they wanted to customise and fully control the interface ? Or is there something wrong with cpio -oTV /dev/rtp ? For instance I was considering the following command to backup the contents of a directory which I hope to squeeze onto one tape but may well take two. find . -print | cpio -o | compress | cpio -oTV /dev/rtp and restore using something like cpio -iTV /dev/rtp | compress | cpio -imu Any thoughts ? Better ideas ? Regards -- <<<<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>>>> << Post: Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia >> << Phone: +61 3 829 6090 E-mail: nigel@cnw01.storesys.coles.oz.au >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
vernon@ssi600.lonestar.org (Vernon E. Hurdle) (11/13/90)
nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes: > Or is there something wrong with cpio -oTV /dev/rtp ? There is/was a problem with the 'TV' options when writing to 150MB tape drives. The backup appeared to work just fine, but when you tried to restore, the file on the break contained errors. Also, the famous 'tape does not appear to be in cpio format' message usually appeared after processing the file on the break. We have had no problems however using the 'TV' option on 45MB tape drives and as far as that goes, we have had no problems with the 'O and I' options in SysV.3 on any of the tape drives. ################################################# # Vernon E. Hurdle (vernon@ssi600.lonestar.org) # # Seay Systems, Inc. Dallas, TX # #################################################
wescott@Columbia.NCR.COM (Mike Wescott) (11/13/90)
In article <1124@cnw01.storesys.coles.oz.au> nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes: > Whats wrong with using cpio -oTV /dev/rtp ? > Is the only reason they did it that way because they wanted > to customise and fully control the interface ? > Or is there something wrong with cpio -oTV /dev/rtp ? The problem is not with cpio but with tape drives/controllers. They are not consistent among themselve on when errors occur and what has been written to the physical tape when these errors occur. Without some consistency there is no way for cpio to know what is on one tape and where to begin the next. -Mike -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
greg@tcnz2.tcnz.co.nz (Greg Calkin) (11/13/90)
In article nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes: >Looking through the NCR SA scripts (Tower 32 UNIX V2 1 & 2) for tape >backup/restore of files I found that they handle multiple volumes >by building a list of the first set of files which will fit on the >first tape and then the next etc. > >Whats wrong with using cpio -oTV /dev/rtp ? There is nothing wrong with the early version of it, but versions from 2.0 (or so - not 100% sure which version) on tower32's didn't work with multiple volume. When we upgrade, we automatically install the old version of cpio on our machine. >For instance I was considering the following command to >backup the contents of a directory which I hope to squeeze onto >one tape but may well take two. > >find . -print | cpio -o | compress | cpio -oTV /dev/rtp Buy a 150Meg tape drive :-) There are other backup systems people have mentioned like afio. dd and a bit of sneakyness could work, possibly through a named pipe ? Also, we have a little utility called cpiofilt that filters out multiple copies of linked files and creates a script linkcomms which is backuped last. This script contains the required link commands to rebuild all file linkages. There is even a sln version of this. This saves multiple copies of the file on backup. If you have linked files, this is VERY handy. Backups are run thus find . -print | cpiofilt | cpio -ovc | compress | dd of=/dev/rtp obs=100k Have fun -- Greg Calkin, Systems Engineer and Dreamer (greg@tcnz.co.nz) Thomas Cook N.Z. Limited, PO Box 24, Auckland CPO, New Zealand, Ph (09)-793920 Disclaimer : Would you buy a used car from someone with these opinions ?
ra@intsys.no (Robert Andersson) (11/13/90)
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