Flash restore, just tried. Actually I thought nothing happening and clicked the "download" multiple times, got them respectively. Make a progressbar in the GUI as on the backups.....

Will try the remote backups tomorrow and report.

EDIT: just tried it, only password works fine. Tried with a flash backup. Went just fine.

One change: the user not necessarily wants to replicate the backup each time (bandwidth, speed etc). With backrest i backed up locally on a daily basis but remotely just on sunday....
Would be better to separate remotes from the normal schedule (easy, 99% is done 😉 )

Edited June 22Jun 22 by manilx

How do we restore from the remote location? Only the local are shown...?

Does this also apply to the remote repo?

26 minutes ago, manilx said:

How do we restore from the remote location? Only the local are shown...?

What happens if I delete a backup? Deletes local AND remote copy? This is not clear. I do think local and remote backups should be both shown here, so that I can choose from where to restore.
The local may be corrupt/deleted and I need to restore from remote.

45 minutes ago, manilx said:

What happens if I delete a backup? Deletes local AND remote copy? This is not clear. I do think local and remote backups should be both shown here, so that I can choose from where to restore.
The local may be corrupt/deleted and I need to restore from remote.

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.

Awesome. My offsite copy is currently running, did run at 5:00 with local copy as separare run is new 😉 Will take a few hours....
Will have to check new stuff later.

I have set offsite copy now to "weekly Sun 10:00"

One thing: I know that offsite copy is running but I don't know which one (container/flash/vm), there's no indication anywhere (which I'm aware off).
You could put a copy progress on the individual items (as on local) and/or dashboard.

I just forced a flash backup (with imediate copy to remote, setting is blank), backup concluded but when I switch to offsite view nothing is shown.

Also checking all other backups, nothing is shown in the offsite view. But offsite was done as i can see the data on the remote repo.

Seeing these errors in the log when backups start to run:

2026/06/23 05:39:03 restic init stderr: Fatal: create repository at rest:http://xxxxxx:8000/dxp480t/vms/ failed: Fatal: unable to open repository at rest:http://xxxxxxx:8000/dxp480t/vms/: config file already exists
The repo was created by Bombvault...!?

Check repo results:

Edited June 23Jun 23 by manilx

Ther's a bug in the folder selection of containers. Containers with no appdata or bind mounts show as having a folder:

This folder does not exist. And under backups no backups are shown.

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

all fixed! Didn't try "- 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.".....

It's now in a state that more should use it!!!!!!!
I'm running it parallel to me normal backups now.

Did a flash backup to local than run a "replicate now" but I did not find any progress on the dashboard or the flash backup.....

40 minutes ago, manilx said:

Did a flash backup to local than run a "replicate now" but I did not find any progress on the dashboard or the flash backup.....

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!

I'm on latest. Did a VM backup and then a "replicate". Didn't see anything on the dashboard.... The button changed to "replicating

Is this indicator on all domains/vm's/flash?

38 minutes ago, manilx said:

Is this indicator on all domains/vm's/flash?

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.

Regarding pruning, probably missing something.

I have:

When I force a prune:

Shouldn't the 22/6 and 23/6 backups have been merged to 1 each?

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

Hi,

Bombvault sounds great, so I gave it a try and tested the manual backup by selecting all containers. Here are a few things I noticed:

1. "Select All" behavior: "Select All" probably shouldn't include Bombvault itself. When the backup process reached Bombvault alphabetically, it crashed the backup for me. :-)

2. Browser/Session dependency: On my second try, I unselected Bombvault. However, the backup failed again when it reached Chromium. I was running the Bombvault UI inside that specific Chromium docker container. Does closing or losing the browser connection kill the manual backup process?

3. Random interruptions: For my next attempts, I deselected both Bombvault and Chromium. It failed once during the Emby backup (though that works now, maybe it is still stopped since this try), but the last three times it stopped right after Fenrus (meaning Fileflows would have been next, judging by the timestamps).

   EDIT: It seems it is still running, only the progress bar was missing from time to time. This time it stopped at iobroker (restic backup failed), but usually I would not backup iobroker this way.

   Suggestion: When backup failed, please restore the running condition of the container afterwards.... emby and iobroker both stayed stopped after backup failure and were running before.

Any ideas on what might be causing these stops?

Mike

Edited June 24Jun 24 by mmm77

@manilx

9 hours ago, Junker der Provinz said:

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.

Bombvault was updated at 2AM by app updater plugin. New backup run at 5AM with new version.

Flash has not been pruned. Just to be sure forced update of container again, run prune manually, same issue, 22nd and 23rd should have been merged and nothing happened.

Edited June 24Jun 24 by manilx

I'm also getting this on one VM backup:

VM backup warning: Home Assistant

domfsfreeze failed; snapshot will be crash-consistent.

7 hours ago, mmm77 said:

Hi,

Bombvault sounds great, so I gave it a try and tested the manual backup by selecting all containers. Here are a few things I noticed:

1. "Select All" behavior: "Select All" probably shouldn't include Bombvault itself. When the backup process reached Bombvault alphabetically, it crashed the backup for me. :-)

2. Browser/Session dependency: On my second try, I unselected Bombvault. However, the backup failed again when it reached Chromium. I was running the Bombvault UI inside that specific Chromium docker container. Does closing or losing the browser connection kill the manual backup process?

3. Random interruptions: For my next attempts, I deselected both Bombvault and Chromium. It failed once during the Emby backup (though that works now, maybe it is still stopped since this try), but the last three times it stopped right after Fenrus (meaning Fileflows would have been next, judging by the timestamps).

   EDIT: It seems it is still running, only the progress bar was missing from time to time. This time it stopped at iobroker (restic backup failed), but usually I would not backup iobroker this way.

   Suggestion: When backup failed, please restore the running condition of the container afterwards.... emby and iobroker both stayed stopped after backup failure and were running before.

Any ideas on what might be causing these stops?

Mike

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):

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

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

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

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

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.

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.