"Error: b2 failed to upload" in an endless job

Hello guys,

Have been trying for a couple of days to complete remote backups to a B2 bucket, unsuccessfully.

  • The /backup folder keeps getting filled with tmp folders like tmp.zx3w54G8nb until eating all my free space, and finally aborting with a not enough diskspace available to perform the backup email repeating every 5 min.
  • Noticed many of such tmp folders contain like the same folder structure and domain_data.tar.zst file inside, so I suspect they’re the same
  • In /var/log/hestia/backup.log, there’s a text block about the backup ending with a summary line telling Error: b2 failed to upload user.2022-03-14_08-20-23.tar, and then the log block repeats itself all over again to the same error.
  • Have stopped the backups and email nagging by pausing the cron job v-update-sys-queue backup
  • As a side note, have been able to rclone copy VPS stuff from the command line to the B2 bucket just fine.

Regarding backup configuration, looks like below. Notice the Application Key was entered, but it’s never displayed:

My questions to you, if you’re so kind:

  • Why does b2 failed to upload seems to start the backup job all over again? A bug? Redundant entries in some queue from previous attempts?
  • If the latter, where are these redundant entries located, so I may get rid of them? I see nothing meaningful in /usr/local/hestia/data/queue/backup.pipe, for example
  • Why is the B2 bucket upload giving me issues? Read in some older post about symbols like +, # in the applicationKey were an issue at the time. Mine indeed has a +. Is this still an issue?

Thanks!

EDIT:

When hitting Local backup = yes, the backup finally finishes successfully, but only locally. Now there’s more info in debug.log though:

ERROR: Missing account data: 'NoneType' object is not subscriptable Use: b2 authorize-account or provide auth data with "B2_APPLICATION_KEY_ID" and "B2_APPLICATION_KEY" environment variables

Anyway, whatever the key error above actually means, it seems there’s an inconsistency in the remote backup process with Local backup = no; the tar files should be created and stored locally first, and then after upload to B2 get deleted.

Just opened a bug about the endless loop issue here.

Can somebody please decipher what’s wrong with my B2 keys? I’ve entered both keyID and applicationKey from a freshly created Application Key and Hestia seemed okay with this. Was that wrong?

I have no idea. Don’t use B2 backup on a daily basis…

Okay… There appears to be an issue with at least latest Hestia (v1.5.11).

Created another Application Key in B2. This time got lucky and there were no odd symbols like +, # in the applicationKey. Now, when trying to fill the new Application ID and Application Key in configure > backup > remote backup, hitting save doesn’t seem to work for me, and the old values still stay.
However, when filling those new values directly into /usr/local/hestia/conf/b2.backup.conf the backup to B2 seems to work this time with that new applicationKey values I just created.

Summarizing: it seems odd symbols in applicationKey is still an issue with latest Hestia, and the form submit of remote backup settings isn’t persisting.

Can someone else please confirm the form submit issue, so I may open a bug report at github? Thanks!

What special characters where inside?

The old applicationKey had a + in it. The new one is only letters and numerals. I think to recall there was a rather old post about such issue here in the forums.

EDIT: Not old at all. Here’s the post.

hey I’m following this VERY interested. I’ve got a 50gb VPS. ONE site has 5gb of uploads in the wordpress directory.

I’d LIKE to start with a different request though: When I pull up this DISCOURSE website forum.hestiacp.com - I’d REALLY like it if I could see the YEAR on the dates. It doesnt’ do me any good to know that it’s ‘Mar 15’ all I care about was ‘This year or previous year?’

I somehow can’t EVER login via the admin username and password. From what I remember I CAN reset the password, but I’m not sure the proper way to reset the ADMIN password in Hestia (when you can’t use the GUI)

I wish I could just sign in via ROOT.

The wordpress version that I’m running is ancient php 7.2 and wordpress 4.8.
I generally have PHP error logging visible.

It’s kindof important that I get a copy of the images off of the website.
The wordpress website doesnt’ currently WORK, I’m going to go back to looking at the error log and application log for that user right now and see if I can figure anything else out.

I wish I could just sign in via ROOT

Has been removed for security reasons. How stupid is it to allow users to allow the use for 2FA and other security features and skip the all those checks if a root / rootpassword is used.

If PW reset is disabled (For a short period it was on default)

Or v-change-sys-config-value POLICY_SYSTEM_PASSWORD_RESET ‘yes’

have you tried just hovering over the date with your pointer?

image

2 Likes

I had the same issue and found a resolution. It looks like when you use the web form in Hestia to enter the b2 data it escapes the special characters in the key when it saves it. It must not be unescaping them when it tries to authenticate with b2.

So the fix is go to the b2 backup config file ( /user/local/hestia/conf/b2.backup.conf ) then remove the escape slashes in the B2_KEY variable.

Save then re-run the backup! It should work now.

@eris, can you confirm this bug?

What character caused the issue?