2 hours ago, BJZwart said:

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

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.

I'm trying to get Off-site copy to Backblaze B2 working.
I have added the rclone config and tested that it sees all buckets.
I now have the rclone.conf file in the appdata folder but what do I now set as path in Off-site copy?

My rclone config is called [BackBlaze] and the bucket BombVault-test.

I tried using BackBlaze:BombVault-test no errors in the container log but nothing is uploaded to Backblaze.

Edited July 2Jul 2 by BJZwart

4 hours ago, BJZwart said:

I'm trying to get Off-site copy to Backblaze B2 working.
I have added the rclone config and tested that it sees all buckets.
I now have the rclone.conf file in the appdata folder but what do I now set as path in Off-site copy?

My rclone config is called [BackBlaze] and the bucket BombVault-test.

I tried using BackBlaze:BombVault-test no errors in the container log but nothing is uploaded to Backblaze.

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!

Thanks, yes it's working now.

Buckets are filling up nicely.

Love this tool, been posting on git as ptmorris1 but wanted to informally request: under dashboard, Last Backups, if it could have start and end time?

Also under the container domain, a search filter. I have a lot of them.

Not sure if you prefer these on git or here?

Thanks!!

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.

Edited July 6Jul 6 by Junker der Provinz

I’ve been using BombVault for a while now and have been very happy with both its functionality and the frequency of updates so great work! That being said Is there currently a way to configure the order in which containers are stopped, backed up, and restarted to account for service dependencies? I know it uses a per-container option to stop other dependent containers during a backup, but I’m not sure whether that can also control the overall restart order or wait for a dependency to become healthy before continuing. In my case, Nextcloud was restarted 36 seconds before Pi-hole, and Authelia was restarted more than 12 minutes before Pi-hole. Both failed to start because pihole was not yet available and they remained stopped afterward. Authelia also protects my Pelican panel and Wings web endpoints, so its failure made the game-server management stack inaccessible until I manually started panel/wings some time later. Is there a way to set the startup order such as Pi-hole first, then wait for it to become healthy, followed by Authelia, Nextcloud, Pelican, and other dependent services? If not it would be extremely useful.

Hey @Kazem , thanks for your kind words. I'll look into it next week when I'm back home and give you some more details then. I'm always glad to see feature requests on BombVaults GitHub site, since it's easier for me to stay on top of everything there. Feel free to open an Issue there if you want to.

Hi, all is working great, except for very large files backup (more than 1 Tb), always getting this error at 11 hours 59 minutes

On 8/1/2026 at 4:42 PM, Ajuntament Sant Pol de Mar said:

Hi, all is working great, except for very large files backup (more than 1 Tb), always getting this error at 11 hours 59 minutes

Hi, thanks, glad it is working well otherwise. That error is a hard 12 hour cap on a single backup run: BombVault detaches a backup so it survives a closed browser tab, but it also stopped a run after 12 hours so a wedged job could not hold the repository lock forever. For a backup over 1 TB, especially to a slower or cloud target, 12 hours is simply too short, which is why it stopped at 11 hours 59 minutes with "context deadline exceeded". That is fixed in v7.2.0: the cap is now 48 hours by default and configurable with a new BACKUP_MAX_HOURS setting (a number of hours, or 0 to remove the cap entirely). Update the image, and if 48 hours is still tight for your dataset set BACKUP_MAX_HOURS higher. Thanks for the report, and feel free to open a GitHub issue any time for things like this so I can track them.

On 7/30/2026 at 7:02 PM, Kazem said:

I’ve been using BombVault for a while now and have been very happy with both its functionality and the frequency of updates so great work! That being said Is there currently a way to configure the order in which containers are stopped, backed up, and restarted to account for service dependencies? I know it uses a per-container option to stop other dependent containers during a backup, but I’m not sure whether that can also control the overall restart order or wait for a dependency to become healthy before continuing. In my case, Nextcloud was restarted 36 seconds before Pi-hole, and Authelia was restarted more than 12 minutes before Pi-hole. Both failed to start because pihole was not yet available and they remained stopped afterward. Authelia also protects my Pelican panel and Wings web endpoints, so its failure made the game-server management stack inaccessible until I manually started panel/wings some time later. Is there a way to set the startup order such as Pi-hole first, then wait for it to become healthy, followed by Authelia, Nextcloud, Pelican, and other dependent services? If not it would be extremely useful.

Hey @Kazem , back home now and I had a proper look at this, as promised.

Right now the per-container option only stops and later restarts the dependencies you name for that one container's backup window; it does not yet model a global restart order or wait for a dependency to become healthy before continuing. That is exactly the gap you hit, with Pi-hole not up yet when Authelia and Nextcloud came back. So the useful feature here is not just a backup order but an ordered restart with a wait-for-that-dependency-to-be-healthy gate, and that is what I would build toward.

There is already an open issue on GitHub for backup and restart ordering, #119, and I have added your scenario to it. Feel free to jump in there with anything: your concrete example (Pi-hole first, wait until it is healthy, then Authelia, Nextcloud, Pelican and Wings) is exactly the kind of detail that helps me get the design right. Thanks again for the detailed report.

Setting up off site backup is confusing, unless im missing something obvious. weeks ago I got backblaze setup with rclone, but i think I have to go to the recovery page, to set up the r2 config and hit save. then go back to the settings to configure the rclone backup. if thats the right path, to me that is super unintuitive, considering there are settings for rest credentials in the settings page.

now im here trying to setup vm backup, but its failing yet the primary container backup connection is working fine.

what am I missing?

43 minutes ago, roachman said:

Setting up off site backup is confusing, unless im missing something obvious. weeks ago I got backblaze setup with rclone, but i think I have to go to the recovery page, to set up the r2 config and hit save. then go back to the settings to configure the rclone backup. if thats the right path, to me that is super unintuitive, considering there are settings for rest credentials in the settings page.

now im here trying to setup vm backup, but its failing yet the primary container backup connection is working fine.

what am I missing?

Hi @roachman, thanks for the report, real bug on your end.

Off-site credentials: the rclone/S3 cards were wrongly hidden behind Advanced mode in Settings, that's why only the Recovery page worked. Fixed for the next release. For now: enable Advanced mode (top right of Settings) and they'll show up directly on the Off-site tab, no need to go via Recovery.

VM backup failing: separate from the above, most likely cause is the SSH connection to your Unraid host (VM backup needs that, container backup doesn't). Check Settings → System → SSH status, and post the exact error if it's still failing.

Bug reports and feature requests are always best on GitHub, I catch those fastest there: https://github.com/junkerderprovinz/bombvault/issues 🙂

55 minutes ago, Junker der Provinz said:

Hi @roachman, thanks for the report, real bug on your end.

Off-site credentials: the rclone/S3 cards were wrongly hidden behind Advanced mode in Settings, that's why only the Recovery page worked. Fixed for the next release. For now: enable Advanced mode (top right of Settings) and they'll show up directly on the Off-site tab, no need to go via Recovery.

VM backup failing: separate from the above, most likely cause is the SSH connection to your Unraid host (VM backup needs that, container backup doesn't). Check Settings → System → SSH status, and post the exact error if it's still failing.

Bug reports and feature requests are always best on GitHub, I catch those fastest there: https://github.com/junkerderprovinz/bombvault/issues 🙂

Thanks, didn't realize it was a bug. before I report, am I missing something here? I hit save config and it says saved. but test connection fails for both. these credentials on backblaze are fresh and verified correct.

I have enabled SSH "Connected — libvirt reachable"

2 hours ago, roachman said:

Thanks, didn't realize it was a bug. before I report, am I missing something here? I hit save config and it says saved. but test connection fails for both. these credentials on backblaze are fresh and verified correct.

I have enabled SSH "Connected — libvirt reachable"

Two separate things here:

**Test connection failing:** your config has `type = r2` — that's Cloudflare R2's rclone backend, not Backblaze B2's. B2 uses `type = b2` with the exact same `account`/`key` fields you already have (that `K005...` key is B2's own format). Change `type` to `b2`, save, test again.

**Real bug found:** "Test connection" was hiding the actual reason behind a generic "not reachable" no matter the cause — fixed in **v7.8.2**, out now. Pull the new image and it'll show the real error, so this kind of thing is self-diagnosable going forward.

Bug reports and feature requests are always best on GitHub, I catch those fastest there: https://github.com/junkerderprovinz/bombvault/issues 🙂

I'd like to have a way to run curls once the following are complete:

- All container backups

- All folder backups

- Flash backup

- All VM backups

- Self-backup

It seems that currently, this is only possible after each individual container.

Edited August 20Aug 20 by Retrolamer1337

Hi @Retrolamer1337, sorry for the slow reply, and thanks for the request. It landed while v8.0.0 was being built, and it turned out to be one of the things that release adds.

8.0.0 went out today.

You were right that per-container hooks were the only thing on offer. v8.0.0 adds Backup Everything: one pass that runs containers, then VMs, then flash, then folders, then

BombVault's own config, with its own pre-hook and post-hook. Those run on the host shell, not inside a container, so a curl is exactly what they are for. You will find it in

Settings, and it takes its own schedule.

The post-hook fires once, after all five have been attempted, and it fires whether they succeeded or not. That is deliberate: a hook that only runs on success is no use as a dead man's switch, because the case you most want to hear about is the one where something went wrong. The single exception is a pass that could not even be recorded as started, where firing would be a false "done", so silence still means something.

Where it does not match your list: you asked for five hooks, one after each group. What ships is one hook after the whole pass. If a single ping when everything is done is the goal, that is covered exactly. If you need a different endpoint after the containers than after the VMs, that is not there yet. Say so and I will look at it.

One caveat worth knowing: the per-container hooks you have today run inside the container, these run on the host shell. Different environment, so a command that works in one will not necessarily work in the other.

On 8/27/2026 at 7:58 AM, Junker der Provinz said:

Hi @Retrolamer1337, sorry for the slow reply, and thanks for the request. It landed while v8.0.0 was being built, and it turned out to be one of the things that release adds.

8.0.0 went out today.

You were right that per-container hooks were the only thing on offer. v8.0.0 adds Backup Everything: one pass that runs containers, then VMs, then flash, then folders, then

BombVault's own config, with its own pre-hook and post-hook. Those run on the host shell, not inside a container, so a curl is exactly what they are for. You will find it in

Settings, and it takes its own schedule.

The post-hook fires once, after all five have been attempted, and it fires whether they succeeded or not. That is deliberate: a hook that only runs on success is no use as a dead man's switch, because the case you most want to hear about is the one where something went wrong. The single exception is a pass that could not even be recorded as started, where firing would be a false "done", so silence still means something.

Where it does not match your list: you asked for five hooks, one after each group. What ships is one hook after the whole pass. If a single ping when everything is done is the goal, that is covered exactly. If you need a different endpoint after the containers than after the VMs, that is not there yet. Say so and I will look at it.

One caveat worth knowing: the per-container hooks you have today run inside the container, these run on the host shell. Different environment, so a command that works in one will not necessarily work in the other.

Sorry, I cant find the "Backup Everything" Section you are talking about. Using 8.3.0

Hey @Retrolamer1337, that one is on me. I said "in Settings" and left it at that, but the Settings page has seven tabs, so it was not much of a direction.

It is on the Schedules tab, and it is the last card on it, below the five per-domain schedules. Adding #schedules to your Settings URL jumps straight to that tab.

The card is titled "Backup Everything" and it has been in every release since 8.0.0, so 8.3.0 has it. If it is still not there once you are on that tab, say so and I will dig further.

I'm trying to set up an offsite and have two issues.

On the remote end I'm trying to monitor the destination but i get an error message trying to save the settings - "could not open the received repository: wrong APP_KEY, or the location is not a BombVault[path] repository"

Secondly,

I'd also like to set up the remote restic to be immutable, but the test always fails.

Despite the fact that the remote restic reports in its logs that it is-

Data directory: /data
Authentication enabled
Loaded htpasswd file /data/.htpasswd
Append only mode enabled
Private repositories disabled
Group accessible repos disabled
start server on [::]:8000

Broadly the docco is too light - it really needs more examples so I don't have to spend so much time reading between the lines and guessing at settings until things work. I couldn't get the scripted deployment of a restic docker functional, and it couldn't be edited in the docker UI, so I used one from CA instead.

As I suggested in a feature request on github, I think the immutable offsite should be baked into the product, not instructions for a docker you can't manage in the Unraid UI. All the components needed are there inside bombvault. I'd also find it more logical if the flow of the app was more like other backup products where there are sources, jobs and repositories, but hey- I can manage with that.

23 hours ago, Junker der Provinz said:

Hey @Retrolamer1337, that one is on me. I said "in Settings" and left it at that, but the Settings page has seven tabs, so it was not much of a direction.

It is on the Schedules tab, and it is the last card on it, below the five per-domain schedules. Adding #schedules to your Settings URL jumps straight to that tab.

The card is titled "Backup Everything" and it has been in every release since 8.0.0, so 8.3.0 has it. If it is still not there once you are on that tab, say so and I will dig further.

Nice, thank you! Found it and works well.

Hey @luke.smith.name, thanks for taking the time to write all that up. It was genuinely useful, especially that you separated what went wrong from what you thought was causing it. All six points are in v8.4.0: https://github.com/junkerderprovinz/bombvault/releases/tag/v8.4.0

1. Receiver location. A path under /mnt is a host path, and BombVault runs in a container where the host's /mnt sits somewhere else. The error blamed the APP_KEY, which sent you off in the wrong direction, and I'm sorry that cost you time. It now names the relative path to use instead. One more thing worth knowing: the Sending APP_KEY is the sending box's key, not the receiver's. That one catches almost everybody.

2. Tamper test. A 404 from the far side was being read as a pass. It now says "inconclusive" rather than claiming a protection nobody actually demonstrated.

3. The restic container. You were right about the symptom. The docker run itself is fine, I checked it against a real rest-server, but a container Unraid did not create from a template has no Edit form behind it, so falling back to a CA container was a perfectly sensible move. The wizard now also gives you an "Unraid template (XML)" tab: save it under /boot/config/plugins/dockerMan/templates-user/, then Docker > Add Container. Every field stays editable and --append-only stays where you can see it.

4. Docs. There's now a worked two-box example with real values, five steps, and a table for what protected / NOT protected / inconclusive each mean. It calls out both traps from point 1. Translated into all 25 languages.

5. "Immutable baked in." Half done, and I'd rather say so than pretend otherwise. The recipe path is fixed above, and the protection card now marks an off-site copy that isn't append-only as an amber gap instead of a grey dash. What's still missing is BombVault deploying the receiving container itself. That touches the receiver model, which is new, so I'd rather give it its own round than rush it in here.

6. Sources / jobs / repositories. This one deserves a proper discussion, so it has its own issue: https://github.com/junkerderprovinz/bombvault/issues/190

Interesting thing I found while writing it up: all three axes already exist in the data model. What's missing is a name for a combination and a screen that shows them. I'd really like your take there, especially on what you went looking for and didn't find.

And a small favour, if you don't mind: for bugs and feature requests, GitHub issues are the best place.

https://github.com/junkerderprovinz/bombvault/issues

It just means I can link them to the commit that fixes them and come back to you when it ships, which is harder to do from a thread. Questions, ideas and general chat are always welcome here though, and thanks again for the detail.

4 hours ago, Junker der Provinz said:

Hey @luke.smith.name, thanks for taking the time to write all that up. It was genuinely useful, especially that you separated what went wrong from what you thought was causing it. All six points are in v8.4.0: https://github.com/junkerderprovinz/bombvault/releases/tag/v8.4.0

1. Receiver location. A path under /mnt is a host path, and BombVault runs in a container where the host's /mnt sits somewhere else. The error blamed the APP_KEY, which sent you off in the wrong direction, and I'm sorry that cost you time. It now names the relative path to use instead. One more thing worth knowing: the Sending APP_KEY is the sending box's key, not the receiver's. That one catches almost everybody.

2. Tamper test. A 404 from the far side was being read as a pass. It now says "inconclusive" rather than claiming a protection nobody actually demonstrated.

3. The restic container. You were right about the symptom. The docker run itself is fine, I checked it against a real rest-server, but a container Unraid did not create from a template has no Edit form behind it, so falling back to a CA container was a perfectly sensible move. The wizard now also gives you an "Unraid template (XML)" tab: save it under /boot/config/plugins/dockerMan/templates-user/, then Docker > Add Container. Every field stays editable and --append-only stays where you can see it.

4. Docs. There's now a worked two-box example with real values, five steps, and a table for what protected / NOT protected / inconclusive each mean. It calls out both traps from point 1. Translated into all 25 languages.

5. "Immutable baked in." Half done, and I'd rather say so than pretend otherwise. The recipe path is fixed above, and the protection card now marks an off-site copy that isn't append-only as an amber gap instead of a grey dash. What's still missing is BombVault deploying the receiving container itself. That touches the receiver model, which is new, so I'd rather give it its own round than rush it in here.

6. Sources / jobs / repositories. This one deserves a proper discussion, so it has its own issue: https://github.com/junkerderprovinz/bombvault/issues/190

Interesting thing I found while writing it up: all three axes already exist in the data model. What's missing is a name for a combination and a screen that shows them. I'd really like your take there, especially on what you went looking for and didn't find.

And a small favour, if you don't mind: for bugs and feature requests, GitHub issues are the best place.

https://github.com/junkerderprovinz/bombvault/issues

It just means I can link them to the commit that fixes them and come back to you when it ships, which is harder to do from a thread. Questions, ideas and general chat are always welcome here though, and thanks again for the detail.

Thankyou for the comprehensive reply, with the new release and this help I've got a few steps further forward but have now hit this on the remote end:

I then connected to the bombvault container on the remote end and tried to use the restic cli there to check and repair, but I don't have the password.

Bombvault says that the restic password is derived from the bombvault key.. but doesnt say how. Can I translate it?

(I'm fairly sure the password restic is asking for is separate from the restic-server password thats used for connections over the network, but i have tried that too.)

EDIT- somewhat obviously the password is in my recovery kit!

Edited September 2Sep 2 by luke.smith.name
corrected my own misunderstanding.

@luke.smith.name
Glad that got you further, and the edit answers it: the password is in the recovery kit.

Worth adding, because it is the part that catches people: for a repository you RECEIVED, the password comes from the sending instance's APP_KEY, not the receiving box's. Deriving it from the wrong key looks exactly like a corrupt repository.

You do not need the kit either. It is computed, not stored:

printf 'bombvault:restic-repo' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r | cut -d' ' -f1

On "repository contains errors": try restic repair index first, then restic repair snapshots if snapshots stay unreadable. BombVault only reads a received repo, so it will not repair it for you.

All of this is in v8.5.0: the Receiver page now says it when a check fails, the encryption card names the kit, and the derivation is in the docs.

Bugs and feature requests are best on GitHub, that way I can link them to the fix and come back to you when it ships: https://github.com/junkerderprovinz/bombvault/issues