sl3h7@cc.usu.edu (05/24/91)
cpio backup problems: How to get standard cpio package that will verify multiple tape backup? On some systems, notably those using archive tape drivers, the second tape does not produce a valid verify -- bad magic error encountered. I beleive that the tape driver is reporting that it does a write of the last block on the first tape when in fact it does not. The verify passes the first tape, but after reading a bit of the second tape blows up with the "bad magic, out of sync " error. This error may be avoided by using another program to filter the output to cpio rewriteing the last block of the previous tape. However, on those systems where the last block of the previous tape really is written, the use of the filter would prove disasterous again. What is needed: a standard driver, cpio driver, that works everywhere. Please address responces to Charlie. Standardize, Standardize, Standardize UNIX!!!
slootman@dri.nl (Paul Slootman) (05/24/91)
In article <1991May23.115825.47879@cc.usu.edu> sl3h7@cc.usu.edu writes: >cpio backup problems: > >How to get standard cpio package that will verify multiple tape >backup? On some systems, notably those using archive tape drivers, >the second tape does not produce a valid verify -- bad magic >error encountered. I beleive that the tape driver is reporting >that it does a write of the last block on the first tape when >in fact it does not. The verify passes the first tape, but >after reading a bit of the second tape blows up with the >"bad magic, out of sync " error. This error may be avoided [deleted] > >What is needed: a standard driver, cpio driver, that works >everywhere. To answer the last question first: get afio. It generates archives compatible with standard cpio; you can also tune the blocksize and buffering to get the streamer tape really streaming. You can specify the size of an archive volume, so that the tape is not written up to the physical end of tape. That way you don't lose anything. We use it on all the different systems we have. However, in SCO Unix it is possible to specify options to cpio that does the same as afio: use -K _kb_ to specify the size of an archive volume in kilobytes, -C 5120 to specify block sizes of 5K, -O /dev/rct0 or whatever to write to (instead of ... > /dev/rct0). Check out the manpage for specifics. You can also specify -k when reading a tape to skip corrupt bits, i.e. to read a tape with some data missing. It should go on and search for a magic number, and resynchronize. For the size, take a 5% margin of error. Play around with the block sizes to get optimal throughput. [personal note: I've never used it; I prefer using a command (afio) that's available on all systems I plan to use] Hope this was helpful. Paul.
chip@chinacat.unicom.com (Chip Rosenthal) (05/25/91)
In article <1067@dri500.dri.nl> slootman@dri.nl (Paul Slootman) writes: >In article <1991May23.115825.47879@cc.usu.edu> sl3h7@cc.usu.edu writes: >>How to get standard cpio package that will verify multiple tape backup? >get afio. Agreed. I decided to use afio for backups for two reasons: it supports multiple volumes nicely (which cpio did not do at the time) and it screams. Here are some results I published in my company's newsletter about 9 months back: We benchmarked afio against all the standard XENIX archiving programs. (We didn't benchmark the tar command because we think it's inappropriate for system backups: it can't han- dle directories or special files and archives only regular files.) Our benchmark was to perform a 13-megabyte backup. The results were as follows: command bsize bcount underrun time user system afio 5120 100 2 3:31 2.8 49.0 afio 5120 50 6 3:26 2.9 49.2 afio 1024 100 5 3:22 3.4 58.7 cpio|dd 5120 1 29 4:29 1.6 18.0 cpio -B 5120 1 31 4:32 10.5 42.0 dump n/a n/a 2 3:23 3.1 48.0 bsize number of bytes per archive block bcount number of blocks per device transfer underrun times tape had to stop because no data was available time real time required to perform the backup user user time consumed by the process in seconds system system time consumed by the process in seconds The article points out that the user and system times for the `cpio|dd' trial are bogus - only the first command in the pipeline is timed. Also, this was done on a machine with only 2MB of memory. A larger machine could have handled bigger/more afio buffers, thus probably providing even better results. Even though the cpio shipped in XNX155B (and presumably 2.3.4) supports multiple volumes, I've been so happy with afio that I've seen no reason to switch. The afio I use has two hacks. First, there is a problem in the distributed version that if your archive contains both a directory and a file within that directory, if the file is restored first (e.g. it is encountered in the archive before the directory), then the directory permissions and ownerships aren't properly restored. Glen Hampton implemented a fix for this. Second, I didn't like the way the verbose option listed everything upon a restore - I only wanted it to list the files actually restored off the archive. I'd be glad to send out these two patches upon request. I've heard rumours of a third problem along the lines of defining the media size something other than an integral number of blocksizes causes problems with the multiple-tape handling. Dunno - haven't run into that here. Now that I have the XENIX box on the network...I'll have to see how well afio holds up for network backups! BTW...I'm told (but wouldn't swear to it) that `pax' took the guts of afio to implement its cpio format. That also might be worth looking into. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play so Unicom Systems Development 512-482-8260 | loud, Mr. Collins.