Re: Multiple storage-definitions, generating archive tapes

I use two separate backup configurations. One for weekly backups and one for yearly archival.
The weekly i start from crontab and the archival one i start manually with "sudo -u amanda amdump archive".
Each configuration has its own storage definition with tape names starting with R or A ( ^A[0-9]{5}$ ) respectively.
They share holding disk but i always flush it so it is only used for slow DLEs to avoid the drive starting and stopping a lot.

Is that what you are trying to do or did i read incorrectly?

Anton "exuvo" Olsson
    [email protected]

On 2022-08-23 10:15, Stefan G. Weichinger wrote:
> Am 10.08.22 um 08:52 schrieb Stefan G. Weichinger:
>
>> What I try:
>>
>> storage1 should leave the lev0 backups in the holding disk after writing to tapes in pool1
>>
>> storage2 should be allowed to remove them when written to the tapes in pool2
>
> Does noone else use multiple storage definitions?
>
> I have it in 3 sites now, various configs.
>
> The main one is the one with the "split tape changer": 4 tapes for daily, 4 tapes for archive
>
> The current plan:
>
> * storage1 (daily) uses
>
> runtapes 1
> dumpselection ALL ALL
>
> and runs monday to friday
>
> -> do incrementals and fulls in mix, only use 1 tape/day
>
> * storage2 (archive) uses
>
> runtapes 4
> dumpselection ALL FULL
>
> and runs on saturday (or sunday)
>
> -> only write FULLs to the tapes, use 4 tapes to get all DLEs onto one set of tapes
>
> -
>
> I don't get all fulls into the holding disks so I have to use "holdingdisk never" for some DLEs (there are Veeam vbk files on one LVM volume, and one holding disk is another LVM volume in the same VG -> no sense to copy that anyway).
>
> What I try to come up with:
>
> how to trigger fulls on the weekend?
>
> I plan to use "amadmin archive force *" before starting "amdump archive -o storage=archive" on weekends.
>
> OK?
>
> Some fulls could/should be collected in the holdingdisk by running the daily backups. This could be achieved by using the right *-threshold values, I assume.
>
> All this gets quite complicated quickly, at least for me ;-)
>
> Maybe I overlook something, maybe I don't yet fully understand some parts here.
>
> Would be great to discuss this with others, thanks.
>
>