KluthR

New observings: Its not happening with bridge network interface. See https://forums.docker.com/t/occasional-ping-issues-over-ipv6/140296/2?u=rkluth @ich777 You also have IPv6 experiences with Unraids docker. Did you ever came accros such issue?

The order is effective for both modes as the container lost gets „sorted“ once when starting the backup.

But the log above that field is visible? No recent reboot or anything?

now.

Yea. Just checked. The plugins chmod runs after post-run. Will change that in next release

Check settings. Whats inside allowed appdata source paths? Is the volume in question maybe "external" and therefore excluded? Some of your containers excluding /mnt which leads to empty zips..? Point to the backup and restore all XMLs and appdatas. Use Previous apps to install all containers. Currently you need some manual work. Another check here: I bet this container is inside of a group?

Could you please upload a debug log and share its ID?

Oops. Yes, not CA related Could someone move it for me?

Interesting. Is there something special about /mnt/user/unraid_backup ? Whats happening if you run "mkdir /mnt/user/unraid_backup/appdata_backup/test"?

Feels more and more like a general v6 docker issue. docker and IPv6 are not the best friends. There are several issues regrading v6.

Hey I migrated from an exclusive cmk appliance to the docker version to get rid of one physical system. However, I experience permanent occasional v6 smart piung issues with the container. I can observe this with ping6 from inside the cmk container. Every few minutes I get 100% packet loss, then back to normal etc. Unraid 6.12.8 Anyone with similar issues? The container is set up this way: docker run -d --name='checkmkk_empty' --net='eth0' --ip='192.168.178.29' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="NAS" -e HOST_CONTAINERNAME="checkmkk_empty" -e 'CMK_SITE_ID'='l22' -l net.unraid.docker.managed=dockerman -v '/mnt/ssd/appdata/checkmk_empty/sites':'/omd/sites':'rw' -v '/etc/localtime':'/etc/localtime':'ro' -v '/mnt/ssd/appdata/checkmk/backup':'/backup':'rw' --mac-address 02:00:00:00:00:29 --tmpfs /opt/omd/sites/l22/tmp:uid=1000,gid=1000 'checkmk/check-mk-cloud:2.2.0p23' Some ping pictures which show the v6 issue only within cmk container. HA container does not show such issues..? HA is set up the same way. docker is using macvtap bridge. Thanks in advance!

= should be == right?

I try to release an update within the next day.

There is none. The restore tab should be self explanatory.

Did anyone tested the fix

Yes. U can try the hotfix if wanted.

Not an issue as well because there were no changes. The main purpose of this plugin is docker backup. Using it just for Flash backup is actually working but not intended. I will see what I can do. You added "/mnt/user" in many containers to exclude. Since I work with tar's exclusions syntax, Iam not always able to 100% check things for logical correctness. However, you should fix the exclusions to NOT exclude whole "/mnt/user" and want the backup to include "/mnt/user/appdata/*" things.

It should print a red, ylear error then: But yes, it could create the dir. Noted. Damn. My fault. The global exclusion list gets ignored during container mapping determination. It will be checked in the next update. But note: The global exclusion list also supports tar's exclusion syntax, but only exact path matches are supported!

There is a new thread for the new plugin. Follow plugins footer link to get there. However: I would need a debug log, please share and tell me its ID.

I fully understood now, what the issue was. I must be blind However: The fix includes supports now to respect excludes as well as skipping external volumes (if the per-container setting does not wish to backup those). The two new ideas are featured by noirsoldats. For anyone who wants to test the fix on their affected setup: I created a small script that patches the file in question. Its a one-liner and it will do the job for you. Running twice will undo the fix! Open a terminal and paste the WHOLE LINE: curl -s https://raw.githubusercontent.com/Commifreak/unraid-appdata.backup/volume_dup_check_fix/vol_dup_fix.sh | bash Please reload the settings page and check if the warnings are now gone or - if shown - correct!

Though its a bug, it seems like @BartyB sees a part of working warning. The data dir IS used in more than one container, so excluding it should do the trick. @schreibmanIn this case I dont need Unraids diagnostics. It would be great if you could PM me, I need the output of your browsers developer console (F12).

named volumes are in progress to be supported. Needs some more time. But it should be possible to exclude those volumes by writing the exact name inside the exclude box (inside container specific settings).

Which is not a consistent backup, in my eyes. If Snapshots would be supported I would AT LEAST stop all containers, create snap, start container, doing file backup on just created snap.

Are you referring to an flag inside zstd?

Known an I (we) are on it. Currently collecting debug info from affected users as I cant reproduce it on my end. Uh Oh. Doesnt look right at all! I guess something is crashing silently. If the red heart is definitively the last line in that log, er are having an issue here. If you have some time, please PM me, I also need some testst at your side for me to understand this. No. Currently the best way is to create a helper .sh file