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