>So, I went ahead and tried to do this:
>$ /usr/sbin/ufsdump 2f - /dev/rdsk/c0t2d0s4 ...
>
>in the hopes that it would show me part of what my error is. ...
FYI, in my experience, debugging this part of Amanda is very hard.
Just a head's up.
I don't think it will matter, but you skipped a couple of args on the
ufsdump command. You do **not** want to use 'u', but you probably
should add 's' and '1048576', i.e.:
$ /usr/sbin/ufsdump 2sf 1048576 - /dev/rdsk/c0t2d0s4 ...
>Note that I was running this su -l'd to the amanda user. ...
That was correct.
>This finished with no problem
>(although some of the output from sed seemed to come _after_ the final message
>from dump saying that the dump was done)
>
>How do I run it as sendbackup would? ...
The pipeline on the client is complicated (this picture does not do it
justice):
+---------------------------> network back to driver
| (messages)
stdout |
dump --------> sendbackup --> [compress/gzip] --> network back to driver
| (data)
|
+---> restore t ---> sed ---> network back to driver
(index)
In addition to the above, stderr from each process feeds back to
sendbackup who has a "messages" connection back to driver. And there
is a fair amount of forking going on to isolate pieces from each other
and avoid deadlocks.
You can run sendbackup yourself, but without the network component I'm
not sure it's really going to show you anything.
>From the comments:
* In interactive (debug) mode, the backup data is sent to
* /dev/null and none of the network connections back to driver
* programs on the tape host are set up. The index service is
* run and goes to stdout.
Look at your amandad*debug file for lines like this:
SERVICE sendbackup
OPTIONS hostname=fortress.cc.purdue.edu;
DUMP /data 2 2002:4:6:7:59:19 OPTIONS |;bsd-auth;index;
Put the OPTIONS (if you have one) and GNUTAR lines in a file (do not put
the "SERVICE" line in it). Then run sendbackup **as your Amanda user**
with "-t" as an argument and this file as standard input:
.../libexec/sendbackup -t < service-file > index-output
My guess is this will also not show you anything. I think the real
problem is that the index connection back to driver has been broken
for some reason (my guess would be some kind of timeout) which filtered
back to that side of the "tee" as a broken pipe and then filtered back
to dump and caused it to fail.
You might be able to simulate this a bit:
.../libexec/sendbackup -t < service-file | head -20
The head command will terminate after 20 lines will will present itself
back up the line as a broken pipe.
We can also test this from the server side. Find the line for this disk
in the "GENERATING SCHEDULE" section of your amdump.<NN> file:
fortress.cc.purdue.edu /data 2 5 2002:4:6:7:59:19 2722448 1995
Put that in a file someplace. Then make (and remember :-) these changes
to your amanda.conf:
* set "record no"
* comment out any tape changer settings
* change tapedev to "/dev/null" (or "null:" if you're using 2.4.3)
Then run libexec/driver as your Amanda user with the config name as the
only arg and the file as stdin:
.../libexec/driver CONFIG < schedule-file 2>&1 | tee test-log
This should reach out to the client and run sendbackup as you did above
but with the network now involved.
When you're done, there should not be anything in the holding disk, but
check just to be sure. Undo the above amanda.conf changes. Then remove
the file named "log" in your log directory (amgetconf <config> logdir).
I didn't test any of the above, but I've used all of the concepts (over,
and over, and over :-) in the past. However I may have forgotten a
piece or two. If you have trouble, just ask.
>Ricky
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
