On 1/24/25 14:50, Phil Stracchino wrote:
On 1/24/25 14:43, Josh Fisher via Bacula-users wrote:
On 1/24/25 13:22, Bill Arlofski via Bacula-users wrote:
On 1/24/25 10:17 AM, Phil Stracchino wrote:
this huge atomic write *also* makes it incompatible with Galera 3
clusters.)
Are you sure about
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
Am 27.01.25 um 17:20 schrieb Philip Pemberton via Bacula-users:
On 27/01/2025 15:41, Udo Kaune wrote:
Please try
https://www.ibm.com/search?lang=en&cc=us&facetTabs=fixes&origin=fc&q=ITDT&tabType[0]=support
I've tested the drive with ITDT and it passes health check and reports similar
speeds.
[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
