>From the client, I tried amrecover ... >Next, on the server, I tried an amrestore to local disk. ... >Next I used dd to copy the file from the tape to disk and then tried to >gunzip it. Boom... bad format.
Sigh. Sounds like you've pretty much tried the things I would. About the only other thing I can think of is to beg/borrow/steal temporarily a different tape drive and see if it acts any better. You might also make sure the cables are seated properly. And, of course, if this is SCSI, check the termination (not too much, not too little, just right). If it's an external terminator, you might try replacing that -- they do fail on occasion. >I wonder whether I have a scenario where the compressed tar is being >compressed by the HW ... That should not matter. The worst that would happen in that case is you don't get the capacity on the tape you expect. Compression is supposed to be loss-less. >( I have not explicitly turned H/W compression off or >on, maybe the default on an 8505 is on! If so, how do I turn it off ? ) That depends on your OS. On Solaris, it's determined by the device name. On AIX, you issue a "chdev" command before hand. On Linux, it's "mt compression on|off" (although as I look at it, the "mt" man page mutters about sending density select codes -- in other words, you need to find a Linux person to ask :-). >I have given up being able to recover anything written to date, but I really >need to ensure that anything more written can be recovered from. It will be interesting to hear how your non-software compressions tests work out. My guess is you have a hardware problem, probably in the drive itself, or maybe the cable. My sympathies (for what they're worth). I know it's of no help now, but have you run amverify? Mostly I'm interested in hearing if it catches the problem (it certainly won't fix anything for you now). If it doesn't report the error, we need to work on that. >Glen and Rosanne Eustace, John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
