KluthR

It is working (if the log does not state something else). And a fix will be made But now affected backups will not get updated as they get discarded over time. Self fixing here.

Yes, thats the case. I have no clue how to fix that in a smart way. Maybe I just move the preRun BEFORE destination existence. Seems smart enough to me. Looks like a missing +x (executable) flag to me. Make sure the scripts are really executable by set rights like "chmod a+x *script.sh*" See Compression Option (Yes, Yes multicore) and its related help block Nope. Only VM meta xml. No more logic to VMs (yet) I cant tell tbh. Have a look into the debug log file at the last few lines (/tmp/appdata.backup/ab.debug.log) Huh, not used for a while now, I check this. There wasnt any fix inside because I could not reproduce the issue tbh. I did a few tests with a test share being the backup destination and I could still work with the files (and see them). The share files were also set to nobody:users and the rw flags are there. But as I just read, there is the executable bit needed to access the folders, so I just add that as well. Yep, thanks for that, I added a comment to that.

You and @Kilrah: I just published a stable update with a debug code inside. Would be great if you could open the browsers developer panel (F12 usually) and navigate to Console. There should be some output like "Volume dup check (affected/matrix):". Maybe that output helps me to find the issue.

Yea just cinformed that by changing it at my end just for you Will be fixed in next update!

I dont test on anything but the default theme. Could you please post a screenshot? I can try to make the color better for non-light-themes.

And those paths are NOT listed 1:1 in any other mapping? Could you PM me (or post it here if you dont care) some paths that seem similar? I have a feeling that the not-so-strict compare method has issues. Not detected during tests on my end

Yes, but I believe the issue is on my side. As requested many times, the plugin now changes the files ownership from root:root to nobody:users. I dont know why but this seems to be an issue? But I cant confirm the issues, I can read them via SMB/Windows. Yea, if you initially have NO groups set at all, there will be no list. Some kind of misleading here. Just type something in and you will have a list for any other container now. Can you confirm that?

If you rebooted or its the first time using the plugin, the log is actualy empty. Its written to /tmp, so not written into the system to be permanently available. If you had at least one backup run, you should see the log. No problem. And yes: the restore assistant needs more love

Hmm. Need to check tomorrow. As well as the second issue you posted.

No. If it was rebuilt/created by unraid, you should be ok after restoring. Please post a ls -a from the path you are having in the restore path field. maybe you could add a screenshot from the restore page with the error message in place?

The libvirt.img is mounted as /etc/libvirt/… the plugin backs up the VM metadata, nothing more. And it restores it there. Anything apart from that (vdisk) needs to be restored/backed up somehow else.

Libvirt is not being backed up, only some contents of its mounted filesystem (the vm definition).

And those ab_ folders have not a suffix „failed“?

Instead or additional. It depends where the primary mapping targets are located at. Otherwise all detected mappings are considered external and only being backed up if „backup external volumes“ is enabled.

As said: Read the "Allowed appdata sources" help block to understand how bind volumes are beind determined as internal/external. You could also submit a debug log within the log tab to let me check your situation. 🤦‍♂️Yea, I just checked and saw, that the exclusions list is not being checked within the function that determines the volumes. I note that and it will be fixed within a next release.

Some update here: the plugin can easily handle named volumes in future. The next beta has support for it.

@trurl Now I see what happened. I believe transmission never got backed up. I recently raised the loglevel for your posted warning to be warn instead just info. So maybe the plugin shows now an issue when it was silent before: https://github.com/Commifreak/unraid-appdata.backup/commit/1d970a9ce0292b53b6c037ba18cad26b1e7ebb35

No. It always worked like that. Maybe you disabled the setting to include external volumes? Yes, that seems right. please also read the help block for the allowed sources paths option.

Please add some recommended Plex excludes (see 1st post)

Please add the mentioned volume path in the exclusion list directly inside its container config.

Just checked that. The fact that one volume within a container is not existing produces the error message but does not marks the whole backup run as failed. errors like tar backup/verification lead to changing the error flag. I dont know if is worth changing.

No, Iam talking about the folder that holds the ab_ folders. And they are there? Cant tell. Please compare a logfile between a 4h run and a 8 hour run. Did you selected the folder that holds the ab_ folders? It always looked inside the tempate. It uses the allowed sources setting to check if the detected template mappings are internal or external volumes/mappings

Please show the contents of the pre-filled directory path (via terminal or via file browser). Are the ab_ folder inside? Yea, the restore function is kinda basic. I plan to enhance it more but time is a limited thing currently. The next step is to make the current beta stable with some more fixes in place.

Did you set the directory containg the ab_ directories or did you selected it directly? the 1st way should be working. Please check the displayed volumes in the settings page. If all all marked external, consider to ignore the container.