Hi!
A long long time ago, in a galaxy far away, I wrote how I
got problems with amverify after replacing the tape drive,
even though amrecover always worked 100% OK. You can see my
original message below.
Just wanted to report for the sake of list archives that
I finally found the solution. I had to set the blocksize
of my DDS drive to 'variable' (mt blocksize 0). This setting
seems to be often recommended on this list and now it has
saved another day.
----------------< Original message >----------------
From: "Toomas Aas" <toomas.aas@r...>
Date: Wed Jan 15, 2003 12:24 pm
Subject: amrestore problems after replacing tape drive
Hello!
Please CC: any possible replies to me. I sent subscribe request a
couple of hours ago, but nothing seems to have happened yet.
I'm running Amanda 2.4.3b4 on FreeBSD 4.7. And yes, I understand that
'b' means beta.
Yesterday I replaced the tape drive in the backup server. The old drive
was HP C1537A (DDS3). The new drive is IBM DDS4, actually a re-badged
Seagate 0624 drive. I also started using DDS4 tapes. I made no changes
to any configuration files (yet). I'm using dump and restore as the
backup software. The drive is set to do hardware compression.
The backup ran for the first time tonight. The output that amdump sent
me after the backup looked entirely normal, and also I could restore
some files from the tape with amrecover. However, amverify is not
happy (see output at the end of message).
When I tried running amrestore directly from the command line, the
following happened:
kuller# amrestore /dev/nsa0 kuller.raad.tartu.ee /
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
kuller#
The messages are returned immediately, without any kind of delay I
imagined would be involved in dealing with the tape drive.
I ran 'mt status' and got the following:
kuller# mt status
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000 DCLZ
---------available modes---------
0: 0x26:DDS-4 1024 bytes 97000 DCLZ
1: 0x26:DDS-4 1024 bytes 97000 DCLZ
2: 0x26:DDS-4 1024 bytes 97000 DCLZ
3: 0x26:DDS-4 1024 bytes 97000 DCLZ
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0 Record Number: 64 Residual Count 0
kuller#
It seems that my tape drive uses 1k blocks. Assuming that this is the
same blocksize which is used by amrestore, I tried telling amrestore to
use it, but it refused:
kuller# amrestore -b 1k /dev/nsa0 kuller.raad.tartu.ee /
amrestore: minimum block size is 32k
kuller#
Is it possible that amrestore can't read the tape because it has been
written with too small blocksize? Or am I barking under completely
wrong tree here? It doesn't seem to be hardware problem, because, as I
said, I can back up with amdump and restore with amrecover, the only
thing that doesn't work is amrestore (and thus, amverify).
Unfortunately I don't remember what the blocksize reported by 'mt
status' was with the old HP DDS3 drive.
Finally, as promised, here's tonight's amverify output.
-----------------< cut here >-------------------------
Tapes: PAEV11
Errors found:
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
PAEV11 ():
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
amverify PAEV
Tue Jan 14 23:16:55 EET 2003
Loading current slot...
Using device /dev/nsa0
Volume PAEV11, Date 20030114
Checked kuller.raad.tartu.ee._var.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Checked heerold.raad.tartu.ee._.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Checked kuller.raad.tartu.ee._usr.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Checked kuller.raad.tartu.ee._.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Checked heerold.raad.tartu.ee._var.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Checked heerold.raad.tartu.ee._usr.20030114.0
** Error detected ()
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 0: reached end of information
** No header
0+0 in
0+0 out
Too many errors. Advancing past the last tape...
-----------------< cut here >-------------------------
--
Toomas Aas | toomas.aas AT raad.tartu DOT ee | http://www.raad.tartu.ee/~toomas/
* One way to be happy ever after is not to be after too much.
|
