>>>>> 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
