Backblaze backup half broken

elmo · October 11, 2026, 1:35pm

B2 backup rotation silently fails with b2 CLI v4

old backups never deleted, bucket fills up

I believe the issue is with the syntax being deprecated as hestia uses v3

elmo · October 14, 2026, 9:18pm

@sahsanu do you have any idea when hestia will update to v4?

sahsanu · October 14, 2026, 9:38pm

Checking upgrade.conf, Hestia currently uses 4.7.1 and I see there is a new 5.0.0 version. I don’t have a blackblaze bucket so I don’t know whether the commands used by Hestia must be changed or what is needed to do. Sorry but I can’t help here.

elmo · October 16, 2026, 8:38am

github.com/hestiacp/hestiacp

[Bug] B2 backup retention/rotation broken with current B2 CLI (b2_v='4.7.1') — old backups never deleted

opened 12:49PM - 18 Sep 26 UTC

closed 06:54AM - 19 Sep 26 UTC

clitnak

### Describe the bug `b2_backup()` in `func/backup.sh` fails to rotate (delete)… old Backblaze B2 backups once the retention count (`$BACKUPS`) is exceeded. The backup **upload** itself succeeds, but old backups are never pruned from B2, so storage usage grows unbounded over time. ### Root cause HestiaCP pins and auto-installs a specific B2 CLI release (`install/upgrade/upgrade.conf`: `b2_v='4.7.1'`, downloaded directly from `https://github.com/Backblaze/B2_Command_Line_Tool/releases`). In B2 CLI v4.x, the command interface was restructured into subcommand groups (`account`, `file`, `bucket`, ...). Most of the old flat commands used in `backup.sh` (`authorize-account`, `clear-account`, `upload-file`, `download-file-by-name`, `get-file-info`, `delete-file-version`) are kept as *deprecated but still-functional* aliases — **except `ls`**, whose interface changed from two positional args (`bucket`, `prefix`) to a single `b2://bucket/prefix` URI, and no longer supports a `--long` flag. This line in `b2_backup()`: ```sh backup_list=$(b2 ls --long $BUCKET $user | cut -f 1 -d ' ' 2> /dev/null) ``` fails with `Invalid B2 URI: '<bucket>'` because `$BUCKET` is passed as a bare positional argument instead of a `b2://` URI. This produces an empty/ garbage `backup_list`, which then causes the subsequent `get-file-info $backup` / `delete-file-version $backup` calls to fail with errors like `Bad file ID`. ### Steps to reproduce 1. Install HestiaCP with a B2 backup host (`v-add-backup-host b2 ...`). 2. Let `v-backup-user` run enough times to exceed the configured `$BACKUPS` retention count for a user. 3. Observe backup log output: ``` b2 ls: error: argument B2_URI: Invalid B2 URI: 'yourBucket' WARNING: `get-file-info` command is deprecated. Use `file info` instead. ERROR: Bad file ID: b2 (bad_request) ``` Old backups are never deleted from the B2 bucket. ### Expected behavior Old backups beyond the retention count should be deleted from B2 as they always were with older `b2` CLI versions. ### Suggested fix Replace the `ls`/parsing line with the current CLI syntax, e.g.: ```sh backup_list=$(b2 ls --json "b2://$BUCKET/$user" 2> /dev/null | jq -r '.[].fileId' 2> /dev/null) ``` (`jq` is not currently a HestiaCP dependency; alternatively this could be parsed with `python3 -c 'import json,sys; ...'`, which HestiaCP already depends on, to avoid adding a new dependency.) The rest of the loop (`get-file-info`, `delete-file-version`) works unchanged since those deprecated aliases still accept a bare `fileId`. ### Environment - HestiaCP: current `main` (confirmed present in the latest `func/backup.sh` and `install/upgrade/upgrade.conf` on GitHub as of this report) - B2 CLI: v4.7.1 (as pinned by HestiaCP's own `upgrade.conf`) - OS: Ubuntu (production HestiaCP server) ### Impact Backups themselves are not lost (uploads still succeed), but B2 storage grows unbounded over time since retention/rotation silently fails on every run using the officially-pinned B2 CLI version.

any idea if its included in the next update?

sahsanu · October 16, 2026, 8:51am

As it’s merged, yes, it should be included in the next release.

calete · October 17, 2026, 3:01pm

Meanwhile the fix makes it into a release (it’s already merged on main — see issue #5727), you can work around it by downgrading the b2 binary to 3.6.0, which is the version your installed Hestia scripts actually expect:

sudo wget -O /usr/local/bin/b2 https://github.com/Backblaze/B2_Command_Line_Tool/releases/download/v3.6.0/b2-linux

sudo chmod +x /usr/local/bin/b2

/usr/local/bin/b2 version # should print 3.6.0

The root cause: B2 CLI 4.x changed b2 ls to take a single b2://bucket/prefix URI instead of two positional args, so b2 ls --long "$BUCKET" "$user" fails — that’s what breaks both the v-add-backup-host verification and the retention cleanup in b2_backup() (uploads still work because authorize-account/upload-file survive as deprecated aliases). With 3.6.0, verification passes and old backups get rotated/deleted again on the next v-backup-user run. When the next hestia package ships, it will bring scripts updated for b2 4.x and re-download the matching binary automatically, so no cleanup needed on your end.

Optionally add the alternative if they don’t want to downgrade: switch the remote backup to rclone with a b2 remote (v-add-backup-host 'rclone' ...), which doesn’t use the b2 CLI at all.