10 hours ago, manilx said:

I'm also getting this on one VM backup:

VM backup warning: Home Assistant

domfsfreeze failed; snapshot will be crash-consistent.

3 hours ago, manilx said:

I had Bombvault to notify on error and I got this as error message in Unraid Notifications (as I've set to receive them there). We'll see how the next one goes.

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.

This list should scrollable.... and show all the backups from the last day/s, ideally one could choose a date and list the backups of that day.

Edited June 25Jun 25 by manilx

5 hours ago, manilx said:

This list should scrollable.... and show all the backups from the last day/s, ideally one could choose a date and list the backups of that day.

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.

Nice. What about the prune issue. It's broken.....

I'm a bit trying to understand that vs backup/restore appdata plugin?

13 hours ago, Nodiaque said:

I'm a bit trying to understand that vs backup/restore appdata plugin?

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.

I deleted a VM and want to delete all backups local/remote:

I have to select all ndividually local and remote and delete them.... Should be a one go command (like in containers if I rember well).

Also then hoping repo's will be pruned....

You didn't comment on this one broken feature :(

Just checked the logs, I got all these errors this night:

2026/06/26 05:00:00 schedule: running containers job

2026/06/26 05:00:00 schedule: running flash job

2026/06/26 05:00:00 schedule: running vms job

2026/06/26 05:00:03 virshcli: "dumpxml" failed: error: failed to get domain 'DietPi_template'

2026/06/26 05:00:03 schedule: vms job: backup "DietPi_template" failed: backup vm: dumpxml: virshcli: dumpxml: error: failed to get domain 'DietPi_template'

2026/06/26 05:02:53 backup: restart dependency "arr-prowlarr-1" failed: dockercli: start: Error response from daemon: cannot join network namespace of a non running container: container arr-gluetun-1 is exited

2026/06/26 05:02:53 backup: restart dependency "arr-qbittorrent-1" failed: dockercli: start: Error response from daemon: cannot join network namespace of a non running container: container arr-gluetun-1 is exited

2026/06/26 05:02:53 backup: restart dependency "arr-radarr-1" failed: dockercli: start: Error response from daemon: cannot join network namespace of a non running container: container arr-gluetun-1 is exited

2026/06/26 05:02:53 backup: restart dependency "arr-sonarr-1" failed: dockercli: start: Error response from daemon: cannot join network namespace of a non running container: container arr-gluetun-1 is exited

I had the gluetun backup shutdown the other containers on backup...
Containers are not restarted.

Edited June 26Jun 26 by manilx

On 6/25/2026 at 6:09 PM, manilx said:

Nice. What about the prune issue. It's broken.....

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

1. 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.

2. 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.

3. 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

4. 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.

just updated and tested:

bombvault v2.8.0

Backup & disaster recovery for Docker containers and KVM/libvirt VMs

Did a flash manual forced prune. Still not working!

22 minutes ago, manilx said:

just updated and tested:

bombvault v2.8.0

Backup & disaster recovery for Docker containers and KVM/libvirt VMs

Did a flash manual forced prune. Still not working!

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

1. Backups now use a fixed host, so new snapshots stay in one group.

2. 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.

I can confirm that this is fixed. Prune is working and respecting the setting.

I have docker container with 700GB of data and backups got growing, so this was quite important ;)

37 minutes ago, Junker der Provinz said:

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.

ab v2.8.0 and let me know how it goes. Thanks as always for the detailed reports.

Also fixed. Backup worked fine and stopped/restarted containers correctly

4 minutes ago, manilx said:

Also fixed. Backup worked fine and stopped/restarted containers correctly

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!

Small GUI error. When I do a manual prune (local/offsite) I get the healthy indicator. But when I switch to the other repo (local/offsite) the healthy stays, in spite of no prune having been run. It should clear this flag when switching repo selector

One more change. My normal backup plan in Backrest is daily local and weekly remote. I have different retention times (prune schedules) for each, remote I keep longer (archive).
In Bombvault I have one single prune schedule.....

11 hours ago, Junker der Provinz said:

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.

I get this error "2026/06/28 05:00:04 virshcli: "dumpxml" failed: error: failed to get domain 'DietPi_template" now each time, how do I get rid of it.
I find this:

There are no local/offsite backups any more. How do I delete this entry

Edited June 28Jun 28 by manilx

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.

Edited June 29Jun 29 by Junker der Provinz

Great job!

All the things I had in mind are already here 😊 Especially the restore stuff.....:
https://github.com/junkerderprovinz/bombvault/issues/19

Question: when I restore a container (or VM for that matter) do you start the container after the restore or leave it off (which I would prefer). Reason: I manage most of my containers via docker compose using stacks in Dockhand (Unraid docker compose plugin is very weak). And to recreate a stack I have to restore all the individual containers of a stack one by one (and they depend on each other, so if one starts without the other having been restored.....)

Ideally I could restore a whole stack 😉 But this I don't even know on how the best way to implement / Interface in the GUI.....

10 hours ago, manilx said:

Question: when I restore a container (or VM for that matter) do you start the container after the restore or leave it off (which I would prefer). Reason: I manage most of my containers via docker compose using stacks in Dockhand (Unraid docker compose plugin is very weak). And to recreate a stack I have to restore all the individual containers of a stack one by one (and they depend on each other, so if one starts without the other having been restored.....)

Ideally I could restore a whole stack 😉 But this I don't even know on how the best way to implement / Interface in the GUI.....

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.

Installed BombVault and it looks great, one issue ran into.

I don't use any VM backup but every time I open the Gui this error appears in the containers log.
error: Cannot recv data: ssh: Could not resolve hostname 192.168.x.x: Name or service not known: Connection reset by peer