Hi Dan,
Am 11.05.2026 um 17:18 schrieb Stieneke, Dan - OCIO-CEC, ID:
Thanks for the pointers. RE your questions:
Q: "If you run backups from other hosts, for example the backup server itself, do
those succeed?"
No significant backups from any other hosts. The backup is migrated to tape each Friday,
the migrate of "nothing" claims success, and then the backup catalog is written
to tape, which is also successful.
Do I understand this correctly -- since the problems started you have
not seen a migration from disk to tape, i.e. we do not know if the SD is
still able to move considerable amounts of data in general?
Q: "Also, the report states that the FD believes it runs on Windows Server 2012, and
that the FD version is slightly newer than the DIR/SD. None of that is necessarily
problematic, but I think it would be reasonable to try upgrading the Bacula software on
both ends first. Have you installed DIR/SD from Ubuntu repos or from another source?"
DIR/SD are from https://www.bacula.org/packages/630201ee796f2/debs/13.0.1
I wanted v13 when I installed, but only v9 was available on 22.04LTS. Now that
I'm running 24.04, 13.0.4 is available from the regular repositories, so that's
an obvious move. I'll check to see if a more recently-built Windows binary is
available.
Quite understandable reasons, and give the age of the packages I think
you should do an upgrade before we dig deeper. Very often, such problems
need developers involved, and their enthusiasm with old versions is
rather limited.
Q: "Have you ever used debug tracing with Bacula?"
I've never had any significant difficulty with Bacula, so no. Per google it
looks easy enough to initiate, I'm guessing the hard part will be interpreting
the results.
I tend to agree :-)
Anyway, what I was aiming at was trying to understand what happens on
both endpoints and in between. Running both the FD and the SD with debug
tracing enabled and, if necessary, correlating with a network capture is
probably going to provide some information, but it's going to need a bit
of time.
I would suggest you try, in bconsole, something like
setdebug level=400 trace=1 tags=network,protocol client=TARGET-fd
while a job runs, and disable afterwards with
setdebug level=0 trace=0 tags=all client=TARGET-fd
and then see what is in the trace file created in the configured working
directory.
Similarly on the SD side, eventually, but I'd start with the file daemon
because, after all, it seems to send larger packets than configured.
If you feel comfortable reading such traces (and, if you're really
curious, the corresponding source code :-) we can start digging.
Cheers,
Arno
Thanks,
Dan
Dan Stieneke
IT Specialist
Laboratory Common Services Branch/Laboratory Technical Services Division
Office of the Chief Information Officer Client Experience Center
3793 N 3600 E, Kimberly, Idaho, 83341
(208) 421-0563
-----Original Message-----
From: Arno Lehmann via Bacula-users <[email protected]>
Sent: Wednesday, May 6, 2026 12:00 PM
To: [email protected]
Subject: Re: [Bacula-users] New error appears on long-working system - Wrote X
bytes to Storage daemon, but only Y accepted
Hi Dan,
Am 06.05.2026 um 17:14 schrieb Stieneke, Dan - OCIO-CEC, ID via
Bacula-users:
Sorry all if this is a repeat, the original message was kicked back
stating it needs moderator approval because I'm a non-member (sending
address was new v. address which joined the list).
we'll see if we get another instance :-)
Without really looking through all the details, I wonder about a few things in
your job report.
In the progress report at the top, it mentions the SD wrote to three volumes.
Eventual volume status is only mentioning two volumes, and the SD bytes written
is also 0.
This seems to indicate a problem that is not just a network issue between FD
and SD but rather something affecting the SDs capability to communicate to the
DIR as well.
If you run backups from other hosts, for example the backup server itself, do
those succeed?
Also, the report states that the FD believes it runs on Windows Server 2012,
and that the FD version is slightly newer than the DIR/SD. None of that is
necessarily problematic, but I think it would be reasonable to try upgrading
the Bacula software on both ends first. Have you installed DIR/SD from Ubuntu
repos or from another source?
Then, the fact that the FD reports a network issue but the SD doesn't seem to
have anything to mention but the DIR lost the connection to it would imply
that, if there's a network or Bacula protocol problem, it should be something
that may be detected on the SD end. Have you ever used debug tracing with
Bacula?
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
This electronic message contains information generated by the USDA solely for
the intended recipients. Any unauthorized interception of this message or the
use or disclosure of the information it contains may violate the law and
subject the violator to civil or criminal penalties. If you believe you have
received this message in error, please notify the sender and delete the email
immediately.
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
