Backblaze B2 API version

Help and Support
1

Hello.

I'm troubleshooting some issues when syncing directly with Backblaze support I sent a log from Rclone and was informed that I was using API version 1 and that I should be using API version 2. In the log it is indeed using API v1 see the sample

"https://api.backblazeb2.com/b2api/v1/b2_authorize_account"

How do I set Rclone to use API version 2?

rclone v1.58.1

  • os/version: Microsoft Windows 10 Pro 21H1 (64 bit)
  • axis/kernel: 10.0.19043.2130 (x86_64)
  • axis/type: windows
  • os/arch: amd64
  • go/version: go1.17.9
  • go/linking: dynamic
  • go/tags: cmount

Thank you

2

Hi Joystick,

I suggest you first try updating to the latest version of rclone, that may solve the issue.

You can use rclone selfupdate or download from here: https://rclone.org/downloads/

If this doesn't help, then it is probably something that needs to be done in the code of the rclone backend to B2.

What type of issue are you seeing? (To better understand the need and urgency)

4

Sometimes synchronisation does not take place. I am sending two logs. Either Rclone is not verified with Backblaze, or synchronization is not taking place due to some timeout.
rclone1_log.txt (229 Bytes)
rclone2_log.txt (2.8 KB)

5

Rclone is using API v1 (no idea a v2 had been released!)

However on API Versions it says this, so v1 should be just fine still.

Support for Old Versions

Backblaze does not have any plans to stop supporting old versions. If we ever do make such plans, we will announce them at least a year in advance, to give you plenty of time to update your code.

6

The error in your log is i/o timeout which is almost certainly a networking problem between you and b2.

7

I fully agree with Nick.

Seems like the Backblaze answer was a bit automatic like mine:

but without taking any time to look into your errors:

Get "https://api.backblazeb2.com/b2api/v1/b2_authorize_account": dial tcp 104.153.233.180:443: i/o timeout
Post "https://api003.backblazeb2.com/b2api/v1/b2_list_file_names": dial tcp: lookup api003.backblazeb2.com: no such host

Both errors indicate a network issue contacting (dialing) the servers at Backblaze and have absolutely nothing to do with the API version. The errors happen while trying to send the API request and basicaly says "recipient not answering/unknown".

I checked your other post and guess you have an issue with the stability of your local network. This is not that uncommon if using WiFi and Windows. Here are a few things to check:

Open a terminal and let this command run while using rclone (or just generally):

ping -t api.backblazeb2.com

if you see a period with "Request timed out" or "General failure" then try checking the Event Viewer for errors/warnings. You may see "WLAN-Autoconfig" which is Windows resetting your network card/driver after connection issues (could be network noise, incompatible router etc etc).

8

It can't be a network problem. It is a cloud VPS server to which I am connected via RDS. So if the network was not working at the time Rclone fails to connect, my RDP connection would crash as well and that won't happen.

After a few retries of running the sync, it eventually does. This is without me changing anything.

9

Agree, the issues aren't related to WiFi then, but the above errors are network errors, so something isn't working well between your VPS and the Backblaze servers.

I therefore still suggest you try the above ping command and then supplement with tracert to narrow in on the failing hub/switch when you see the issue.

10

I'm wondering, when you write about the tracert command, if it might be related to DNS servers. Currently the settings are on the ISP's servers, I can try to change to DNS from Google for example.

11

This could be a connectivity or DNS issue:

dial tcp: lookup api003.backblazeb2.com: no such host

This is a pure connectivity issue (the hostname api.backblazeb2.com has been resolved to 104.153.233.180):

dial tcp 104.153.233.180:443: i/o timeout

Are you pressing your VPS with respect to CPU or network capacity? (are you above 90%)

12

Exactly not. Backing up to Backblaze is done at night when no one is working on the server and the CPU load is minimal.

13

OK, then I am out of guesses, time for systematic analysis.

I once had an unstable ISP and ended up making a script pinging the hosts along the traced route, so I could pinpoint the exact time and component failing at recurring intervals. This way I managed to locate a defective component in the ISP's infrastructure, much to their surprise. I suggest you do something similar. Could be that everybody had the same thought as you and this overloads (part) of the network at night.

14

OK, thanks for the tips.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.