I've noticed something which has changed from the bacula 9->13 upgrade.
Looking at logs from December, before the upgrade, I find that *all* the
backups were using storage "FileStorage0" and media type "File0". And
yet, the load was still shared 50/50 between devices FileDev0 and FileDev1.
r
On 28/01/2025 19:48, Martin Simmons wrote:
Actually, I think job 92925 runs first (according to the timestamps in the
logs, which are not in order for some reason) and creates the volume using
FileStorage0. Then, for some reason, the SD refuses to use FileStorage0 for
job 92925, which makes it s
> On Tue, 28 Jan 2025 09:09:47 +, Brian Candler said:
>
> # grep '9292[56]' /var/log/bacula/bacula.log
> 26-Jan 02:05 store.nsrc.org-dir JobId 92926: Start Backup JobId 92926,
> Job=drupal.nsrc.org.2025-01-25_21.00.00_35
> 26-Jan 02:05 store.nsrc.org-dir JobId 92926: Error: bsockcore.c:40
[Continuation]
Configurations are below, and nothing really has changed since upgrading
from 9.4.2 to 13.0.4.
The upgrade was done via in-place upgrades of the backup server from
Ubuntu 20.04 -> 22.04 -> 24.04. The first upgrade removed bacula
entirely (since bacula was dropped from the jam
This issue is weird, and I wonder if anyone else has seen anything like
this.
We are using bacula with file storage, and the volume labelling comes
from a variable expansion:
LabelFormat =
"${JobId}-${Client}-${Level}-${Pool}-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}"
After upgrading the d
