is not present in Duplicati code but is found numerous times on the Internet in non-Duplicati context, so might be a Windows or .NET Framework message (you could look – most of the top hits are in French).
Google Translate:
A connection attempt failed because the connected party did not respond properly beyond a certain time, or an established connection failed because the connection host did not respond
Although I have not adapted my test to exactly your specs, clicking fast and many didn’t find a problem.
My Duplicati is on Windows. It sounds like yours is too. I don’t have a Linux sftp server set up for a test.
My netstat shows just the SFTP server LISTENING for connection. What does your netstat show you? Looking at the Linux remote may also be interesting to see if the two views line up in a reasonable way.
C:\tmp>netstat -ano | findstr :22
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING 3624
TCP [::]:22 [::]:0 LISTENING 3624
TCP [::1]:22 [::1]:52343 TIME_WAIT 0
TCP [::1]:22 [::1]:52345 TIME_WAIT 0
TCP [::1]:22 [::1]:52346 TIME_WAIT 0
TCP [::1]:22 [::1]:52347 TIME_WAIT 0
TCP [::1]:22 [::1]:52356 TIME_WAIT 0
TCP [::1]:22 [::1]:52357 TIME_WAIT 0
TCP [::1]:22 [::1]:52358 TIME_WAIT 0
TCP [::1]:22 [::1]:52359 TIME_WAIT 0
TCP [::1]:22 [::1]:52367 TIME_WAIT 0
TCP [::1]:22 [::1]:52368 TIME_WAIT 0
TCP [::1]:22 [::1]:52369 TIME_WAIT 0
TCP [::1]:22 [::1]:52371 TIME_WAIT 0
TCP [::1]:22 [::1]:52379 TIME_WAIT 0
TCP [::1]:22 [::1]:52380 TIME_WAIT 0
TCP [::1]:22 [::1]:52384 TIME_WAIT 0
TCP [::1]:22 [::1]:52392 TIME_WAIT 0
TCP [::1]:22 [::1]:52394 TIME_WAIT 0
TCP [::1]:22 [::1]:52395 TIME_WAIT 0
TCP [::1]:22 [::1]:52397 TIME_WAIT 0
TCP [::1]:22 [::1]:52404 TIME_WAIT 0
TCP [::1]:22 [::1]:52405 TIME_WAIT 0
TCP [::1]:22 [::1]:52407 TIME_WAIT 0
TCP [::1]:22 [::1]:52408 TIME_WAIT 0
TCP [::1]:22 [::1]:52414 TIME_WAIT 0
TCP [::1]:22 [::1]:52415 TIME_WAIT 0
TCP [::1]:22 [::1]:52416 TIME_WAIT 0
TCP [::1]:22 [::1]:52417 TIME_WAIT 0
TCP [::1]:22 [::1]:52423 TIME_WAIT 0
TCP [::1]:22 [::1]:52424 TIME_WAIT 0
TCP [::1]:22 [::1]:52425 TIME_WAIT 0
TCP [::1]:22 [::1]:52426 TIME_WAIT 0
TCP [::1]:22 [::1]:52432 TIME_WAIT 0
TCP [::1]:22 [::1]:52433 TIME_WAIT 0
TCP [::1]:22 [::1]:52434 TIME_WAIT 0
TCP [::1]:22 [::1]:52435 TIME_WAIT 0
C:\tmp>
I’d note that I’m not changing the source, but I do have –upload-unchanged-backups option checked, so it looks like I put up 9 backup versions (though just the dlist file) from my rapid clicks. Each one does go through Verifying backend files after the upload (and I notice one of your errors was in the TestHandler). –backup-test-samples=0 will turn off the verification, if you want to test if that avoids all of the problems.
"FilesUploaded": 1,
"FilesDownloaded": 3,
then becomes
"FilesUploaded": 1,
"FilesDownloaded": 0,
but if you have source file changes, you might get 3 files uploaded (dblock and dindex due to changes).
What would be helpful would be to see if the connection failure or the retries are an essential part here.
Is your SFTP server on a reliable (including any WiFi) local network? Might be either network or server.
A useful log would be to see what’s happening at the Retry level, e.g. About → Show log → Live → Retry, or if you prefer a log on disk with more setup effort, options –log-file and –log-file-log-level=Retry.