Red Hat Bugzilla – Bug 86081
amrecover/amrestore fail to read tape properly
Last modified: 2014-08-31 19:24:48 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: Attepting to read backup images off a tape with amrecover/amrestore fails with: amrestore: error reading file header: Input/output error Version-Release number of selected component (if applicable): 2.4.2p2-9 How reproducible: Always Steps to Reproduce: 1. Make a backup with amanda (eveuything will be reported as A-OK) 2. Try to read the tape the next day: [root@riesling holding_disk]# mt -f /dev/nst0 rewind [root@riesling holding_disk]# amrestore /dev/nst0 Actual Results: amrestore: 0: skipping start of tape: date 20030216 label yorkgroup05 amrestore: error reading file header: Input/output error Expected Results: A bunch of amanda dumps should be on my holoding disk from the tape. Additional info: I did find a temporary work around that may also offer some insight into what is wrong here. (Thanks to robin on amanda-users for posting this): $ amadmin config info host drive Take note of the tape and file number of the data you want. With the proper tape in the drive: $ mt -f /dev/nst0 rewind; mt -f /dev/nst0 fsf filemarker $ dd if=/dev/nst0 skip1 bs=32k of=backup.tar.gz And viola, your backup is now sitting on your disk as a tar file, just like amrecover/amrestore should have been able to do. So, this work around gives us several important pieces of data. 1. amdump works. 2. the tapes/tape drive are/is good. 3. when doing the dd, an interesting message is printed: dd: warning: working around lseek kernel bug for file (/dev/nst0) of mt_type=0x72 -- see <sys/mtio.h> for the list of types Is there some kernel bug (2.4.19) that dd knows about, but amrestore does not?
lseek() has never worked on tape drives. Amanda knows this. dd didn't know that until it tried to use it to skip forward. I'm investigating the problem on an Itanium system using a Sony AIT-2 drive. If I run amrecover immediately after putting a tape in the drive, it fails. If I do a "dd bs=32k < /dev/st0 > /tmp/tapelabel" after I insert the tape but before I run amrecover, it works fine. So I suspect a tape device driver problem. What kind of tape drive are you using. The problem is probably specific to certain tape drives.
I am using an external SCSI VXA-1 drive. Strangely enough, the drive died of a bad power supply capacitor shortly after I made this report. The replacement drive has not shown this problem yet. So it could have been a hardware thing. But I can read all of my old tapes (written with the "bad" drive). I will try to read the tape that was written before the failure tomorrow (I just got it back from Exabyte today in the mail). If I have any luck in reproducing this with my new drive I will let you know. Thanks.
I just reproduced this bug with the replacement drive. (It is almost like it knows when I am testing it... This time we were restoring for real and we had to use the magic trick above to get the data off the tape.) Are you sure Amanda knows that lseek is broken? If it does, why can't it compensate like dd does?
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.