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.