Brian Cuttler wrote:
> samar 31# /usr/local/sbin/amrestore -p /dev/sdlt2 samar /usr5/bimal
> | /usr/local/sbin/gnutar -tf -
> amrestore: 0: skipping start of tape: date 20041229 label SAMAR24
> amrestore: 1: skipping samar._usr5_lalor.20041229.0
> amrestore: 2: skipping samar._usr5_tapu.20041229.1
> amrestore: 3: skipping samar._.20041229.1
> amrestore: 4: skipping samar._usr5_amanda.20041229.1
> amrestore: 5: restoring samar._usr5_bimal.20041229.1
> ./
> [...]
> amrestore./cvs_test/spider/man/CVS/
>
> : read error: I/O error./cvs_test/spider/src/
>
> ./cvs_test/spider/src/CVS/
That one's a GTAR DLE, isn't it? Looks as though you're only
partially out of the woods for those...
Try manually dd'ing data from the tape (basically, doing by hand
what "amrestore -r" does). This will help you to determine
whether the data's physically on the tape.
mt rewind
mt fsf N # for some appropriate N
dd bs=32k </dev/whatever >tempfile
(It looks as though the right value of N is simply the number
printed by amrestore; e.g. with the tape you used to generate the
above excerpt, to get samar:/usr5/tapu, use "mt fsf 2").
First, take note of the block counts printed by dd at the end,
and see if they match your expectations. Note that it's counting
the physical blocks it read from the tape; when it says "X+Y",
the X is the number of full-size records it read -- 32 KB since
you said "bs=32k"; the Y is the number of partial blocks, i.e.
those that were less than 32 KB. Since your tape is configured
for variable-length blocks, I *think* I'd expect to see Y=0, i.e.
all blocks being 32 KB long. Ditto if you configured it for
32-KB fixed-length blocks. I'm not sure what would happen if you
configured the drive for shorter fixed-length blocks -- probably
depends on the drive, and its driver, whether it'd:
- emulate 32-KB blocks, i.e. break each one up into, say,
512-byte blocks and reassemble them at read time, thus
yielding "X+0" from dd
- break up the 32-KB blocks, but not reassemble them, yielding
"0+Y" from dd
- write the first 512 bytes of each 32-KB block and discard the
rest, yielding a garbage tape
Then look at the <tempfile> you dd'ed off the tape. Its expected
contents is a 32-KB Amanda per-DLE header (just like the one
you've been successfully getting from amrestore), followed by the
backup of that DLE (either DUMP or GTAR format; compressed iff
you're using software compression on that DLE).
You can check the contents with:
dd <tempfile bs=32k skip=1 | tar -tf -
(or the corresponding "restore" command).
Exception: if N=0 (i.e. if you read the first file on the tape),
you'll get a 32-KB file containing Amanda's per-tape header, and
nothing else.
If the above test succeeds for a DLE that amrestore bombed on, or
vice versa, try both the amrestore and dd tests again a few times
each, using the *same tape*. You might have intermittent
hardware problems (e.g. bad SCSI cables or termination, to name
just two possibilities).
On Fri, Dec 31, 2004 at 12:42:17PM -0500, Gene Heskett wrote:
> And I'd make the suggestion that somewhere in this setup, there is
> insufficient iron to do the job. I don't know anything about an
> SDLT, but if its taking 33 hours of real time, that drive has got to
> be doing a lot of "shoe shining" [...]
I'm not sure about that. It's only 14:34 of tape time, and Amanda
reports 2469.2 KB/sec tape speed. Is that reasonable for this
drive?
> There has been a suggested rule of thumb for tape drives and
> capacities put forth that says that if it takes the drive, in
> streaming mode, more than 3 hours to complete that backup by writing
> a nearly full tape, its too small and slow if its streaming 100% of
> the time.
That might be useful for guesstimating, until one gets better
stats, but I wouldn't depend on it for diagnosing problems! It's
about as scientific as Moore's "law", which seems to hold
surprisingly true, but even so would better be called "Moore's
Observation" -- or as Dave Tillbrook's facetious comment that
"the computer you want always costs $5000" :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics AT telepres DOT com
| | /
The animal that coils in a circle is the serpent; that's why so
many cults and myths of the serpent exist, because it's hard to
represent the return of the sun by the coiling of a hippopotamus.
- Umberto Eco, "Foucault's Pendulum"
|
