As I am scripting some routines to backup several ftp accounts to my local drive, one of them fails with random "connection refused" errors.
My guess is that rclone is hitting the server too fast, even with transfers and checkers set to "1". I have tried several combinations of transfers, checkers, timeouts and retries, but had no luck.
I wonder if there is any parameter to force a delay between each file download attempt.
Of course this would impact the time taken to backup the account, but if it works it would be an acceptable solution for me.
Running multiple passes does not help either because it always fails on different files.
What is your rclone version (output from rclone version)
go version: go1.15.5
Which OS you are using and how many bits (eg Windows 7, 64 bit)
Which cloud storage system are you using? (eg Google Drive)
Remote FTP to Local HDD
The command you were trying to run (eg rclone copy /tmp remote:tmp)
I don't think the full log will provide any further info, and it will be quite large. It shows several transfers and then some random files fail here and there.
It is not going offline, as many files are being transferred before and after the failures, more likely the server is throttling by refusing connections, hence why I ask if there is any switch that will make rclone "less aggressive" against this particular FTP.
I am not seeking to debug an error, rather I am asking if there is something like the nmap's switch to reduce the risk of being blocked while it scans a target.
I just tried --ftp-concurrency with "3" and the "1" but it seems to make no difference in this case.
" --tpslimit " for what I gather from the Docs seems like it would be the switch I need, if it worked with ftp connections...
If you feel like adding it it would be great and I can offer to do my best to help testing it against this stubborn server.
But on the other hand, this looks like an edge case and making a "feature request" out of it just so I can back up this site feels too selfish. Perhaps I can find another way around this.