Have been trying for a couple of days to complete remote backups to a B2 bucket, unsuccessfully.
/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
/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?
Local backup = yes, the backup finally finishes successfully, but only locally. Now there’s more info in
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
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).
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?
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?
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?