Hello,
I'm having a strange problem with amrestore. I get an I/O error in the
middle of a restore and amrestore exits, but st0 device remains busy and
only a reboot can clear it. There is an error on the console as
follows...
st0: Error 70002 (sugg. bt 0x0, driver bt 0x0, host bt 0x7)
... My first thoughts were hardware errors, but I've checked out
everything I can (short of buying a new library!) and everything seems
fine. Perhaps more revealingly I have no issues performing backups with
amanda or extracting data from the tape using dd.
Heres the amidxtaped.debug file (I originally experienced the problem
while using amrecover)
## START amidxtaped.debug [extract]
amidxtaped: time 6.803: Ready to execv amrestore with:
path = /usr/local/sbin/amrestore
argv[0] = amrestore
argv[1] = -p
argv[2] = -h
argv[3] = -l
argv[4] = UnixDaily-FHH545
argv[5] = -f
argv[6] = 72
argv[7] = /dev/nst0l
argv[8] = ^myhost.mydomain.com$
argv[9] = ^/export/home$
argv[10] = 20050219
amrestore: 72: restoring myhost.mydomain.com._export_home.20050219.0
amrestore: read error: Input/output error
amidxtaped: time 38.951: amrestore terminated normally with status: 2
amidxtaped: time 38.951: rewinding tape ...
gzip: stdin: unexpected end of file
### END ##
Running the amrestore command manually (redirecting output to a file)
gives the same errors. The command was...
amrestore -p -h -l UnixDaily-FHH545 -f 72 /dev/nst0l
^myhost.mydomain.com$ ^/export/home$ 20050219 1-amrestore-fromtape
The resulting output file is indeed smaller than expected.
Then...
mt -f /dev/nst0l rewind
my -f /dev/nst0l fsf 72
dd if=/dev/nst0l of=2-dd-fromtape bs=4194304 [My tape
block size is 4096k]
...results in the full file being copied from disk with no errors. I
can then extract the dump from the file with amrestore...
amrestore -p -b 4096k -h ./2-dd-fromtape 3-amrestore-fromdd
Which is fine.
In case it was relevent I also tried (by trial and error) to see if the
truncated version from the original amrestore fell on a tape block
boundary - it did (22 blocks including the header). I found this by
truncating the dd'd image then running amrestore on it.
dd if=2-dd-fromtape of=4-dd-truncated-to-22-blocks bs=4194304 count=22
amrestore -p -b 4096k -h ./4-dd-truncated-to-22-blocks
5-amrestore-fromddtruncated
The file sizes from the above can be seen below...
-rw-r--r--1 amanda disk 131203072 Feb 20 15:54
1-amrestore-fromtape
-rw-r--r--1 root root 343932928 Feb 20 16:04 2-dd-fromtape
-rw-r--r--1 root root 498728960 Feb 20 16:11
3-amrestore-fromdd
-rw-r--r--1 root root 92274688 Feb 20 16:15
4-dd-truncated-to-22-blocks
-rw-r--r--1 root root 131203072 Feb 20 16:15
5-amrestore-fromddtruncated
All of which seems to point to some problem with the way amrestore
interacts with the tape device. Has anyone seem this before?
For completeness:
Amanda 2.4.4p4
Tao Linux release 1 (Mooch Update 4) [ Rebuild of Red Hat Enterprise 3 ]
Compaq Proliant 1600R
Overland Powerloader with Quantum SDLT320 drive
Adaptec 29160 Scsi card
My tapetype definition...
define tapetype Quantum-SDLT320 {
comment Quantum SDLT 320 hardware compression off/ blocksize 4m
length 159080 mbytes
filemark 4096 kbytes
speed 15762 kps
blocksize 4096 kbytes
}
[The reason for the blocksize change was to improve speed, it now
achieves speeds approaching the manufacturers quoted ones]
BMRB International
http://www.bmrb.co.uk
+44 (0)20 8566 5000
_
This message (and any attachment) is intended only for the
recipient and may contain confidential and/or privileged
material. If you have received this in error, please contact the
sender and delete this message immediately. Disclosure, copying
or other action taken in respect of this email or in
reliance on it is prohibited. BMRB International Limited
accepts no liability in relation to any personal emails, or
content of any email which does not directly relate to our
business.
