John R. Jackson wrote:
>> What would it take to have some sort of config option that did exactly
>> that? ...
>
>
> Nothing. It's already there. Just leave the tape out of the drive and
> make as many runs as you want into the holding disk.
Finetuning:
For the 'holding disk runs' take an other configuratin which differs
only in the tape label string. Amanda will complain, but do the backups
to holding disk (if configured right).
For the 'with tape run' use your original configuraion and try to also
bring the holding disk to tape.
There are several possibilities to do this.
Check out the config options
holdingdisk yes/no
ignore
strategy skip
and consider two different holding disks for the two configs (waste of
disk space, but they are getting so big today :)
Note: this strategy will certainly screw up, if your balance/amount of
backup data/backup cycle etc. tends to be as big as your tape ...
Doublefinetuning:
Have some to-be-written smart script that decides which configuration to
use, according to the load in the holding disk.
eg
crontab:
15 0 * * * /path/to/smartscript
smartscript:
if holdingdisk space is to small
/path/to/amdump to_tape_config && \
mt offline (&& send extra big mail to the guy who changes the tape:)
else
/path/to/amdump to_holding_config
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.
OR:
Use the approach stated somewhere in the FAQ for people who don't trust
their holdingdisks, by backing up normaly only to holding disk with
config 1 and later backing up the holding disk with config 2.
> At your convenience,
> run "amflush" and select "all" instead of a specific holding area
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?
A: "�$!*#@" and then hide some directorys in a newly made cruft
directory and run amflush again. after flushing make them visible again.
( thats the drawback of having a *lot* of incrementals lungering in the
holding disk and waiting for deletion or occasional flushing :-)
> to flush.
>
>
>> Marc G. Fournier
>
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Simon
