Hmmmm, that is really strange. It does appear to me, however, that
your dumpcycle has changed from 0 to 1 (although not sure I'm reading
the diff results correctly). If this is the case, my gut feeling is
that this has something to do with it. My general feel is that
changing from a zero to a non-zero value can mean something
significantly different. Just a hunch.
Although it still occurs for me now and then, it's my understanding
(unless this has been changed in newer versions of AMANDA) that zero
level dumps should never be written to holding disk. The fact that it
is routinely writing zero level dumps to holding disk seems to be a
problem in itself.
I would guess a dumpcycle of 1 would insist on a full backup every day
not even dumping to holding disk when there is no tape because "can't
change to incremental dump". I don't know what dumpcycle 0 would mean
in contrast other than (given your experience) telling AMANDA to do a
full dump everyday yet change to incremental dump when no tape is
available.
I have to agree with you that, because it IS writing to holding disk,
AMANDA at least seems to be getting the message that there is no tape.
Not at all certain this is any help :)
Paul
->>In response to your message<<-
--received from Will Partain--
>
> Hi, all; have had a running Amanda for years which (a) tried for a
> full backup every night [dumpcycle 0], but (b) I often didn't put in a
> tape, so I got incrementals on the holding disk instead. What I
> wanted.
>
> I just upgraded my server to FC4's stock 2.4.5, and now it won't go
> into degraded mode for love nor money. Full dumps (with a tape in)
> work as expected; other times, it just starts packing level-0 dumps
> onto the holding disk until it runs out of space.
>
> The changes to my amanda.conf (diffs below) seem innocuous; the
> "reserve 100" seems to be seen (log says "reserving 8616884 out of
> 8616884 for degraded-mode dumps").
>
> I _think_ it is correctly seeing that the tape isn't there...
>
> driver: result time 120.963 from taper: TAPE-ERROR [tape_rdlabel: tape
> open: /dev/nst0: Input/output error]
> dump of driver schedule before start degraded mode:
> --------
> --------
> dump of driver schedule after start degraded mode:
> --------
> --------
> driver: state time 120.963 free kps: 2000 space: 8616884 taper: DOWN
> idle-dumpers: 4 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 86400 driver-idle:
> not-idle
>
> ... but I could be wrong.
>
> Any ideas how to figure out what's changed (for the worse)? Thanks,
>
> Will
>
> partain% svn diff -r227 amanda.conf.tmpl
> Index: amanda.conf.tmpl
> ===================================================================
> --- amanda.conf.tmpl (revision 227)
> +++ amanda.conf.tmpl (working copy)
> @@ -30,6 +30,25 @@
> # B -> biggest bandwitdh
> # try "BTBTBTBTBTBT" if you are not holding
> # disk constrained
> +
> +taperalgo first # The algorithm used to choose which dump image
> to send
> + # to the taper.
> +
> + # Possible values:
> [first|firstfit|largest|largestfit|smallest|last]
> + # Default: first.
> +
> + # first First in - first out.
> + # firstfit The first dump image that will fit on
> the current tape.
> + # largest The largest dump image.
> + # largestfit The largest dump image that will fit on
> the current tape.
> + # smallest The smallest dump image.
> + # last Last in - first out.
> +
> +displayunit "k" # Possible values: "k|m|g|t"
> + # Default: k.
> + # The unit used to print many numbers.
> + # k=kilo, m=mega, g=giga, t=tera
> +
> netusage 600 Kbps # maximum net bandwidth for Amanda, in KB per sec
>
> dumpcycle 1 # the number of days in the normal dump cycle
> @@ -46,6 +65,7 @@
> ### ### ###
>
> bumpsize 20 Mb # minimum savings (threshold) to bump level 1
> -> 2
> +bumppercent 20 # minimum savings (threshold) to bump level 1
> -> 2
> bumpdays 1 # minimum days at each level
> bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
>
> @@ -156,6 +176,7 @@
> # reserve 30 # percent
> # This means save at least 30% of the holding disk space for degraded
> # mode backups.
> +reserve 100 # we don't want full dumps landing in our holding disk
>
> autoflush no #
> # if autoflush is set to yes, then amdump will schedule all dump on
>
--
Paul Yeatman (858) 534-9896 pyeatman AT ucsd DOT edu
==================================
==Proudly brought to you by Mutt==
==================================
|
