We run AMANDA for many years with the same taper and the time comes with
more and more users until one tape per day is sometimes not enough. :-/
We don't have any changer and often one tape is enough. So I would like a
mode where AMANDA would decide it is not possible to have everything on
one tape *but* would not stop dumping and would go on on the holding
disk. Then the autoflush mode would flush everything the day after or a
manual flush could be done on a separate tape.
The problem is that when AMANDA notices that there is not enough space on
tape, it stops with messages such as:
minou.info.enstb.org /var lev 0 FAILED [dumps
too big, 180301 KB, but no incremental estimate]
minou.info.enstb.org /home lev 0 FAILED [dumps
too big, 3309778 KB, but no incremental estimate]
pei.info.enstb.org /mnt/bonbonne/subversion_backups lev 0 FAILED [dumps
too big, 1414910 KB, but cannot incremental dump new disk]
minou.info.enstb.org /export/bouteille lev 2 FAILED [dumps
way too big, 4632849 KB, must skip incremental dumps]
I'd like to have incremental and even level 0 dumps on the holding disk,
where I have a lot of space.
I've played recently with
maxdumpsize -1 # Maximum number of bytes the planner will schedule
# for a run (default: runtapes * tape_length).
but it doesn't help since it says it can decide to dump more than a tape
but it fails later with the same messages than above.
So, is there an obvious way to deal with the not-so-frequent overrun we
encounter?
If not, what about adding a new strategy with a mode such as:
dump-on-holding-disk-if-degraded-mode yes
Should not be to difficult to implement.
I will try also to play with the reserve keyword next night with, for
example, reserve 50 % for full backups.
reserve number
Default: 100. The part of holding-disk space that
should be reserved for incremental backups if no tape
is available, expressed as a percentage of the
available holding-disk space (0-100). By default, when
there is no tape to write to, degraded mode
(incremental) backups will be performed to the holding
disk. If full backups should also be allowed in this
case, the amount of holding disk space reserved for
incrementals should be lowered.
But if it works, why this static allocation between incremental and full
backups?
Another approach: what about also a mode with runtapes > 1 without any
changer, assuming that the user will use amflush later?
Thank you,
--
Ronan KERYELL |\/ Tel: (+33|0) 2.29.00.14.15
Département Informatique |/) Fax: (+33|0) 2.29.00.12.82
ENST Bretagne, CS 83818 K GSM: (+33|0) 6.13.14.37.66
F-29238 PLOUZANÉ CEDEX |\ E-mail: rk AT enstb DOT org
FRANCE | \ http://enstb.org/~keryell
callto:ils.seconix.com/rk AT enstb DOT org
|
