Ok , Without encryption (TlsPskEnable = false and TlsVerifyPeer=false) and lzo-md5 the job finished well and all job that were in error gone ok too today. Just to say , on Debian 12 , libssl is on the new v3.0 version so I have to retroport it from the bullseye repo in order to install Bacula which depends on libssl1.1 Perhaps it could be why I encounter this problem. (for info too, the ethernet card is : <Ethernet controller: Intel Corporation Ethernet Controller X550 (rev 01)>
> OK. I see that now. You also tried without compression and without > encryption. Have you tried reducing Maximum Network Buffer Size back > to the default 32768? I also have tested with 32768 max net buffer size, but it was from window's fd to Debian 12 remote sd and it went in error (but really not sure if at this time all my confs were properly set in both side) : Error: lib/bsock.c:397 Wrote 32772 bytes to Storage daemon:192.168.0.18:9103, but only 32768 accepted. I now use without encr (and with lzo-md5 comp for data), Its ok, I can work like this. As the last past jobs are now ok I won't go further. Thank you for considering my problem. Great thanks for the Bacula and bbr explanation I will study this with great attention. Sure it could give me much more efficience. -----Message d'origine----- De : Martin Simmons <mar...@lispworks.com> Envoyé : mercredi 8 novembre 2023 19:32 À : Josh Fisher <jfis...@jaybus.com> Cc : bacula-users@lists.sourceforge.net Objet : Re: [Bacula-users] fd lose connection >>>>> On Wed, 8 Nov 2023 11:09:44 -0500, Josh Fisher via Bacula-users said: > > On 11/7/23 19:26, Lionel PLASSE wrote: > > I’m sorry but no wi-fi nor 5G in our factory, and don't use my phone too to > > backup my servers :) . > > I was talking about ssh (scp) transfer just to Just to show out I have no > > problem when uploading big continuous data using other tools through this > > wan. The wan connection is quite stable. > > > > "So it is fine when the NIC is up. Since this is Windows," > > no windows. I discarder windows problem hypothesis by using a > > migration job, so from linux sd to linux sd > > OK. I see that now. You also tried without compression and without > encryption. Have you tried reducing Maximum Network Buffer Size back > to the default 32768? Are you sure it is 32768? I thought the default comes from this in bacula/src/baconfig.h: #define DEFAULT_NETWORK_BUFFER_SIZE (64 * 1024) > There must be some reason why the client seems to > be sending 30 bytes more than its Maximum Network Buffer Size. Bacula > first tries the Maximum Network Buffer Size, but if the OS does not > accept that size, then it adjusts the value down until the OS accepts > it. Maybe the actual buffer size gets calculated differently on Debian > 12? Why is the send size exceeding the buffer size? Or could there be > a typo in the Maximum Network Buffer Size setting on one side? It's an interesting question. OTOH, if the connection is using TLS, then the underlying number of bytes transmitted doesn't match the application layer anyway. Also, can you explain why the network buffer size would cause data loss on a TCP connection? > > > > > > Thanks for all, I will find out a solution Best regards > > > > PLASSE Lionel | Networks & Systems Administrator > > 221 Allée de Fétan > > 01600 TREVOUX - FRANCE > > Tel : +33(0)4.37.49.91.39 > > pla...@cofiem.fr > > www.cofiem.fr | www.cofiem-robotics.fr > > > > > > > > > > > > > > > > -----Message d'origine----- > > De : Josh Fisher via Bacula-users > > <bacula-users@lists.sourceforge.net> > > Envoyé : mardi 7 novembre 2023 18:01 À : > > bacula-users@lists.sourceforge.net > > Objet : Re: [Bacula-users] fd lose connection > > > > > > On 11/7/23 04:34, Lionel PLASSE wrote: > >> Hello , > >> > >> Could Encryption have any impact in my problem. > >> > >> I am testing without any encryption between SD/DIR/BConsole or FD > >> and it seems to be more stable. (short sized job right done , > >> longest job already running : 750Gb to migrate) > >> > >> My WAN connection seems to be quite good, I achieve transferring big > >> and small raw files by scp ssh and don't have ping latency or troubles > >> with the ipsec connection. > > > > So it is fine when the NIC is up. Since this is Windows, the first thing to > > do is turn off power saving for the network interface device in Device > > Manager. Make sure that the NIC doesn't ever power down its PHY. > > If any switch, router, or VPN doesn't handle energy-efficient internet in > > the same way, then it can look like a dropped connection to the other side. > > > > Also, you don't say what type of WAN connection this is. Many wireless > > services, 5G, etc. can and will drop open sockets due to inactivity (or > > perceived inactivity) to free up channels. > > > > > >> I tried too with NAT, by not using IPSEC and setting Bacula SD & DIR > >> directly in front of the WAN. > >> And the same occurs (wrote X byte but only Y accepted) > >> > >> I Tried too to make a migration job to migrate from SD to SD through WAN > >> instead of SD-> FD through WAN and the result was the same. (to see if > >> win32 FD could be involved) > >> - DIR and SD in the same LAN. > >> - Backup remote FD through remote SD, the two are in the same LAN to > >> fast backup : step OK . > >> - Then migration from remote SD to the SD that is in the DIR area > >> through WAN to outsource volumes physical support : step nok The final > >> goal: outsourcing volumes. > >> I then discard the gzip compression (just in case) > >> > >> The errors are quite disturbing : > >> * Error: lib/bsock.c:397 Wrote 65566 bytes to > >> client:192.168.0.4:9102, but only 65536 accepted > >> Fatal error: filed/backup.c:1008 Network send error to SD. > >> ERR=Input/output error Or (when increasing MaximumNetworkBuffer) > >> * Error: lib/bsock.c:397 Wrote 130277 bytes to > >> client:192.168.0.17:9102, but only 98304 accepted. > >> Fatal error: filed/backup.c:1008 Network send error to SD. > >> ERR=Input/output error Or (Migration job) > >> * Fatal error: append.c:319 Network error reading from FD. > >> ERR=Erreur d'entrée/sortie > >> Error: bsock.c:571 Read expected 131118 got 114684 from > >> Storage daemon:192.168.10.54:9103 > >> > >> It's look like there is a gap between send and receive buffer and looking > >> at the source code, encryption could affect buffer size due to encryption. > >> So I think Bacula-SD could be in cause (maybe). > >> Could it be a bug? > >> What could I do to determine the problem (activating debug in sd > >> daemon ? ) > >> > >> I use Bacula 13.0.3 on Debian 12 , with ssl 1.1 > >> > >> Thank for helping. Backup scenarios must have an a step of relocating the > >> backup media to be reliable. > >> > >> _______________________________________________ > >> Bacula-users mailing list > >> Bacula-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users