Graeme Humphries wrote:
Here's what amstatus says about it:
server:/dir/problemshare/ 0 600000k dumping 32k ( 0.01%)
(16:06:27)
The estimated size is out to lunch, because it's never actually finished
backing up from this location before. Also, this was copied at 16:27:53
my time, so it's just been sitting there for 20 minutes doing nothing.
This share is also set to "estimate server"?
Was this behavior the same before, with the older AMANDA-release?
On the client server, I can see the following in the process listing:
31183 ? S 0:00 /usr/lib/amanda/sendbackup
31185 ? S 0:00 \_ /usr/lib/amanda/sendbackup
31187 ? S 0:00 | \_ sh -c /bin/tar -tf - 2>/dev/null |
sed -e 's/^\.//'
31188 ? S 0:00 | \_ /bin/tar -tf -
31189 ? S 0:00 | \_ sed -e s/^\.//
31186 ? D 2:48 \_ gtar --create --file -
--directory /dir/problemshare/ --one-fil
It looks the same as the other dump jobs that are happening
simultaneously (and working!).
The same thing happened in my test from last night, and in the summary I
got mailed, it said this:
/-- librarian /projfiles/rndprojfiles/ lev 0 FAILED [data timeout]
sendbackup: start [server:/dir/problemshare/ level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/tar -f... -
sendbackup: info end
\--------
Does anyone have any ideas what's causing it to die right at the start
of the job? The client is a RH9 (Fedora Legacy) box, with tar version
1.13.25, which I read as being supported.
Any ideas on how I can further debug this would be *greatly*
appreciated, as it's the last thing I need to sort out before making
this system live.
I'd try to increase the values for dtimeout (and maybe etimeout) for a
start ...
You should also be able to dig up more infos from your logfiles (lookup
the parameter logdir in your conf, it leads you there ...).
Stefan
--
Stefan G. Weichinger
AMANDA core team member
mailto://[EMAIL PROTECTED]
--
oops! linux consulting & implementation
http://www.oops.co.at
--