Re: [Bacula-users] VirtualFull and correct volume management...

[Bill Arlofski via Bacula-users]

On 5/24/24 2:39 AM, Marco Gaiarin wrote:

I suspect that 'job counter' get resetted if and only if all jobs in a
volume get purged; this lead me to think that my configuration simpy does
not work in a real situation, because sooner or later jobs get 'scattered'
between volumes and virtual job of consolidation stop to work, so jobs and
volume purging.

Sorry, i need feedback on that. I restate this.


Seems to me that if i use 'job based retention' on volumes, eg:

        Maximum Volume Jobs = 6

on the pool, simply does not work. Because the 'job counter' on the volume
get resetted if and only if *ALL* job on that volume get purged.

If i have a volume in state 'Used' because got 6 job within, and i
purge/delete jobs but not all, media state does not switch to 'Append', and
even if i put manually in 'Append' mode, bacula reject the volume and put on
'Used' state because have reached 'Maximum Volume Jobs'.
If i delete *ALL

* job in that volume, get correctly recycled.

It is right?


There's some 'knob' i can tackle with to make volume management more
'aggressive'?

Why not set in your Pool(s) `MaximumVolumeJobs = 1`







You will want to limit your volumes sizes (MaximumVolum




If you prefer to have volumes stay in a pool they were initially created in 
forever, ignore that previous paragraph. :)


ed for re-use as described above.


----8<----
Job {
  Name = Admin_Delete_Failed_Jobs
  Type = Admin
  ...other settings...

  RunScript {
    RunsWhen = before
    RunsOnClient = no
    Command = /opt/bacula/scripts/deleteFailedJobs.sh
}
----8<----

Then, in that `/opt/bacula/scripts/deleteFailedJobs.sh` script, something like:
----8<----
#!/bin/bash

bcbin="/opt/bacula/bin/bconsole"
bccfg="/opt/bacula/etc/bconsole.conf"

# The "gui on" removes commas in jobids so you don't have to use tr, or sed to 
do it
failed_jobids=$(echo -e "gui on\nlist jobs jobstatus=f\nquit\n" | $bcbin -c $bccfg | grep 
"^| [0-9]" | awk '{print $2}')

for jobid in $failed_jobids; do
  echo -e "delete yes jobid=$jobid\nquit\n" | $bcbin -c $bccfg
done
----8<----

If you do it this way (using the `Command =` in the Admin



Hope this helps!
Bill

--
Bill Arlofski
w...@protonmail.com

Then control your JobRetention and FileRetention periods as needed in your Pool(s). Typically you will set JobRetention > FileRetention if you want to aggressively manage the amount of storage your catalog uses, but it is usually best if possible to set JobRetention = FileRetention. This way, each file volume will have one job on it, and when that job is pruned from the catalog, the volume will be pruned/purged/truncated/recycled. (I am going on zero hours sleep this morning, so some details may be sketchy :) Don't try to force Bacula to use some arbitrary (small) number of file volumes. Let Bacula manage your volumes based on your chosen Job/File retention times, disk space available, etc. eBytes = xxGB for example), and you will want to limit the number of volumes allowed in a Pool (MaximumVolumes = xxx). This way with a little bit of calculations you can make sure that Bacula never fills your partition to capacity. You can monitor this as time goes on, and you can make adjustments as needed. If you have multiple Pools and you want Bacula to be able to freely move volumes from different pools when they are available, and so they don't get "stuck" in one pool forever, you can use the Pool's `ScratchPool` and `RecyclePool` pool settings and then create a Scratch Pool that all Pools would point both of those settings to. Not sure if anyone has answered, but to delete a job, the bconsole `delete jobid=xxx` is what you want. This will delete the Job and Files records from the catalog, and free up any volume(s) used in the job being prun If you *really* want to automatically delete failed jobs (I personally don't think this is a good idea), you can use a RunScript in an Admin type Job like: Job's RunScript, the bconsole output of the jobs being deleted each time this Admin job is run will be in the Admin Job's joblog. Alternately, you can trigger the script from cron, and the bconsole output will be in the email that cron sends.

signature.asc
Description: OpenPGP digital signature

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