>How to read the tape to see if any data ever made it on - besides the label.
The easist way is like this:
mt -f /dev/whatever rewind
amrestore -p /dev/whatever no-such-host > /dev/null
This will ask amrestore to find an image for host "no-such-host" and
send it to stdout. It won't, of course, find a match, but along the
way it will read all the images and report the ones it skips.
>... I get no printou and no mail message.
Are there any core files in either /tmp/amanda or the amanda.conf
directory?
The program that generates both printouts (I assume you're talking
about lbl-templ?) and E-mail is "amreport", and it may be rerun by hand.
See the man page.
>... I couldn't read the tape when it finished, but that may be
>something to do with the blocking factor.
You'd need to provide more details for us to provide any help. Like how
you tried to read the tape and exactly what happened (e.g. any messages).
>I verified the tape drive worked by using amlabel to label a
>tape. And, after a run of amanda was not successful, creating a tape
>archive directly to the the tape with "tar --create --file /dev/nst0"
I assume you ran amlabel again, then? Amanda will only accept tapes that
have been processed by amlabel.
>I would look through the runtar.DATESTAMP.debug file and see something like:
>
>running: /usr/bin/tar: /usr/bin/tar --create --file /dev/null
>--directory / --one-file-system --listed-incremental
>/usr/local/var/amanda/gnutar-lists/roberta__0.new --sparse
>--ignore-failed-read --totals --exclude-from
>/usr/local/etc/amanda/csd/exclude.gtar .
>...
>I tried to see if the tape was actually writing to /dev/null instead
>of the tape device, but that seems to be irrelevant. Amanda does use
>the TAPEDEVICE specified the "--file /dev/null" is for some other
>reason.
The /dev/null is used for doing the estimates. Amanda runs gtar one or
more times to /dev/null to find out how large a full dump will be, how
big the same level as yesterday will be and so on. For the "real" run,
--file will be "-", i.e. gtar will write to stdout. Amanda collects
that and sends it to the tape server via the network (even if it's the
same machine).
>I made the amount of data I was dumping much smaller. For some reason
>this time I could see that the data was being written to the tape. (It
>has a yellow light that blinks when data is being written.)
This all fits with your etimeout being too small. If Amanda could
not get estimates, it would not have done any backups. Going with the
smaller amount of data may have also made the estimate go fast enough.
>To see if it had actually written anything to the tape this time I
>tried to manually reposition it with the mt command and to manually
>run the tar command to see if there was anything ont it. ...
You can't do that. There is a 32 KByte Amanda header at the front of
each file. See the docs/RESTORE file or "the chapter":
http://www.backupcentral.com/amanda.html
>sendsize: debug 1 pid 15431 ruid 2 euid 2 start time Sun Jun 24 12:11:42 2001
>/usr/local/libexec/sendsize: version 2.4.2p2
>calculating for amname '/', dirname '/'
>sendsize: getting size via gnutar for / level 0
>sendsize: spawning /usr/local/libexec/runtar in pipeline
>sendsize: argument list: /usr/bin/tar --create --file /dev/null --directory /
>--
>one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/robert
>a_
>_0.new --sparse --ignore-failed-read --totals --exclude-from /usr/local/etc/am
>an
>da/csd/exclude.gtar .
>Total bytes written: 204554240
>.....
>sendsize: pid 15431 finish time Sun Jun 24 12:20:41 2001
The important thing to note here is that it took nine minutes to do
this estimate. That gives you a rough idea of how fast (or slow :-)
gtar is on your system.
Amanda only did a level 0 estimate of this disk. It could do up to two
more estimates (same as yesterday and one level higher). These should
be faster since they are "only" estimates, but I wouldn't bet on them
being a whole lot faster. So it seems to me an etimeout of around 1800
would not be unreasonable for your configuration.
The amandad*debug output more or less matches this problem. Amandad got
a duplicate request, which was planner getting tired of waiting. And the
errors at the end are amandad trying to send the response back but there
wasn't anyone listening any more.
Your debug files with the higher estimate time seem to be OK.
>Josh Kuperman
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
