Backup failed on B2 Storage: TLS handshake timeout

Support
#1

Hi, I use duplicacy 2.2.3 on various machines on cron jobs. They all use one Backblaze (b2) repository as default storage.
In the recent weeks I often get errors:

Storage set to b2://de-xxxxxxxxx-duplicacy
Failed to load the Backblaze B2 storage at b2://de-xxxxxxxx-duplicacy: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: net/http: TLS handshake timeout

So the backups are not successful for these days.

In a script file, I use the following syntax to check if there are errors or not, but it does not to get triggered, although the backup was clearly not completed.

if [ $? -eq 0 ]
then
  echo "Backup finished."
else
  echo "ERROR on last backup"
fi

Do you can help me with the problem? Thanks in advance!

#2

What do you mean it doesn’t get triggered? Are you saying your script isn’t getting triggered? If so, how are you calling it?

Or are you saying it isn’t matching on a conditional you expected it to based on the exit code? What exit code are you getting in this scenario?

Possibly relevant thread

1 Like
#3

Hi leerspace, thanks for your reply.
With the code

if [ $? -eq 0 ]
then
  echo "Backup finished."
else
  echo "ERROR on last backup"
fi

I check the status of the duplicacy command called before (all in an .sh script file).

Actually I had a typo in this, so the exit code of the failed backups (and it also happens with prune) is: 100

Kind regards

#4

Are you sure there’s absolutely nothing in between the backup command and the snippet you’re including? If there’s any other command (e.g., echoing the output or something like that) then you’ll be checking the exit code of the last command before the snippet rather than the exit code for the backup command.

If the backup command is returning a 100, then it seems like it should be hitting the ERROR on last backup message.

#5

Hi, please have a look at the script here: useful-server-scripts/backup.sh at master · DorianVasco/useful-server-scripts · GitHub
However, I can’t find a way to debug the failing connection to B2… do you have an idea?

#6

You can enter an incorrect B2 credential, which will trigger the same code path as the TLS handshake error.

#7

That script looks good to me from just looking at it on my phone. I’m not sure why it wouldn’t work as intended unless Duplicacy isn’t returning the expected exit code. But it seems we’ve already ruled that out.

#8

Yes indeed, the exit code was just a reason why I did not see the failing backups earlier.

I still get the TLS time out errors:

Storage set to b2://de-xxxxxxxxx-duplicacy
Failed to load the Backblaze B2 storage at b2://de-xxxxxxxx-duplicacy: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: net/http: TLS handshake timeout

I tried to use another programm to check the connection (in this case I tried ‘pip install b2’), but it seems to be a duplicacy specific error.

I suspected that duplicacy connects to b2, then crawling all my local directories for changes and starts the upload afterwards. Is that correct? Because the crawling part does take quite a time because of a not so fast LVM snapshot.

Regards
Dorian

#9

No, Duplicacy doesn’t do that. It was only trying to download the file named config from b2 when setting up the storage, and b2_authorize_account is the first API call.

I think it has something to do with the network (are you using an https proxy?) or the root certificates. Can you run duplicacy -log -d list to see how long the tls timeout is?

#10

I tried the recommended command duplicacy -log -d list quite a few times, but it does not return any timeouts…
my last backup log looked like this:

2019-10-18 02:05:20.390 INFO STORAGE_SET Storage set to b2://de-dorianvasco-duplicacy
2019-10-18 02:05:32.827 ERROR STORAGE_CREATE Failed to load the Backblaze B2 storage at b2://de-dorianvasco-duplicacy: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: net/http: TLS handshake timeout
  Logical volume "root-snap" successfully removed
LVM snapshot removed.
2019-10-18 02:05:37.992 INFO STORAGE_SET Storage set to b2://de-dorianvasco-duplicacy
2019-10-18 02:05:48.224 ERROR STORAGE_CREATE Failed to load the Backblaze B2 storage at b2://de-dorianvasco-duplicacy: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: net/http: TLS handshake timeout
#11

What happens if you try to access the API outside of duplicacy? Do you still have connection problems?

curl https://api.backblazeb2.com/b2api/v1/
#12

I ran the line in a loop once a second for about 24 hours, but did not get any timeouts…

#13

What is the output from the curl command?

#14 
{
  "code": "bad_auth_token",
  "message": "",
  "status": 401
}

But no signs of timeouts… I even changed the time of the cron job to a few hours later (to bypass possible network bottlenecks of other tasks), but its always the same.

#15

If you’re sure that the credentials you used with the b2 utility (which you said was working earlier) are the same ones that duplicacy is using, the only other thing I can think of (based on @gchen’s post about invalid credentials hitting this same path) is maybe there being something wrong with how the B2 credentials are being passed to duplicacy. Or maybe there are some old/expired credentials being pulled from somewhere unexpected.

Are you storing the credentials in environment variables, the preferences file, or a keyring?