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
