Yes , you're right But the job work well for an other machine through the same vpn and the job last 9hours . And from the hardware vpn gateway, I don't have much configuration choice. It could be a direction.
Could it be a problem of Debian 12 which seems not to be official for Bacula v13 ? "SD calls Client" directive was activated , don't know why ( I tried so many conf to solve it :). I will re-test without And for the slow rate I am trying the Network buffer size directive on FD and SD but not really conclusive. But : Error: lib/bsock.c:397 Wrote 65566 bytes to client:192.168.0.4:9102, but only 65536 accepted Tells me to look after the send and receive buffer on network drivers .... Bacula doc : Note, on certain Windows machines, there are reports that the transfer rates are very slow and this seems to be related to the default 65,536 size. On systems where the transfer rates seem abnormally slow compared to other systems, you might try setting the Maximum Network Buffer Size to 32,768 in both the File daemon and in the Storage daemon ... The default size was chosen to be relatively large but not too big in the case that you are transmitting data over Internet. It is clear that on a high speed local network, you can increase this number and improve performance. For example, some users have found that if you use a value of 65,536 bytes they get five to ten times the throughput. Larger values for most users don’t seem to improve performance. If you are interested in improving your backup speeds, this is definitely a place to experiment. You will probably also want to make the corresponding change in each of your File daemons conf files. I'm disappointed, and made so many inoperant conf changes , that I will try to with v9.6.6 ( I used before on my lan) to see if the problem is the same .
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
