Hello @algebro and welcome to the forum!
–number-of-retries (default 5) –retry-delay (default 10 seconds) retry at a higher level than the individual backend. I’m pretty sure it gets a new upload URL each time, but if you see otherwise then that’s a bug.
Backblaze B2 ideally would like Duplicati to look for their Retry-After header (I don’t think it does that), and if that’s not available then do an exponential backoff as described below (with “expotential” as typo):
B2 Integration Checklist. Section technically is referring to 503 error, but a backoff plan might fit anyway, given that “something goes wrong” can happen other ways. Duplicati doesn’t do “exponential” yet AFAIK.
What release are you running? Here are some of the B2 glitches I hit during a big test of 2.0.4.22 canary where you can see the retry message. Use About → Show log → Live → Retry, or set up –log-file and –log-file-log-level=retry, or for the simplest check, look for your log’s BackendStatistics" “RetryAttempts”.
Typically Duplicati seemed able to ride out B2 errors transparently (unless you’re looking at logs closely) until retry attempts were exhausted, then it bailed out quite hard. I’m not sure if that’s a new or old bug…
Reporting options –send-mail-to worked, but the job database never got updated to record an error there. After a few tries, the backup would always sort itself out and keep going though. What errors did you get?
There seemed to be a special noisiness with parallel uploads when a dlist upload would fail and Duplicati would try to clean up by deleting it, only to find that it wasn’t there. This was avoidable by disabling parallel uploads with --asynchronous-concurrent-upload-limit=1 (only in canary and experimental, not yet in beta).