Gerhard den Hollander wrote:
> How about
> As abovem 2 configs, each identical exept for allowed tapestring;
> if(holdingdisk space is full){
> amflush totape && mt rewoffl && alert-person-to-change-tape
> }
> amdump todiskconfig
i think this should work.
btw:
how do you non-interactivly amflush ?
at my site, we do something like that, but instead of flushing (as it
should be) we leave the incrementals on disk and delete them together
with their index files, if the holding disk space is running low
>
> also, finetune this so that if a holdingdisk is more full than fits a
> single tape, you amflush oldest partitions first until tapefull
> (e.g. by moving the latest dumps to a different dir, amflush nd move back).
to call it by name:
include some errorchecking and foolproofness
>
>> Again:
>> See the note above and have in mind that this can only be usefull for
>> poeple whose backup device capacity is much more higher than the backup
>> load from a couple of days.
>
>
> And for people who can afford to loose a couple of days worth of backups if
> the holdingdisk crashes.
That's true (!!). But at least the data is on two different machines.
And hopefully the holding disk is not crashing at the same time as the
backup client crashes.
>> Q: what to do if "all" is to big, you have more than 26 areas and the
>> one you really want to flush is to new to be listed?
> What do you mean with area ?
John R. Jackson said:
At your convenience, run "amflush" and select "all" instead of a specific holding area.
and I picked up the word area :-)
it means the place where all the backup images of a run of amanda
reside. namely the directory in the holding disk named after the
corresponding date.
> Cannot amflush flush more than 26 areas to tape ?
As amflush presents you a list with the directorys in the holding disk
all with a indicating letter (A-Z) there is a maximum of 26 visible
holding "areas". they are sorted by age (or alphabetically whats the
same in this case). So cou can't *see* the 27th area and therefore can
not flush it. (I DONT know if it WOULD be flushed when you select all)
> Whats the deal with the 26 areas ?
Well, ... uh ... more than 26 unflushed backups ... ?!
As said above, we keep as many incrementals as possible in the holding
disk for no specific reason other than lazyness. As Incrementals are not
big, a large holding disk can hold a lot of them.
> Gerhard, [@jasongeo.com] == The Acoustic Motorbiker ==
Simon
