On Tue, 29 Jan 2002 16:12:17 -0500 "John R. Jackson" <[EMAIL PROTECTED]> wrote:
[..] > I looked at the code and that error only comes from one place, when driver > has tried doing a dump once and it failed but was requeued to "TRYAGAIN", > then the second attempt also failed. I'm not sure the message means what > it says, that there really was a problem connecting to the host. That may > have been what it originally meant, but now it might mean other things > (in case it isn't obvious, this code gets a little confusing to navigate). > > I'm pretty sure it has nothing to do with starting a new tapecycle, > except in an indirect way (if at all). My best guess is it has something > to do with the amount of holding disk space you have, or possibly other > activity going on in the holding disk at the same time Amanda is running > (e.g. Amanda thought it had N MBytes but when it actually tried to use > the space, less than that was really there). > > I would need to see the corresponding amdump.<nn> file that goes along > with one of these errors, and possibly all the client logs for that same > run. If you want to contact me offline of the list for this, that's OK. > > In the meantime, you might try dropping maxdumps back to 1. That may > or may not help -- it's just a guess. Hi John, you are right about the "TRYAGAIN", take a look ath an excerpt of /var/log/amanda/DailySet1/amdump.3 at the backup server ---cut-on--- -------- driver: adding holding disk 0 dir /amanda_holding_disk size 512000 reserving 512000 out of 512000 for degraded-mode dumps driver: start time 27.648 inparallel 10 bandwidth 600 diskspace 512000 dir OBSOLETE datestamp 20020126 driver: drain-ends tapeq LFFO big-dumpers 7 driver: result time 27.648 from taper: TAPER-OK driver: send-cmd time 27.648 to dumper0: FILE-DUMP 00-00001 /amanda_holding_disk/20020126/heiner.buero-till.de._usr_samba1_ing__buero.1 heiner.buero-till.de /usr/s amba1/ing_buero 1 2002:1:23:23:46:49 1073741824 GNUTAR 96 |;bsd-auth;compress-fast;index;exclude-list=/etc/amanda/exclude.gtar; driver: state time 27.649 free kps: 590 space: 511904 taper: idle idle-dumpers: 9 qlen tapeq: 0 runq: 13 roomq: 0 wakeup: 15 driver-idle: start-wait driver: interface-state time 27.649 if : free 590 driver: hdisk-state time 27.649 hdisk 0: free 511904 dumpers 1 driver: send-cmd time 42.641 to dumper1: FILE-DUMP 01-00002 /amanda_holding_disk/20020126/heiner.buero-till.de._usr_samba_fax__eingang.1 heiner.buero-till.de /usr/ samba/fax_eingang 1 2002:1:23:23:45:48 1073741824 GNUTAR 96 |;bsd-auth;compress-fast;index;exclude-list=/etc/amanda/exclude.gtar; driver: state time 42.642 free kps: 580 space: 511808 taper: idle idle-dumpers: 8 qlen tapeq: 0 runq: 12 roomq: 0 wakeup: 15 driver-idle: start-wait driver: interface-state time 42.642 if : free 580 driver: hdisk-state time 42.642 hdisk 0: free 511808 dumpers 2 driver: result time 42.643 from dumper1: TRY-AGAIN 01-00002 nak error:amandad busy dumper: stream_client: connected to 192.168.1.25.41043 ---cut-off--- Your guess about the holding disk might be right, because I have only about 500 MB space left which is configured for this amount at amanda.conf. The data to backup are a few :) GB, is there a calculation for the size of the holding disk corresponding to the amount of data to backup? Sorry, I haven't found any amdump.* file neither at the server nor at the client. Well, don't blame me as I am a new user, but what do you mean with "dropping maxdumps back to 1" and how to do that? BTW, the server is a debian with a pentium II cpu at 400 MHz and amanda been installed from source, because debian doesn't have packages for the actual bugfixed release and it has no other jobs to do at night than amanda. ... I hope, that you can tell me to get a bigger holding disk and that this would fix my "could not connect to client" - problem. ... if not, I'll have to ask my boss, if he agrees about giving more information to your hands if you are willing to get them to help me :) :) adTHANXvance Sascha
