KluthR

You can stop docker service, move the img to its default path and start it again. Then stop all containers, move all appdata, adapt every container path mapping and you should good to go*. * No warranty For further question, you should ask inside the docker section.

The plugin does not change any ownerships. I just checked my dev environmemt and all id as it should be. Docker is managing access rights on mappings. what does „unknown“ mean? A number? Like 999? If yes, thats normal. Sounds like an suitable candidate 😂 check your ca.backup2 source config: you are backing up the wrong paths (or your docker.img is inside your appdata). Both cases are unfavorable EDIT: somehow we seem to mix posts for ca.backup2 and appdata.backup…. so: for old ca.backup2: Macj72x: the old plugin should not change ownerships as well.

Yes, because I cant tell which mapping originates from which container. Exact same reason I could remove a mapping once it appeared but it could be backed up within wrong container context which causes confusion. hmm. Have to check tars behavior here. Maybe I have to adjust some details.

Ok, thanks. I will fix all current issues within this week, including your config issue. Please leave your snippet here. You can try to save the settings once, that should do it for you. It will take some days as Iam a bit busy currently. Stay tuned!

I dont see any errors for swag inside the log. I dont think so. Adding the appdata path to exclusions would not backup any other appdata folder for that container. I think, I have to extend the plugins capabilities by that Thats the whole config.json? So, I guess you did not saved it for a long time. There are container parts missing like their config and the start order. Which is not a problem because you are working with defaults. But its worth mentioning. Please confirm that this posted config IS the complete file content. If so, we have a bug here which prevents applying default defaults (yes) to older config versions. I will look into that. Ah I see. swag backups contents of Jellyfin, maybe you want to exclude them (/mnt/cache/appdata/Jellyfin/log) as well as the other container mappings (vaultwarden?).

@Anym001Duplicacy and jellyfin both having volumes within volumes (cache on each). This is working for docker but messes with the tar verification. The plugin script does not handle this currently. It will be, in future version.

Please show the debug log. code-server has a volume mapping to appdata, which will be backed up. Is that mapping correct?? tautullis backup verification fails, because shfs is accessing the Logs (/mnt/cache/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Logs) Since tautulli has a mapping from Plex to backup and Plex is already running again, the files are being changed.

sonarr is dying with exitCode=0 which should be a normal stop, initiated by the container. Stopping some of my test containers show the same beavior. Let one of my test sql start with wrong volumes/corrupt data, ends up in another exitCode. I still dont see, what is failing just because of a name change

I saw those mapping (/:/rootfs). Those end up being empty in the final tar command. With latest plugin update, those will be excluded from the mapping. Should not have before worked anyway.

You should exclude those for grafana as well: /etc /proc /var/run/docker.sock /var/run/utmp /sys as such are mapped to the container and would be backed up too (ext volume backup enabled)

There will be a new update within the next 10 minutes. Could you update and run a manual backup and share the debug log again?

Multiple schedules is not available (yet).

No, that cant be the case, since its a completely new feature Open the per container settings by clicking on its name. There you will find it. Not explicitly enabling it means, it should be off. Im curious what its current state is.

That section should be ok. Could you try this: Open a terminal, enter "docker system events" this starts a real-time docker event output. Start sonarr (which is failing) and let it crash. docker should output some lines, ioncluding "container die". Please post that here along with a "docker logs sonarr".

As I can see, the debug log excerpt does not showing sanitizng infos. So: Do you have "Backup external volumes" enabled? This would backup TV Shows etc as well.

Oops. Thank for reporting both issues, I check this asap! Could you please share your complete debug log together with your config (/boot/config/plugins/appdata.backup/config.json)?

Looking good. Nothing obvious inside a diff. Maybe this is one for the docker section. Im out

That is really weird! 😮 Container logs. Weird. docker inspect sonarr (or sonarr2). That gives some unraid labels in between back, but nothing special: "net.unraid.docker.icon": "https://guacamole.apache.org/images/guacamole-logo-64.png", "net.unraid.docker.managed": "dockerman" I dont get, what is causing your container to stop. Something within the Unraid logging window at the time? Or maybe something inside /var/log/docker.log? Hmm. Should not caused that error. The Container AutoUpdate is not needed anymore with the new appdata.backup btw. There is an auto update feature built in. Thats weird, too. Somehing inside Unraid logging windows and/or /var/log/docker.log at this time? Could you post the results of "docker ps -a"? and maybe "docker image inspect *your Jd image name*". Replace the image name with the exact image name with tag! You can first list all valid image ids with "docker image ls -a".

Is any AutoUpdate plugin installed? i saw this type of error once but I got bo idea what is causing it to fail with this image deletion error.. hmm Nice idea. It should not but currently it does (within appdata.backup as well). Maybe a container start after backup could be considered „nice to have but not a blocker“.

Hmm. cant tell. I dont think it has a bug. In any case, I ask you to try it within the new appdata.backup plugin as soon as Unraid 6.12 is done. If the issue persists, Ill check it.

https://forums.unraid.net/topic/137710-plugin-appdatabackup/ Stable is newer. Betas will be released if needed only.

Hmm. If its coming from the MyServers plugin, it must be a bug then. Interesting. How is your exclusion list configured? I seen some such things recently. Thr thing is: The backup plugin tells docker "Hey, could you please start (or stop) this container?". This mechanism is the SAME as you would click stop/start inside the docker overview page. The "Server Error" is an direct response from docker daemon. It turns out, that in some cases: the container was already running (seperate AutoUpdate plugin was in use and updated containers while they were being backed up) Some leftover process was running in the name of the container. The last one is being diagnosed automatically with the new Appdata.Backup plugin for Unraid 6.12+ - but only for file verification errors. (Maybe it should do diagnosis after failed starts as well - I put a note on that) Not able to unmount your appdata (with all containers stopped) would speak for it as well (files in use). There is not much which would cause a name blocking issue. Unraid stores all docker related infos directly inside the docker container meta infos (using labels). So, if you remove a container, there is nothing left from it (maybe the image but thats ok). What does a "docker ps -a" say? What does the container logs say? Maybe some leftovers here as well. Do you have the seperate AutoUpdate plugin installed as well? I will thinking about that. But IF this feature will come alive, only for the new Appdata.backup plugin.

There is. Just configure it inside the container options.

@keywalPlease update, the issue should be gone.

Do you have any docker containers in your setup yet? Unfortunately, those arent valid backups anymore for this plugin version.