After I checked all the VM's I found a .bombault.tmp in the domain folders. Deleted that, fixed as mentioned above the wrong disk setting and now ALL VM's did a live backup just fine!!!!!!

How's that 😉

Spoke to soon, in fact I was thinking that it was a live backup, the VM's where shutdown/restarted. I don't like it to be like this. It does not warn me that it will shutdown/restart it just does this.

Another thing I mentioned previously. Upon install and 1st run it created the /mnt/user/bombvault folder indiscrimenantly! On both servers I had to cli delete the folder because it created a share which even being empty could not be deleted via GUI.

Do not create this folder! Let the user create one and define in settings or create it when defined in settings

One more: there should be an option to delete backups I no longer want.....

Do you run restic prune jobs, to reduce the backup size?

Nothing is using the repo. I get this, how to fix?

Answering myself: deleting all files in the locks folder in the repo/containers.

Should be an option to do this from Bombvault

VM backup is weird. I have one VM which backups live fine, another one, which is a clone of it (with some additional stuff installed) shuts down. Just run a test on each.
After this test I now also get this:

EDIT: looked at the target and found another lock file in there. Deleted it and backups display.

Something is buggy with log files also

Edited June 20Jun 20 by manilx

When trying to restore files from a backup, the shown folders should expandable/collapsible as in a normal file browser, it is not easy as it is to find a file to restore:

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

Hi

on all points you've implemented. Thx!

I'm just giving my user feedback once I encounter it, so excuse the "many" messages.
I've just updated and put it as it's test.

All VM's backuing up live now ✌

One thing which I still don't get:
You mentioned "- 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)."

I get this on a container, which backs up:
There is no backup, how do I restore the container when it is deleted? (Apart from the UR appstore but If I deleted the yaml I can't here)

What if I want to restore a previous config? I might have altered stuff wrongly.

Edited June 21Jun 21 by manilx

ToDo:

Remote targets, not only rclone (don't use it). I have a restic server remotely and attach it to backrest via rest:http://server:port/folder

Also S3 as target would be nice. (no rclone)

ToDo:
Pushover notifications (and others). Don't use webhooks or matrix....

BUG:

I did run a live update on all VM's: went fine
Subsequent runs have the error again vm live backup: snapshot: virshcli: snapshot-create-as: error: unsupported configuration: external snapshot file for disk hdc already exists and is not a block device: [path]

Reason:

Again there is a leftover in the domains folders:

This should auto-delete

Just tried latest update. Live update is fixed. Leftover files are deleted

fixed also 😉

Trying restores now:

Container without data folders.

restored just fine! Nice one.

Before trying to restore some with data folders I need to know the following:
Do you save the folder permissions (appdata and other folders)? As some need specific permissions as you know.
So a full restore must set the correct/old permissions.

Regarding notifications:

Forget implementing pushover etc. We have the standard Unraid notifications, which can be pushed to those services.
Just add an option to have the notifications received in Unraid:

2 hours ago, manilx said:

Regarding notifications:

Forget implementing pushover etc. We have the standard Unraid notifications, which can be pushed to those services.
Just add an option to have the notifications received in Unraid:

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.

Edited June 21Jun 21 by Junker der Provinz

🙏 👏

Wow. I must say that the speed you implement the improvements is awesome.

I'm running this now in parallel with Backrest/Scripts for this week and then switch over.

This might be the missing link for many as backups on Unraid is a PITA with nothing build-in from the start, never understood that. I havd/had QNAP/Synology and it's perfect there.

It's been a pleasure to help.

Regarding remote paths:

My rest server only needs password not user, so I leave user blank?

Also, where do I add the backup paths for remote? I want to keep the local ones, which are set. Remote is for additional offsite.
From what I see now it's either local or....

Tried a flash restore for the 1st time, got this:

Looked the target and this was created:

With respective content in it, so I don't know the state of this. And no way to know because error message has no details,

P.S. I would prefer for the restore to be a zip file, which can used by the Unraid usb flash creator software as is, no manual copy.
And just make it a downloadable link directly from the restore, no need to look up in the target.

Edited June 22Jun 22 by manilx

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.