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.

Glad it's working well for you, and thanks, that means a lot! On the off-site progress: that running indicator landed in 2.5.0, and "Replicate now" has been around since 2.4.0, so if you ran it on an earlier build there was simply no indicator yet. Make sure you're on 2.6.0 (current) and you'll see an "off-site replication running" indicator on the domain's page and on the Dashboard while it copies. One caveat: a flash replication is usually near-instant (small repo, and once it's seeded restic copy only ships the new bits), so the indicator can flash by quickly. I'm making it linger a bit longer so fast replications are easier to catch. Awesome to hear you're running it alongside your normal backups!

@manilx Big update is out: 2.5.0 (it bundles everything from the last round into one release). Off-site backups, now a first-class citizen: - Local + off-site: keep your fast local backup and add an off-site replica per domain (Settings > Off-site copy). Works with any restic backend (rest:, s3:, b2:, sftp:) via Settings > Cloud credentials. The local repo stays primary; off-site is best-effort and never fails the local backup. - Its own schedule: leave it blank to replicate after every backup, or set e.g. "weekly Sun 03:00" to back up locally daily but ship off-site weekly. There's a "Replicate now" button too. - Restore/maintain from either: every backup browser and the Integrity & Maintenance card has a Local | Off-site switch. List, restore, download, verify/unlock/prune and delete against whichever copy you pick. Local repo dead or corrupt? Switch to Off-site and restore from there. - Delete is per-source: deleting only removes the copy you're viewing, never both (stated next to the switch). - A running indicator shows which domain is replicating off-site (on its page and the Dashboard). It's an active indicator, not a percentage: restic copy doesn't expose machine-readable progress like backup does. Flash: - Flash restore is now a .zip download, streamed to your browser, ready for the Unraid USB creator. The live /boot is never touched, and because a zip carries no Linux permissions the old "There were N errors" is gone. It shows live download progress. Fixes from your testing: off-site view no longer shows empty for a remote repo; no more "config file already exists" log spam; stateless containers no longer show a phantom appdata folder; saving settings no longer wipes cloud credentials; REST with password-only works (leave username blank). Update to 2.5.0. Thanks again, this whole wave came straight from your feedback.

Great questions, and both are sorted in 2.4.0 (just released). Delete = per source, never both. Deleting a backup only removes the copy you're currently viewing. So deleting a local backup never touches the off-site copy, and vice versa. That's deliberate, exactly for your scenario: if the local repo is corrupt or gone, the off-site copy is still there to restore from. The restore browser now states this right next to the source switch. Restore from local OR off-site. You were right that you need to choose. Every backup browser (Containers, VMs, Flash) and the Integrity & Maintenance card now has a Local | Off-site switch. Flip it and the list, restore, download, verify/unlock/prune and delete all act on that copy. So a dead local repo is no problem: switch to Off-site and restore from there. Your screenshot is still 2.3.0 (no switch yet). Update to 2.4.0 and it's all there. Thanks again, this feedback shaped the release.

Hey @manilx both of these are done in 2.3.0, and they're tied together nicely. Flash restore "1104 errors": found and fixed. The old restore wrote the files out to a folder and then tried to set Linux ownership/permissions on each file on the /mnt/user share, which the share rejects per file. So your data was always fine, those were metadata-only errors, not data loss. The error box just showed restic's final count without the detail. The fix is exactly your P.S.: flash restore is now a direct .zip download. Pick a snapshot and it streams straight to your browser as flash-<id>.zip, ready to drop into the Unraid USB creator as-is, no copying out of a target folder. A zip carries no filesystem permissions, so the errors are gone. (I also made restic's per-item errors show up in the UI now, so nothing fails with just a number again.) Local + off-site at the same time: also done. There's a new "Off-site copy" section in Settings with a second repo per domain. After each successful local backup, BombVault replicates the new snapshot to that repo with restic copy. Your local backup stays primary and runs as before; the off-site copy is best-effort, so an off-site hiccup never fails the local backup. It works with any restic backend (rest:, s3:, b2:, sftp:), using the same Settings > Cloud credentials. REST with password only: leave the username blank and just set the password, that works. If your server ever rejects it you can also put it in the path, e.g. rest:http://:password@server:8000/repo. One more: saving settings used to wipe your stored cloud credentials in some cases, that's fixed too. Update to 2.3.0 and you've got all of it. Thanks again for the detailed testing, it's been driving most of these.

Update 2.2.0 is live, and it closes out everything from your last few posts. Permissions: yes, fully preserved. restic stores each file and folder's mode, owner (uid/gid), timestamps, ACLs and xattrs, and a restore puts them all back. So appdata that depends on specific ownership or permissions comes back exactly as it was, no manual chown afterwards. Unraid notifications (2.1.0): new option under Settings > Notifications. BombVault posts each backup result straight into Unraid's own notification system, so you set up email/Pushover/etc. once in Unraid and BombVault just feeds it, no separate integration needed. Same policy as the other channels (never / on failure / always), and the Test button covers it. It goes over the host SSH connection (the same one used for VM backups), so that needs to be configured under Settings > VM Backup. Remote targets without rclone (2.2.0): you can now point a Backup Path straight at a restic remote repo, for example: rest:http://your-server:8000/repo s3:s3.amazonaws.com/bucket/path b2:bucket:path sftp:user@host:/repo Credentials go in the new Settings > Cloud credentials card (S3 access key / secret / region, and restic REST user / password). They're stored encrypted and handed to restic as the standard env vars it expects. Secrets are write-only, so they're never shown again after saving; leave a field blank to keep the stored one, or clear everything to remove the config. rclone still works if you prefer it, but it's no longer required for these. Grab 2.2.0 and you've got all of it. Thanks again for the steady stream of input, it's been driving a lot of these improvements.

Both work, you don't strictly need a reverse proxy. A Cloudflare Tunnel is fine for client access and means zero open ports. Two things to know: Cloudflare caps uploads at 100 MB (the README already uses 100M, so that lines up), and for federation you still need the .well-known delegation to 443 (section 6 in the README). Voice/video (TURN) is UDP and can't go through a tunnel or proxy, so forward those ports either way. A normal reverse proxy (NPM, what the README documents) is the cleaner option if you want federation plus bigger media. And if you ever use Cloudflare's orange-cloud proxy instead of a tunnel, set the Matrix subdomain to DNS only (grey cloud), the orange proxy breaks non-browser clients and federation.

@manilx this is gold, thank you. Pretty much your whole list went into 2.0.0, just force-update the container to pull it: - The /mnt/user/bombvault share: fixed. BombVault no longer creates that folder on startup, so no more phantom share you can't delete. It's only created when you actually run a backup. - Delete backups you no longer want: done. Every backup now has a Delete button (containers, VMs and flash). - Prune: retention already prunes after each backup, and there's now a manual Prune button per repo under Settings > Integrity & maintenance to reclaim space on demand. - The lock issue (and "Failed to load backups"): there's now an Unlock button under Settings > Integrity & maintenance, and BombVault also clears stale locks automatically before a backup and when listing backups, so you shouldn't have to touch the locks folder by hand anymore. Same-repo operations are serialised now too, so a backup, prune and unlock can't trip over each other. - VMs shutting down without warning: fixed, and this was the big one. The "live" method now never shuts a VM down. Those shutdowns were an auto-fallback I'd added earlier; it's gone. The real cause for the VMs that kept failing was a leftover snapshot overlay (the .bombvault-tmp file you found and deleted) from an interrupted run. BombVault now detects that and commits it back automatically before the backup, so live keeps working without you cleaning anything up. The method dropdown also spells out graceful = shutdown vs live = no downtime now. - File restore: it's a proper collapsible folder tree now, expand/collapse like a file manager. One I couldn't action yet: you mentioned "something is buggy with log files", can you say a bit more about what you saw (which logs, what looked off)? I'll dig in. Thanks again, genuinely. A big chunk of 2.0.0 exists because of your testing.

Hey @manilx , thanks again for all the testing and the clear write-ups, that feedback shaped a whole release. I bundled everything into 2.0.0, just force-update the container in the Docker tab to pull it. Here's what's in there for the things you ran into: - "Failed to load runs": fixed, and good news, it's not a corrupted database. A backup that was still running or got interrupted left a record the run history couldn't read, and that one record broke the whole list. It loads fine again after updating, no reset needed. Interrupted runs also get tidied up on startup now instead of sitting there as "running" forever. - Containers with no data folder: they now show "Config only" instead of a plain "done", so it's clear no data snapshot was made (the container definition is still saved, so it can be recreated). And there's a new per-container Export button that drops a plain <name>.tar.gz + <name>.xml next to your repo, same idea as the Appdata Backup plugin, if you want the config/settings as readable files. - Containers without an appdata folder no longer fail with "all source directories do not exist". - The dashboard now shows which container/VM a run was for, and the error message when one fails, instead of an opaque snapshot id. - Stop other containers during a backup: each container has a field where you can list other containers (like a database) to stop while it's backed up and start again after. Covers the backrest-style use case, over the Docker API, no scripts. - VM live backups, two things. First, cd-rom / read-only disks are skipped during the snapshot now. Second, and this is the big one for your two VMs: if a live snapshot still can't be created, BombVault automatically falls back to a graceful backup instead of erroring out, so the backup always completes. So those two VMs should just back up now (they may quietly fall back to graceful, which means a short shutdown during the backup). If you'd rather keep them truly live, the snapshot is failing because of how one of their disks is set up. Grab "virsh dumpxml VMNAME" from the Unraid terminal and post it, and I'll get that disk classified properly. One more on the earlier "hash mismatch" on the Windows 11 VM: that one points at the host (RAM or the cache pool), not BombVault. BombVault actually caught it and refused to store a corrupt backup. A MemTest86 run is worth it when you get the chance. Thanks again, this was a great batch of feedback.

Hey, thanks a lot for taking the time to test this properly and write it all up. That kind of detailed feedback is exactly what I needed. Most of it is sorted in the latest version, so here's where things stand. The big one you caught: a backup was starting a container that had been stopped beforehand. That was a real bug and it's fixed now. A stopped container gets backed up in place and stays stopped, and a running one gets stopped for a clean backup and started again afterwards. Restore behaves the same way now, it brings the container back in the exact state it was in when you backed it up instead of always starting it. You also said there was no sign of anything happening during a backup or restore. There's now a live progress bar on each container, VM and flash card that fills up as the job runs, for both backup and restore, so you can actually see how far along it is. On the HTTP_ONLY setting: when it's on, the WebUI link still points at https, so for now you have to open http://[ip]:[port] yourself. I've noted that in the template description. For the Windows VM backup that failed without telling you why, I improved the error reporting, so instead of restic's generic "please open an issue" line you now get the real reason in the UI. About that specific failure: if the message is something like "detected data corruption while saving blob ... hash mismatch", that one is worth a closer look. restic checks every chunk it writes, and that error means the data changed in memory between being read and being written. If you run the backup a few times and it fails on a different block each time, while the disk file itself reads back identical when the VM is off, that points at the RAM rather than at the tool or the disk. The good news is restic refuses to store a corrupt backup, so nothing bad got saved. I'd run MemTest86 (it's in the Unraid boot menu), and if you're using an XMP or EXPO memory profile, try turning it off and testing again. That fixes this kind of thing more often than you'd expect. On backing up other folders: right now it automatically grabs the container's appdata. Choosing which of the container's other mapped folders to include or exclude, plus adding your own paths, is the next feature I'm working on. The Backup Hooks field isn't for that, by the way, it just runs a command around the backup (like dumping a database into appdata so it gets picked up), it doesn't add folders. I made that description clearer too. Good to hear the flash backup and the stopped-VM snapshot both worked for you. And yeah, it's still got room to grow, no argument there. Thanks again for pushing on it, it genuinely makes the thing better. Let me know how the next version treats you.

Thanks for trying it, and for the blunt feedback! 🙏 The "error 400 on some VMs" was a real bug: VM names with a space (e.g. Windows 11) got rejected by a too-strict name check. Fixed in v1.3.4, spaced names back up fine now. The mystery "datastore" is just the restic backup repo, it defaults to /mnt/user/bombvault/ (changeable in Settings → Backup paths). Fair point that it wasn't mentioned anywhere, now spelled out in the description + README. No pressure to switch from your scripts, but if you fancy another go, grab v1.3.4/:latest and it should just work. 👍