Re: New error appears on long-working system - Wrote X bytes to Storage daemon, but only Y accepted

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