Re: [Bacula-users] Q: what will bacula do if I reduce pool MaximumVolumes lower than number of existing vols in pool?

[Justin Case]

Thanks for coming back to this old question. To better understand what is 
happening I have further questions:

All my pools have ScratchPool = “Scratch" (the default scratch pool), but no 
RecyclePool. Interestingly the volumes in the pools to NOT have the scratch 
pool set (shouldn’t they have Scratch as scratch pool when the pool has 
ScratchPool = “Scratch”?)

When I list all purged volumes I just see 3. Although there is a lot of 
recycling going on when backups jobs are running. It seems that in my setup 
volumes get purged and recycled only during backup jobs when further volumes 
are required to be written. The volumes stay in the pool where they were 
created.

I have read the documentation on recycling volumes and RecyclePool. It seem 
that If I were to set RecyclePool=“Scratch” in my pools that purged volumes are 
first placed in the “Scratch” pool and will only be used from there if no 
further volumes can be purged during the backup job. Would that mean that 
during a backup job when a new volume is needed that firtst all old volumes 
that are expired get purged and places in Scratch and then a volume is fetched 
from Scratch to be able to continue? 

Also it seems that this way a volume may be moved from pool A to pool Scratch 
and later to pool B. As my disk volumes have filenames reflecting the pool 
characteristics this might be confusing, or will the disk volumes be renamed on 
disk when moved to a different pool?

If not, then I would need to have an individual scratch pool for each pool, so 
that recycled volumes stay with their original pool, but get moved out of the 
pool when expired, and later go back to the same pool when a new volume is 
needed?

> On 27. Jan 2024, at 12:36, Radosław Korzeniewski  
> wrote:
> 
> Hello,
> 
> pon., 20 lis 2023 o 00:27 Justin Case  > napisał(a):
> Hi there,
> 
> I realise that my short term pool will have more volumes than actually 
> necessary, as I started the backups earlier than on the day per month when 
> fulls are taken. So this pool will have at least two fulls in the first 
> month. In subsequent months there will only be the need for 1 full per month.
> 
> Now I had this thought: may I reduce the MaximumVolumes of that pool after 2 
> months when the superfluous first full has been purged? Explicitly this does 
> mean I would set MaximumVolumes of the pool to a number that is lower than 
> the number of volumes currently help in this pool. How would Bacula react? 
> would it throw the oldest purged volumes into the Scratch pool? Or what else?
> 
> MaximumVolumes parameter will prevent automatic volume labeling or moving 
> existing volume from Scratch pool only. No other procedures will be performed 
> when the number of volumes exceeds this limit. So, unless configured by 
> different parameters it won't move volumes out of the pool automatically. If 
> you set up a recycle pool in your pool configuration then Bacula will always 
> put recycled volumes in this pool, regardless of MaximumVolumes set. It is an 
> independent parameter.
> Setting both on your pool will allow you to automatically lower the number of 
> volumes in the pool and maintain a maximum number of them.
> 
> best regards
> -- 
> Radosław Korzeniewski
> rados...@korzeniewski.net 
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Again vchanger and volumes in error...

[Josh Fisher via Bacula-users]

On 3/19/24 08:31, Marco Gaiarin wrote:

Mandi! Josh Fisher via Bacula-users
   In chel di` si favelave...


This Looks like the volume is marked as being in a slot in the bacula
catalog, but the RDX cartridge containing that volume is not actually
mounted. This can happen if a cartridge is removed but an 'update slots'
command is never run or else failed due to an error.

Also replying to Bill: no, script seems to work as expèected and udev rules
that run them too.

Apart strange things that sometime happens, what happen is simple: on friday
morning i eject the cartdrige by a script; operator so find the cartdrige
expelled, and change it.

If change wrong cartdrige (eg, remove the '3' and put in the '2' insted of
the '1') could be that the umount script/udev rule does not act, but surelt
the mount script/rule act as expected: i found the volumes of cartdrige 2
correctly 'inchanger'.


It would be a bug if Bacula is trying to mount a volume not inchanger, but
even though it seems that way, that might not be true. You can set
'Log Level = LOG_DEBUG' in the vchanger.conf file. That will log everything
that vchanger does. The udev script will run vchanger with the REFRESH 
command.
If you don't see a REFRESH command being logged in the vchanger log file 
when

the cartridge is removed, then Bill is correct, the RDX device is not
generating an ACTION="remove" event in udev when the cartridge is removed.




Simply they are not purgeable, so bacula start to purge volumes in cartdrige
1 (right) and mount them (wrong), puting them on error.

___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users