KluthR

Well, it does exactly this. It checks if the destination is available and writeable. But I will look if I find an issue.

Please post the url (edit screen -> advanced view) of one affected container

Dont select the ab_ folder, select the parent folder. Please provide debug log either by ID or as attachment

No clue. I call the native flash backup method, so no own magic here. Absolutely! Nice idea. A grouping option is already on the list. Were notifications disabled?! The next days, Im on it.

You are talking about write the backup two more destinations? If yes, then its better to write a post run script which do a copy.

I switch it to info level but leave it there. You are right, if the user searches for a reason for an unwanted behavior, he reads the log and would notice it anyway. Your script looks fine to me. Please look inside the debug log (or submit it), it holds the actual reurned code The backup file operations are working on a higher level (filesystem). I dont have any option to set something related to network transfers. I'll add an option the next time. Could take a few days. Exactly. And thanks for helping out on this thread!

Its not broken. Its intended to leave failed ones alone.

Not true. the debug ID has not any error in it and successful backups. The final message is new and is triggered always, just for information, like a normal success-notification. If this really causes flood messages, I would bring in an option to disable it? I implemented that with the idea of "maybe the user is not aware of it, notice it inside the log as a warning". Maybe setting the notification level to errors only is better for your setup? Its really just a warning. Any critical would be reported as error. Hmm. Thinking about it, maybe its just worth an information then. Thats right and needs to be fixed. Its because of the ".. done" suffix, if the result is ok. No need for 2 2nd line then. But in case of an error, there is a need for a second line. Noted. Thats a weird thing I never managed to understand completely: The 100% Unraid way. And thus said, I dont get why it does not work sometimes. The Unraid way calls the Docker API. And docker itself returns a failure here. I catch this and try it via "docker stop xxx" which seems to work then. The docker API does not tell me whats the problem. I never faced the issue on my end, so no permanent issue which I could try to debug. You could check the /var/log/docker.log for infos or check the Unraids log terminal if any messages appeared for those failures. Those messages are ok. I still dont get whats causing the error. Never seen that before That was my fiurst idea as well. I need to let the plugin check for volumes used in multiple containers..

Thanks bit this time the syslog file is empty. The syslog.1 (previous one) last line is dated 28.9. weird. please try this: open the log window and observe the output while install the plugin. Maybe you can copy and paste the section during install.

The last one can be ommited. And yes, that includes all subfolders as well.

Try using /mnt/cache/appdata instead of /mnt/user. You have to use absolute paths. But yes, then it would work

I find no entries within the logs regarding plugin installation. At which time did you tried the setup?

On 6.12.4? What other plugins are installed? Maybe add a diagnostic file.

Please retest with new version uploaded just now. Any occurring error should now show up.

The restore just restored the volume(s) and the template(s), if any. I wanted to add a docker container restore in a future version.

I add a feature which calls the script with some arguments soon, so you can target the current backup dir directly.

No. And I dont see any positive reason to make a single file with everything.

Interesting found. Is /mnt/user/appdata a symlink aka exclusive share?

You are right, adding to the todo. If the backup stops, you can scroll up again. Because there is currently no limit setting. Some users observed decreased overall server perfoemance.

Of course, it uses it since the beginning. Have you issues getting those?

Checkout the „Compression: Yes, multicore“ setting

Please open the per docker setting and show me what you see as volumes there. I bet the actual dpcker mapping is /mnt/cache which is different from /mnt/user. Whats the content of Allowed Sources?

Cant confirm. In the cases krusader and Plex the debug log clearly states: Calculated volumes to back up: /mnt/user/appdata/binhex-krusader and Calculated volumes to back up: /mnt/user/appdata/Plex-Media-Server which is expected. Note, that at this point, any exclude is not yet processed.

There could be a tunable setting - but for now you could set the Compression to Yes and NOT to "Yes, multicore". No, currently not. Please share a debug log ID from an affected run If all indicators saying, that the backup was not running, it probably wasnt running then. The script writes down a PID and as long as this PID exists, the backup runs. As soon as it exist, the PID is no longer an active process. Are you sure that the backup was actually running?? Thats already on the list. I agree. Some simple one liners dont need an extra file but it simplifies script maintenance because the file is reusable and in a central place? Nice one. The plugin could call the ending scripts with an argument to tell it the result. Dont know if it was you, but I wanted a ls -la to get the permssions on those files. No, its always seperated. What does the log say? If unsure, share a debug log ID with me and Ill check whats going on. Please, post a ls -la from failed backups. I want to see the file perms as I dont found the bug yet why its not deletable Found a small yet powerful bug... I fix that later today! There is an empty line in the allowed sources textbox which confuses calclulations! The script should check this but it seems that I missed something. Please share a debug log ID. Yes - for initial setups - but no if the script found it stopped. Any manual abort just stops the current action. If an error occurs within normal run, the container gets back up if it was up before starting the backup.

Exactly. And check whats wrong with your backup by checking the backup log.