Ugh. The list ate my message  because it was too large. For this reason, my
follow on message is actually posted first. rats.

Part 1/2 follows:

Replies inline, in red

On Sat, Feb 14, 2026 at 7:40 PM Ross Boylan <[email protected]>
wrote:

> My backup partition filled with file-based volumes and I want to clear
> many of them out, as well as purging related records from the Catalog.
> I set my configuration to retain everything.  I made a Python script
> to identify the volumes I want to kill by direct
> queries to the database, but am unsure what commands I should be
> sending to bconsole.  And so I would appreciate some help.
>
This isn't how I would approach this problem. I would normally identify the
oldest 'full' backups or large jobs by sorting and filtering jobs in
bacularis or baculum (gui bacula administration tools). I would note down
the volumes used by those jobs, then go to the volumes page and see which
jobs use those volumes. If my target jobs are the only jobs on those
volumes, then I can safely dispose of the volumes to clear related catalog
entries, then free up disk space.
(methods: purge, then truncate those volumes OR delete the volumes in
bacula, then delete the file volumes from the filesystem).

I wouldn't use a script to try to find things to delete. Sounds needlessly
complicated and unlikely to get me what I need to know. If that's what
works for you, no worries, that's your decision.

I want to preface this paragraph by saying that I have used AI rather
extensively (carefully checking its results, and using man pages to
understand what it's doing). I have NOT used AI with bacula. The training
data available doesn't discuss bacula very much, so the AI models cannot
reliably give good information about bacula. I can very reliably provoke
every AI model I've tested (out of like 3, lol) to hallucinate: I just have
to ask them about bacula. They immediately start generating config file
options that don't exist. I don't know if you used AI with bacula, but I
wanted to warn you that it's less than useless for that purpose.
I'm not judging, nor do I think I am sure you used AI with bacula, but I
wanted you to know that, just in case. I mainly bring this up because the
python script approach felt odd to me. Maybe it's just because I'm used to
using GUI tools, and you needed to parse some bconsole output with python.

Myself and the other folks on the bacula list are here to help, and I
guarantee we will do a better job than AI in this case. :)


>
> MAIN QUESTIONS:
> Does bconsole's `delete` command for a volume delete all job and file*
> records associated with it?
>
Yes. 'delete volume=volumename' in bconsole will result in the removal of
all catalog entries related to jobs and files stored on that volume. It
will also remove the volume entry, which means that bacula will not manage
the volume anymore, up to and including truncation. In general, I'd rather
prune / purge a volume, then truncate.

The bconsole delete command itself will not remove any file volumes from
disk. It only impacts catalog entries.


> Does it matter if some of the jobs also use other, non-deleted, volumes?
>
No. The delete command deletes entries you specify for deletion. 'delete
volume=Volume-1' will impact jobid1, which is written to Volume-1. it will
have no impact whatsoever for jobid 2, which is written to Volume-2.

>
> OTHER QUESTIONS:
> Similarly, would deleting the job delete all associated file records?
>
Yes. File records are removed when the related job is removed. Job records
are removed when the related volume is removed. Please note that Job
records are NOT removed if file records are removed. This is because bacula
enables administrators to save catalog space by allowing file records for a
given job to expire sooner than the job itself. The consequence of such a
case where a job has no file records is that the entire job must be
restored in order to access a single file within it (or even to see what
files are contained within the job).

>
> Does `purge` have the same effect?
>
No, technically. Sort of. 'purge volume=volname' and 'delete
volume=volname' will both result in the removal of all job and file records
related to volume 'volname'. However, they differ in their method of
operation.
Purge will order the deletion of job and file records related to that
volume, then set the volume to status 'purged'. The volume is now available
for reuse. The volume has not been truncated, and still contains all of its
data.
Delete will order the deletion of job and file records related to that
volume, then delete any record of that volume from the catalog. The volume
has not been truncated, and still contains all of its data. Because the
volume is not referenced by any bacula catalog entry, bacula cannot manage
the file volume further.

>
> Understanding truncation is less important, since I want to delete the
>
I kinda disagree. I think truncation is the most important part of this,
though manually deleting volume files is an option. Truncating from within
bacula is better and safer, though.

> files--datestamps are part of their names.  But while I'm here ...
> `purge` is documented to truncate if `action = truncate` is specified
> or the volume has
> `Action On Purge` set to truncate.  Or perhaps both must be true for
> truncation to occur?
>
This feature is confusing. 'action on purge = truncate' should be 'action
on purge = Enable truncation'. Sort of like flicking a safety off. Nothing
happens unless you pull the trigger, ie, run a truncate command that
targets the relevant storage. From the 3rd to the last result (out of like
50 results) for 'truncate' in the bacula 15.x pdf manual:
"(The truncate command) will truncate a volume if the volume is purged, and
if the volume is also marked Action On Purge = Truncate."

>
> At any rate, does `delete` ever cause truncation, either by explicit
> command option or if the volume is set to truncate?
>
No, not to my knowledge. This is primarily because delete removes the
volume entry from bacula's catalog entirely, which means:
1. The volume is not in status purged, so not eligible for action by the
truncate command.
2.  The volume isn't even listed in the bacula catalog anymore, so bacula
has no reason whatsoever to interact with the file. By default, bacula
won't nuke random files that it doesn't have a clearly defined rationale
for nuking. This is pretty reasonable design, since we don't want bacula
wrecking random things on the filesystem.

>
> I'm using bacula 9.6.7.  I have consulted its documentation, the
> current documentation
> https://docs.baculasystems.com/BEUserInterfaces/Console/index.html,
> and the internet, but I am not sure how the commands behave.  For
> example, the current manual says "The purge command will delete
> associated Catalog database records from Jobs and Volume" but doesn't
> say exactly what is "associated" for each subcommand.
>
Firstly, be CAREFUL with purge. They aren't kidding when they say it's
dangerous. You might be familiar with running jobs from bconsole, where
each step of the process is multiple choice, you can abort at any point,
and you're given a summary of proposed actions for you to modify, approve,
or decline (cancel).
The purge command, if ran at the command line with no other options, will
ask you which filedaemon you want to act upon. You select a file daemon,
and hit enter. It proceeds to nuke every catalog entry related to that file
daemon, without any further prompting. When I discovered this, I only had 1
file daemon, which was running on my bacula server. I had to do a catalog
restore from backup. When using the purge command, I usually recommend
making a fresh catalog backup, and then restoring it to a safe place BEFORE
running the purge command.

Purge commands with more specific options are safer (by comparison). so
'purge volume=volumename' will purge all job and file records associated
with that volume, and then mark the volume as purged. The volume file
itself will remain unmodified by that specific operation.

Regards,
Robert Gerber
402-237-8692
[email protected]
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to