Marco,
I do think that truncating a tape 'the bacula way' (if bacula provides a
way to do this) is a better idea. Preserving tape mount statistics could be
valuable, as Arno mentioned. In the case that I described in my previous
email, I knew I had mounted and used that set of tapes one time - to write
a full backup. I also knew that the tapes would be written to again 1 more
time, to take another large full backup.
I think truncation is usually more useful for disk volumes, to stop them
from taking up space, so maybe this process won't work for tape volumes. I
believe for tape volumes, truncation would have to involve rewinding to
some point and writing an eof marker so the bacula can find the last useful
data. The drive will not seek beyond the eof marker. So if the bconsole
'truncate' command does not write an 'eof' to the tape, then I think it
will not truncate a tape volume. I just don't know what the truncate
command is designed to do in this case. I looked in the bacula console
manual, and there is no entry for the truncate command, which is
unfortunate. Perhaps for bacula-managed tape truncation, the tape could be
rewound to the area right after the bacula label (at the beginning of the
tape), and then an eof could be written. This would be slightly different
than the process I outlined in my previous email, because using 'mt' to
write an eof would write the eof over top of the first few bytes of the
label bacula wrote to the start of the tape, essentially making the tape
unlabeled. Also presumably, if we aren't deleting the volume from the
catalog, then volume statistics could be preserved.
Here is some information from the bacula 15.x manual, section on pool
resources:
Action On Purge = <Truncate>
The directive ActionOnPurge=Truncate instructs Bacula to
permit the Volume to be truncated after it has been purged. Note: the
ActionOnPurge
is a bit misleading since the volume is not actually truncated when it is
purged, but is
enabled to be truncated. The actual truncation is done with the truncate
command.
To actually truncate a Volume, you must first set the ActionOnPurge to
Truncate in the
Pool, then you must ensure that any existing Volumes also have this
information in them,
by doing an *update Volumes* command. Finally, after the Volume has been
purged, you
may then truncate it. It is useful to prevent disk based volumes from
consuming too much
space. See below for more details of how to ensure Volumes are truncated
after being
purged.
First set the Pool to permit truncation.
Pool {
Name = Default
Action On Purge = Truncate
...
}
Then assuming a Volume has been Purged, you can schedule truncate operation
at the
end of your CatalogBackup job like in this example:
Job {
Name = CatalogBackup
...
RunScript {
RunsWhen=After
RunsOnClient=No
Console = "*truncate Volume allpools storage=File*"
}
}
........
End of manual entry.
........
I think for your case it would be undesirable to update all volumes in your
pool to enable truncation. It is probably also overkill to make a special
job to perform this task. I also think you do not want to truncate all
potentially eligible volumes in all pools, only the specific ones that you
want to reuse. I do think this manual entry gives us some hints about the
correct way to truncate a volume.
I wonder if you could:
1. create a special pool just to enable actiononpurge=truncate,
2. move your target volumes to that pool,
3. run an update volumes in bconsole to apply any pool settings to volumes
(if those settings weren't applied when the volumes moved to that pool)
4. purge the volumes
5. run the truncate command in bconsole. I would be more specific about a
pool, and not run it for all pools.
6. move the volumes to the desired pool
7. run update volumes again, just in case.
A note: the purge command in bconsole is dangerous! In the past I wanted to
understand the purge command, so in bconsole I ran:
> purge
I was asked to select an FD.
> I selected an FD. I expected further prompting.
ALL FILE RECORDS FOR THAT FD WERE IMMEDIATELY PURGED FROM THE DATABASE
WITHOUT ANY FURTHER WARNING!
So please be very careful with the purge command. I recommend targeting
specific volumes with a purge command. I usually use bacularis to perform
this task. I believe all bacularis is doing is selecting a volume and
running the bconsole command to purge only that volume and nothing else.
probably something like 'purge volume=volname'.
I know I use truncation for some of my disk volumes. In my case I have
cloud volumes, and I want to stop paying for cloud storage as soon as
possible. So, truncation is the option I use.
For my case I have:
1. 'actiononpurge=truncate' in all relevant pool resources (set from the
beginning, not applied to volumes after they were created). (my point is
that I don't know much about updating volumes after a pool has been created
/ volumes have been added to a pool).
2. retention periods set to expire jobs, file records, and volumes when I
want them expired
3. an admin job to prune all volumes that are expired from all pools with
'prune volume allpools yes'.
4. an admin job to run 'truncate allpools storage=mystoragename'
Please note that for an admin job, it isn't good to use 'console =
YourCommand'. It is better to have a separate script that contains the
command, and run that script. If you simply run the command in the admin
job using 'console =' then the bconsole output will go into the log under
'jobid 0', which is terrible for troubleshooting. When you use a script
from an admin console, you need to use 'Command =
"/path/to/your/script.sh"' in the admin job.
Regards,
Robert Gerber
402-237-8692
[email protected]
On Wed, Nov 12, 2025 at 4:53 AM Arno Lehmann via Bacula-users <
[email protected]> wrote:
> Hi Marco,
>
> Am 11.11.2025 um 18:46 schrieb Marco Gaiarin:
> > Mandi! Arno Lehmann via Bacula-users
> > In chel di` si favelave...
> >
> >> I see "recycle=0" or, in Bacula Pool Directive terms, "Recycle = No".
> >
> > Sorry; considering that i know that tapes does not contain useful data,
> to
> > manually recycle i need to:
> >
> > 1) purge it
> >
> > 2) truncate it
> >
> > 3) manually set/update volume to 'Append' status
> >
> >
> > Right? Thanks.
>
>
> Good question, actually -- I can't even recall any instance I had to do
> such a thing manually ;-)
>
> I would say "truncate it" is going to be the key thing. Presumably,
> Bacula will refuse to recycle such a Volume; the simplest option might
> be to just set the volume to enable recycling, and once a Job has
> started writing to it, reset as needed:
>
> *update volume=E01006L8
> Parameters to modify:
> 1: Volume Status
> 2: Volume Retention Period
> 3: Volume Use Duration
> 4: Maximum Volume Jobs
> 5: Maximum Volume Files
> 6: Maximum Volume Bytes
> 7: Recycle Flag
> ...
>
> This would allow the DIR to go through all the necessary steps and at
> the same time not lose volume life status data such as number of mounts
> recorded.
>
> Cheers,
>
> Arno
>
> --
> Arno Lehmann
>
> IT-Service Lehmann
> Sandstr. 6, 49080 Osnabrück
>
>
>
> _______________________________________________
> Bacula-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
