I've used Amanda for four years or so now in two different contexts,
but I've only recently made the following observation:

If amverify is started before amdump has completed, amflush will
(sometimes, at least) proceed normally, and amdump will be unable to
go on.  Amdump does not, however, seem to terminate in this case;
instead it goes on and on and on, and has to be terminated manually so
that the next night's backups can be run.

I'm using Amanda 2.4.1p1, and this only started happening after I
added so much disk that Amanda sometimes won't finish the dumps in
only 9 hours (the time between amdump and amverify in my crontab).

Of course, this is not too reproducible -- it only happens when Amanda
decides to back too much up in one night.  Also, I *think* I've found
a way to work around this while keeping amverify in my crontab:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.31807 installed on Sat Apr 27 13:21:02 2002)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
3 23 * * 1-5 /usr/local/sbin/amdump nf-amanda
13 16 * * 1-5 /usr/local/sbin/amcheck -m nf-amanda
01 17 * * 1-5 /bin/mt -f /dev/nst1 retension
01 08 * * 2-6 /usr/local/sbin/amstatus nf-amanda || /usr/local/sbin/amverify nf-amanda 
2> /dev/null > /dev/null

This hasn't been tested yet, but the idea is that amstatus should
return 0 ("true" to the shell) if the backups are still running, thus
preventing the execution of the amverify.

Anyway, is this a known issue?  Should one avoid running amverify from
crontab without such measures?  Or have I found a strange bug?

And while I'm at it, are there any good ways to speed up the time
Amanda takes, e.g. by increasing inparallel or netusage?

-- 

Arvid

Reply via email to