Junker der Provinz

Thanks @phunky1, really glad it's useful to you! Both of those are good ideas: - Start and end time on the Dashboard "Last Backups": an easy one, since each run already records when it started and finished, so showing the times (and the duration) there is straightforward. - A search/filter box on the Containers tab: agreed, once you have a lot of them the list gets unwieldy. On where to post: GitHub is the better spot for feature requests and bug reports. Filed as issues they don't get lost in the thread and I can track them properly, so if you don't mind dropping these two into separate issues over at github.comjunkerderprovinz/bombvault/issues that would be perfect. I've noted them down in the meantime either way. Thanks again, and thanks for all the reports as ptmorris1, they've been genuinely helpful.

Hey! The path just needs the rclone: prefix so restic uses rclone instead of treating it as a local folder. That's why it ran without errors but nothing showed up on B2 (it was quietly writing to a local path named BackBlaze:BombVault-test). Set the Off-site copy path to: rclone:BackBlaze:BombVault-test The format is rclone:<remote>:<bucket>, using the exact remote name from your rclone config (BackBlaze here). Keep pasting the rclone config into BombVault's Rclone settings card (not just dropping it in appdata) so it wires the config into restic; since it already lists your buckets, that part looks good. The B2 repo will initialize itself on the first off-site copy. Give that a shot and let me know if it still doesn't push!

Hey, thanks for the kind words and the report! That SSH error was BombVault checking for libvirt VMs on every page load, even when you don't use VM backup. Fixed now: it only talks to libvirt when the VMs domain is turned on. Update to the latest image and the log should be clean.

Good question, and it turned into two features. Thanks for the nudge. First the direct answer: on restore BombVault keeps the run state from the backup. A container (or VM) that was running when it was backed up comes back running, one that was stopped stays stopped. It never force starts. (Small bonus: VMs used to always boot on restore regardless of their prior state, which was inconsistent, so I fixed that at the same time.) For your exact case I added two things, both live on :latest now: 1) A "Leave stopped after restore" checkbox on the restore panel (containers and VMs). It recreates the container without starting it, so you can restore your stack members and bring them up yourself in the right order. 2) Since you run compose stacks, I went further. BombVault now groups containers by their compose project (the com.docker.compose.project label, which it already captures) into a "Stacks" panel above the container list. "Restore stack" restores every member from its latest backup left stopped, then optionally starts them in depends_on order. So a whole stack comes back in one go without members racing ahead of the containers they depend on. It also covers the disaster recovery case where the whole stack was wiped (it restores from the stored definitions, so deleted members come back too), and if a dependency fails to restore it holds back the containers that depend on it instead of starting them into a broken state. Update the container to :latest and you'll see the "Stacks" panel and the "Leave stopped" option. Give it a spin with your Dockhand stacks and let me know how it goes.

Hey @manilx, all three of your latest points are sorted now, pushed out in the new image (v2.9.0): 1. The GUI glitch where the green "healthy" indicator stuck around after a manual prune is fixed. Switching the Local/Off-site selector in Integrity & maintenance now clears the result, so you only ever see a status that actually belongs to the repo you're looking at. 2. Separate retention per repo is in. Settings > Retention is now split into Local and Off-site, each with its own keep-last/daily/weekly/monthly, so you can keep the off-site copies around longer as an archive. The off-site policy starts at all-zero on purpose, which means it won't touch your existing off-site snapshots until you set it yourself, so nothing gets trimmed behind your back. (I also fixed a related bug where a manual prune on the off-site repo was wrongly using the local policy.) 3. The orphaned VM entry (your DietPi_template) can be removed now. If a VM is gone from the host, the VMs tab has a "Remove entry" button that clears the leftover. (If one still has backups, "Delete all backups" in its panel takes care of those.) And the daily "dumpxml: failed to get domain" error is gone too: the scheduler already skips a VM that no longer exists on the host, so once you update and remove the stale entry it stops for good. Grab ghcr.io/junkerderprovinz/bombvault:latest (or :2.9.0) and you're set. Thanks again for the really clear reports, they make this stuff a lot easier to track down.

Happy to have everything fixed for now. If you encounter any further bugs or if you have an idea for a new feature which will make BombVault more versatile, hit me up!

Good catch, and thanks for testing so fast. The v2.8.0 prune fix handled a different failure mode (a stale lock that made prune error out). What you ran into is a separate bug, and I just shipped v2.8.1 for it. What was actually wrong restic stamps every snapshot with the machine hostname. Inside Docker that hostname is a random container ID that changes every time the container is recreated, which includes every update. restic groups retention by host, so after each update your older snapshots landed in a different group and the keep policy was applied per group instead of across all of them. So keep daily 3 looked like it did nothing, because each batch was kept separately. The fix in v2.8.1 Backups now use a fixed host, so new snapshots stay in one group. Prune now groups by path instead of host, so a target's whole history is treated as one set. That also cleans up the snapshots you already have, no matter which hostname they were taken under. What to do Update to v2.8.1, then run the flash prune once. With keep daily 3 it should drop from 9 to 3. Let me know if it does. Thanks again for the detailed reports, they make this much easier to chase down.

Hey, sorry for the quiet day, I was off yesterday and definitely didn't forget you. I went through everything you flagged and just shipped v2.8.0 with all of it fixed. Fixes Prune. It was choking on a leftover lock from an interrupted run, so it never reclaimed space. It now clears the stale lock first, and prune works normally again. Scheduled VM errors (DietPi_template). That VM isn't on the host anymore, so the nightly job kept tripping over it. It now skips any VM that's no longer defined instead of failing. gluetun and the arr containers. They share gluetun's network namespace, and the restart order was backwards, so they came up before gluetun was running. Fixed the order so the backed up container is up and running before its dependents restart. New Delete all VM backups in one click. You can now wipe every backup for a VM at once, per source (local or off site), and it prunes the repo right after. No more removing them one by one. Grab v2.8.0 and let me know how it goes. Thanks as always for the detailed reports.

Yeah, easy to mix up, here's the gist: Appdata Backup plugin Runs as a host plugin. Stops your containers and tars up the appdata folders into a (mostly full) archive each run. Restore = extract the archive back. Simple and solid if that's all you need. BombVault Runs as a container, uses restic under the hood: Deduplicated & incremental — after the first run it only saves what changed, so history barely grows. Optional encryption and off-site copies to S3/B2/rclone. The best part is the restore — it doesn't just dump files back, it fully rebuilds your containers and VMs with their original config, so they reinstall and just show up again in the Docker and VMs tabs, ready to go. Granular too — pull back a single file from any snapshot if that's all you need. Short version: plain appdata archives → the plugin's fine. Full container/VM restore that puts everything back in place, with incremental history and off-site → that's BombVault.

Done, that's in now. The Run History on the dashboard is scrollable and shows the full recent window instead of just the last few, and there's a Day dropdown to filter down to a specific day's backups. Hover a row's time and you'll get the exact timestamp too. It's in the latest image (2.7.2). Grab the update and have a look.

Good news, the update should make that one go away. That fsfreeze message isn't a failed backup, it's the safety fallback: when Home Assistant's guest agent can't freeze the filesystem, BombVault just takes a crash-consistent snapshot instead of bailing, and the backup still completes and restores fine. The reason it reached you as an error is that it ran on an older build, which surfaced that fallback as an error notification. The current build (2.7.1) handles it silently and reports the backup as a success, so with "notify on error" you won't get pinged for it anymore. I also added the running version to the startup log in 2.7.1, so you can open the container log and confirm which build you're actually on. So let's see how the next one goes, it should be clean. If it still comes through as an error on 2.7.1, that would mean both the frozen and the crash-consistent snapshot failed (a real one), so grab that log line and I'll take a look.

That one's not a failure, it's the safety net doing its job, so your backup is fine. Here's what's happening: for a live VM backup BombVault asks the guest agent to briefly freeze the filesystem (fsfreeze) so the snapshot is application-consistent. Home Assistant's qemu-guest-agent has an fsfreeze hook wired into HA's own backup manager, and it often blocks or fails (especially around HA startup). Rather than fail the whole VM backup over that, BombVault retries the snapshot crash-consistent (without the freeze) and carries on. That's the message you saw. Crash-consistent just means the disk was captured as-is, exactly like a clean power-cut. HA recovers from that on boot like nothing happened (its SQLite recorder DB journals/recovers), so the backup is fully restorable. The only thing you lose vs a frozen snapshot is the "guaranteed quiesced at this instant" guarantee, which for HA isn't worth failing the backup over. If you want a guaranteed application-consistent HA backup, set that VM's method to Graceful (it shuts HA down for the snapshot, then starts it again) instead of Live. Otherwise Live + crash-consistent is perfectly safe to keep using. One thing to confirm: on the latest image (:2.7.0) this is just an informational line and the backup still reports success. If you're seeing it pop up as an actual red warning/failure, tell me the image tag you're on and where it shows, and I'll take a look.

Thanks a lot for trying it and for the really useful report. All three turned out to be the same root cause: the manual "back up all" was driven entirely by your browser, so anything that interrupted the browser killed the run. You found a genuinely nasty edge of it. All fixed in the latest image (:2.7.0 / :latest): "Select All" including BombVault itself. Yep, that was a self-inflicted one: when the loop reached BombVault it stopped its own container mid-backup, which killed the whole process. BombVault now knows its own container, refuses to back itself up, and is excluded from "Select All" (its card shows a short note instead of a backup button). Its own settings are recoverable separately via Discover anyway. Browser/session dependency (the Chromium one). Spot on. Each backup ran on the HTTP request that started it, so when the backup reached the Chromium container hosting your UI, stopping it dropped the connection and cancelled the running backup. Backups now run under a detached context on the server, so losing the browser no longer interrupts them. The random stops after Fenrus. Same cause: the loop lived in the browser, so any connection hiccup (or a request timeout on a long-held POST) stopped the whole sequence wherever it happened to be. "Back up selected" is now a real server-side batch: one request kicks it off and the server backs up each container in turn, fully independent of your browser. Close the tab and it keeps going; reopen it and the progress reconnects. Only one batch runs at a time. Update to the latest image and give "Select All" another go. If anything still stops, grab the container log around the point it stops and I will dig in. Thanks again, this was a great catch.

@manilx Good catch, and you're reading the policy right: with keep-daily 14 you'd expect 22/6 and 23/6 to each collapse to one snapshot. The reason it didn't happen: "Prune" only ran restic prune, which reclaims space but never applies your keep-rules. The retention (restic forget --keep-daily) runs automatically after each backup, so a policy you just set takes effect on the next backup, not on a manual prune. I've changed the Prune button so that when a retention policy is set, it now applies it (forget --keep-* --prune): clicking it collapses snapshots per your policy and reclaims space in one go. So your 22/6 and 23/6 pairs will each reduce to one. With no policy set it stays a plain space-reclaim, so it can never wipe a repo. Quick heads-up since this makes Prune able to actually remove snapshots: the confirmation dialog now spells that out. It's in the latest image (:2.6.0 / :latest, multi-arch). Update and force a prune on that VM repo and the same-day pairs should merge. Thanks again for the sharp report.

Yes, the indicator is on all three domains — Containers, VMs and Flash — both on each domain's own page and on the Dashboard (labelled per domain). What you saw is expected: you clicked "Replicate now" on the Settings page, so the feedback there is the button itself flipping to "Replicating…". The Dashboard is a separate page, and a VM replication of an already-seeded repo is quick (restic copy only ships the new bits), so it finished before you switched over. The Dashboard/page indicator shows a replication while you're actually looking at that page — e.g. a scheduled off-site run, or the automatic replication right after a backup (if you leave the off-site schedule blank). Sit on the Dashboard and trigger a replicate, or let a scheduled/after-backup one run, and you'll see it light up.