John R. Jackson [mailto:[EMAIL PROTECTED]] wrote: > 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.
And you were correct. This worked just fine.... > 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 OK. This worked. It seemed to dump just fine. There seemed to be nothing in the output that would indicate why the dump has been failing in the past. I'm now wondering if the problem has to do with having more than one dumper dumping at the same time -- I think that it might be that some of the partitions are on the same disk, and perhaps there is a conflict with dump? I will try using the "spindle" values in the disklist to see if that helps solve the problem... Any other suggestions? Thanks, Ricky
