Error "Maximum backoff reached" during COPY

copy
backblaze-b2

#1

After many hours of running COPY from my Win 7 backup computer to Backblaze B2 suddenly I received the following error and the copy process stopped completely:

Chunk ... (44xx/82676) copied to the destination
...
Chunk ... (4411/82676) copied to the destination
URL request 'https://pod-000-1052-13.backblaze.com/b2api/v1/b2_upload_file/26856cb06f097f6b644b0510/c000_v0001052_t0037' returned status code 500
URL request 'https://pod-000-1054-18.backblaze.com/b2api/v1/b2_upload_file/26856cb06f097f6b644b0510/c000_v0001054_t0047' returned status code 500
Failed to upload the chunk e076772755c1bc521914ed01d7833e156a4bdd2eb84f68f767ac5ae4638a2655: Maximum backoff reached

After restart of COPY it runs again for hours now.


#2

I did a quick search and found:


#3

Thanks. I found that too, but I’m not sure if it is really the same issue.

The question is, why is Duplicacy stopping at all? And why is it needed to restart it?

Wouldn’t it be better that Duplicacy waits a certain time and retries by itself?

And what is the reason for this error anyway?


#4

Today again: After restarting and many hours of running COPY suddenly I received the following error and the copy process stopped completely again:
Chunk ... (8339/82676) copied to the destination
...
Chunk ... (8349/82676) skipped at the destination
Failed to upload the chunk 332d86d7075a88fa1de25c9bc750012fa18e5d0f9975635eec45a0fa2dba9c61: Maximum backoff reached
Duplicacy script terminated.


#5

This is very likely an issue either with the network connection or with B2, as discussed here:


#6

Thank you!
But is there a solution? @gchen wrote:

This is either a network issue or a B2 issue. If it persists, the best option may be to increase the number of tries from 8 to 12.

But how to increase the number of tries? There’s no option for “number of tries” in COPY: Copy command details


#7

Sorry what I meant is that you can modify the source code (src/duplicacy_b2client.go) to change the number of tries and then rebuild the binary.


#8

@gchen Thanks! Is there a solution for non-IT professionals like me, who are not able to rebuild binaries?
Wouldn’t “number of tries” be a good option for the COPY and BACKUP functions?


#9

I agree. If this setting needs adjusting, I suppose it should be a command option or something, no?


#10

I think we can add an environment variable for setting the number of retries.


#11

How will that work in windows?
I guess people are more used to using a command option than an environment variable…


#12

I just made an “enhancement suggestion” in the GitHub topic, because the last post there gave an idea of a “finalized issue”.


#13

Got the error this morning:

Chunk b5d6966ccd517bdcc6fd1590ca00d0901b7bd07835ab9f9e225728f09d1fa0f5 (5957/40549) copied to the destination
Failed to upload the chunk 70a25d2e171a2c0b3e1f8182903849eb3d50f756eaf8bcad626ff915107e4011: Maximum backoff reached

So the error is still in the air.

Thanks.


#14

Just a “bump” to indicate that we have a new issue referencing the first ones:

The other two (# 423 and # 460) are about creating a new option for retries. The last one (# 558) only increases the number from 8 to 16.


#15

Great! Thanks @gchen

:ok_hand::ok_hand::ok_hand: