>I check the status as the process progresses and I found that one directory
>got dumped okay, but the next one hangs at 100.04% :-?

As Olivier said, the value being larger than 100% is not a problem.
The hang, of course, is :-).

>To find out, I made a second config for backing up (and send the dumps to
>/dev/null).  ...

That was a good idea.

You did set "record no" in the dumptypes, right?  Otherwise, this testing
will interfere with the real backups.

>checking the status with amcheck hosting2 tells me that the /var dir is
>backed up okay (first dir.), /etc hangs at 100.04% and /home is waiting for
>/etc to finish.

So the next thing to do is find out what part is hanging.

>After the process has stalled, the gtar program is still listed in the
>process list (ps) for a while, but it quits as well, after about 10 minutes.

Is the sendbackup process still there as well?

Hangs are notoriously hard problems to debug, especially with lots of
processes connected in a complex manner like Amanda sets up.  You'll need
to build everything with debugging enabled (-g on the cc/gcc lines), and
both gdb and lsof tools available on client and server.  After "watching"
one of your backups that behaves to see how things normally move, do
the same to the one that hangs and try to figure out what's different,
where the data is jammed up, etc.

The first thing I'd try is turning indexing off (note that these are
just debugging tips -- I'm not suggesting you'll have to run production
this way).  That will simplify the connections between processes.

What do you have maxdumps set to?  Try setting it to one.

>Can I clean some information on the client (cobalt) for amanda which makes
>it start from scratch? Or is information only stored on the server side
>(using the curinfo and index directories) ?

The only information clients store/update is the listed incremental
files if you're using GNU tar or /etc/dumpdates for dump.  If you've set
"record no", they are not a factor.  Everything that controls Amanda is
on the server.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to