KluthR

No, theres an "wizard" - which stiil needs to be extended - which does the job. Please show the restore log. The restore uses the same paths as there were used during backup. Did you changed some names? The tar command is just still running. Please verify this with "ps aux | grep krusader". If this shows a running tar command, its still running. How many files are inside the source container path? Please open up one of the backups and show a picture of the contents. It feels like the templates are there but no container volume got backed up..?

Please share a pic with the latest backup contents and the content of the backup log please

Yea. And now the whole log.

Look into the latest folders logfile or view the log tab contents.

So, the backup log must been in /tmp because its copied from there. As well as the debug log. Very interesting. please check during next backup if there are files inside the tmp folder.

Is a logfile copied to latest backup destination?

Currently not possible. But could be via exit codes. Nice finding! 1 could be the behavior like now 2 could be an indicator for „stop the backup“.

Thats true. Any reboot wipes out the last log. But I understood that the log gets not created directly after backup.

Thats interesting. And the backup is working you say?

Of course it exists. I wanted to check its subfolders. Please run the command again with /tmp/appdata.backup as path.

Cant tell. But Media sounds like some important folder? I really dont know whats worth a backup in Plex. No. There is no reason to backup plugins in my eyes. I read about this some time ago. Could you post the response for the command "ls -la /tmp"?

There is no need to backup the docker.img.

Did anyone tested the current beta?

@jj_uk Just like I thought: the post-run is being executed before copy the log and config. This will be fixed in the next version. I thought docker creates such mapping paths right after starting the container, so I would say it should exist, hmm. When npm is running, could you check the existence of that path? There are helpblocks on several places. Its not that complicated. If you need further help, post back. Could you two share a debug log? Without ANY information, I cant do anything. Is the mapping in question used by another container by chance? The error means that during the backup some contents were changed. So something accessed it during backup. Noted Write a pre-run script that executes: /usr/local/emhttp/webGui/scripts/notify -e "Appdata Backup" -s "Starting backup..." -d "The backup just begun" -i "normal"

@jj_uk Just like I thought: the post-run is being executed before copy the log and config. This will be fixed in the next version. I thought docker creates such mapping paths right after starting the container, so I would say it should exist, hmm. When npm is running, could you check the existence of that path? There are helpblocks on several places. Its not that complicated. If you need further help, post back. Could you two share a debug log? Without ANY information, I cant do anything. Is the mapping in question used by another container by chance? The error means that during the backup some contents were changed. So something accessed it during backup. Noted Never observed that behavior. The schedulung is done via cron and is registered once you hit SAVE.

The log os copied as last step I think. But the missing config file is interesting. Let me test some things.

Since the plugin is able to call scripts with some status info (dunno if the latest already contains that) it should be possible. If I have some time tomorrow I can write you a sample.

Then exclude it everywhere except for the main one.

Any other container using the mentioned volume?

Exactly Not yet. You have to add that complete path to the per-container settings exclusion list.

Oh, yes. Had this issue several times as well.

Nah, thats not entirely correct. The previous version aka 2.0 (not 2.5) has a broken error detection. Guess how many people thought the plugin update to my version caused backup issues like that 😅 https://github.com/Squidly271/ca.backup2/issues/5

Classic. a volume ist used by more than one container. During backup the data inside that folder got changed, thus the error. Solution for now: Exclude this folder for any container except that one(s) who is really writing to it. The next bigger update brings grouping option for containers, maybe you put all those in one group then. I also plan to implement a detection for those cases (volume x in use by more than one container) and display a small warning.

There will be an answer when there is free time for it. Sorry. No need to „bump“.

Hmm. The thing is: the plugin does it the exact same way. like: Unraid and the plugin telling docker „Hey, please stop PMS!“ and docker returns to the plugin then „Server error“ (most likely PMS did not stopped in time then). is PMS logging something for this time the backup ran?