Fixes, one is important enough to upgrade promptly.
Scheduled backups could stop silently after applying a client profile (#420)
If you used Apply to Clients on 2.91.0 or 2.91.1, check your schedules. Applying a profile cleared each affected schedule's next run time, and the scheduler skips schedules that have none — so those schedules stayed enabled, kept showing as active, and never ran again. Nothing appeared in the queue, and manual runs still worked, which made it easy to miss.
Applying a profile now recalculates the next run time. Affected installs repair themselves on the first scheduler pass after upgrading — you don't need to re-save anything. A schedule that has been dead for a while resumes at its next scheduled time rather than firing a backlog of catch-up backups.
Storage on WebDAV and similar mounts reported the wrong size (#415)
df describes whichever filesystem answers it, which on a WebDAV mount is the local cache disk — so a 100 GB share could report the server's own multi-terabyte disk.
- Mounts that can't report their own size now say Capacity unknown, with the reason, instead of showing a wrong number.
- You can state the real size: Storage → the pencil icon on a location → Capacity. BBS then shows that as the total and counts what it has actually written there.
- Low-storage alerts and the health endpoint skip locations whose capacity is unknown.
NFS, CIFS and sshfs report their exports correctly and are unaffected.
Local storage locations also gained an edit form — previously a location's label could not be changed after it was created.
Post-scripts that wait for repository work (#422)
Two fixes for shell hooks set to run after all repository jobs:
- The script received empty
BBS_REPO_PATH,BBS_ARCHIVE_NAME,BBS_BACKUP_PLANandBBS_CLIENT_NAME. It now gets the full context from the backup that triggered it, plusBORG_REPOandBORG_PASSCOMMANDwhen the config exposes the passphrase. - The script ran once per completed backup rather than once per idle repository, so several backups close together queued several runs back to back. It now runs once.
Both are server-side; agents need no update.
Low-storage threshold is one setting again
The Low-Storage Alert At field is back on Settings → General, and now drives both the low-storage notification and the storage warning from /api/v1/health. Those had drifted apart: health warned at a hardcoded 85% while the settings field said 90%, and the field itself had quietly had no effect since per-user thresholds were introduced. The per-user setting is now simply a switch for whether you receive the alerts.
Health endpoint: offline clients are reported, not a fault
A client being offline no longer turns /api/v1/health yellow on its own. Client counts are still reported, but whether a machine is a problem is decided by whether it has missed its backup window — a laptop with the lid shut, well inside its allowance, is not a fault. Clients reporting an error still warn.
Storage administration over the API
Storage locations and remote SSH targets can now be managed through the API, which previously could only list and create them: PUT/DELETE /api/v1/storage/{id} and full CRUD plus connection tests at /api/v1/remote-ssh-configs. SSH private keys are write-only — stored encrypted, never returned.
Agent installer
The installer refused to run in LXC and LXD containers. Those run a real init system and were always supported; it now checks what is actually supervising services rather than assuming no systemd means no init. Containers that can't keep the agent running are still refused.