Hello Lionel,
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?"
In addition to the Josh considerations, I would consider trying BBR:
https://www.bacula.lat/bacula-e-prototoclo-bbr-para-backups-via-internet-perdas-de-pacote-desconecoes-etc/?lang=en
I have a mixed OnP+cloud customer +1000 machines situations, where this was the
only solution for the network interruptions.
The BBR is not only more resilient to transmission contingencies (NATs,
firewall drops, switches/router resets etc.), but also provides much faster
throughput recovery in case of failure.
Underlying VPN is also something that, by my experience, are prone to
disconnections that have huge impact on Linux default congestion protocol.
Rgds.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
