KluthR

Oops. Looking o to that soon. Maybe. Iam on 2.10 now. But we developer have other builds. I thought those were the same now.

Ooops. Thats interesting. If you see the issue again: Please open Tools -> PHP Options, set "Error reporting level" to "All categories" and check the "Show errors on screen" checkbox. Hit apply and open the page again. Im more than excited to see what the output will be... (After you reboot the next time, those PHP settings will be reset). You also not on latest RC, but that should not be the issue here.

The Grafana Unraid Stack template has the same issue. I dont know if its wrong practice to do such mappings, but it feels bad. It works, though. Maybe the plugin should detect those and writes a warning.

Your icloudpd container is the issue: It has the following volume mappings: ( [0] => /mnt/user/appdata/icloudpd:/config:rw [1] => /mnt/user/iCloud_Daniel:/home/user/iCloud:rw,slave [2] => /mnt/user/appdata/icloudpd/root:/root:rw ) You can see, that /root is inside the mapping for /config. So your unraid path for config is /mnt/user/appdata/icloudpd and your /root path points to /mnt/user/appdata/icloudpd/root. This causes a verification error during backup (at tars side). While it is working, it would make more sense to seperate those mapping into /mnt/user/appdata/icloudpd/root and /mnt/user/appdata/icloudpd/config. This is the 2nd time I see such issue. Maybe the plugin should remove mappings within another mapping automagically. The final backup contents would be the same - but without verification errors.

Please attach the debug log.

Does any of your containers have access to the folder where the file is located at? I dont know if Unraid created it (seems so) or some container (via volume mapping)

No idea were the file comes from. Could you share its content? Open it with Notepad++ or Wordpad. Either the java text was directly inside it or its a url with a pointer to a website. the filename is a script path to an unraid helper tool. I believe something placed it here. But what? however: removing it should fix the issue.

Could you share a directory listing of your configured source directory?

ToDo / Roadmap => GitHub <= backup without packing files into an archive https://forums.unraid.net/topic/132721-plugin-ca-appdata-backup-restore-v25/page/18/#comment-1251220 https://forums.unraid.net/topic/137710-plugin-appdatabackup/?do=findComment&comment=1365025 https://forums.unraid.net/topic/137710-plugin-appdatabackup/?do=findComment&comment=1365996 Option to disable container handling and just doing Flash, vm backup etc. Per container scripts https://forums.unraid.net/topic/137710-plugin-appdatabackup/?do=findComment&comment=1355362 named volumes support with this, I clean up ANY wording and make a clear difference between bind mounts and (named) volumes. private note: named volumes backup via helper container, NOT directly via /var/lib/docker/volumes! Not needed. The restore assistant needs some more ❤️ Doing verification (and even compression?) outside docker downtime (after docker services back running)?

Known issues Sometimes, users backing up Plex, are seeing backup issues for some "Application Support subfolders"

Appdata.Backup Support Thread This is the support thread for appdata.backup (formerly known as ca.backup2). This plugin primary takes care of your appdata backup! It allows you to configure backup settings for each of your docker containers. Flash and VM meta backup is integrated as well! If you encounter any issues, post it here with the debug log file attached! For your beta feedback, please post here instead! Why do I need to reinstall the plugin (again)? After my adoption of the ca.backup2 plugin (which needed a manual reinstall from every user the 1st time), I decided to make a complete overhaul of the whole plugin. The main reason was the PHP8 incompatibility. This new plugin is the result. Because it is actually a seperate new plugin, you have to switch to it manually again. This will be the last time Hints The plugin send me here to check for some Plex exclusions. Yes, thats right. You dont need to save Plex cache (and some other) directories. But its up to you to exclude them or not. Currently you are advised to set the following exclusions for plex: Each following paths need to be prefixed with your correct appdata path! Library/Application Support/Plex Media Server/Cache Library/Application Support/Plex Media Server/Media Library/Application Support/Plex Media Server/Metadata The plugin sent me here for help with the grouping function The grouping function allows you to group cotainers. The backup process stops all those containers, backup them and starts them back up before going to the next single container. This works for the mode "Stop, backup, start for each container" only. If the plugin reaches a group, it stops all containers in it, backup them and start them back up. The backup method "Stop all, backup, start all" has no effect here because every single container will be stopped nefore starting backup. The plugin sent me here to get help for the "Mapping used in multiple containers!" message The plugin can detect if you use the same mapping within more containers. That is completely okay but you should know that this can lead to "verification failed: contents differ" messages if you use stop/backup/start method and another container modifies the data during backup of the container that uses that share. The best way to get rid of that message is to add that share to the exclusion in all but the main container. One could also change the backup type but it does not prevent backing that share up multiple times!

Depends. I publish the plugin as stable the next days, but only starting with 6.12. so it depends when Unraid 6.12 is finally published.

Hi Maybe Frigate has a verbose log option? I dont think so. V3 gives a start order setting but the current version not. Well, it started correct actually. The docker daemon sends ok response. A „crash“ or error after start is not detected as error. I would test frigates log option first.

Sorry, no further updates for this. 6.12 is not far away (at least I think so). No issues known for the new plugin. If you still encounter issues then, post again.

As stated in the first post: you can test the beta if you want. Otherwise: All signs point to a first stable release before Unraid 6.12 gets a stable release.

See the pinned post and the 2nd one

Hmm, okay. But I dont see why it was not working. The plugin can work with spaces in its destination path. I will check this.

New plugin version status update Tests are going well so far. No blocking issues were reported for now. My plan is to release a first stable, if no issue were reported this week. The "v2.5" plugin is able to survive the Unraid update to 6.12 stable (as soon as its published) and will prompt you to install the new plugin. But it will NOT auto-backup anything in that case! The new plugin will give you the opportunity to migrate your settings from the "old" plugin.

Oh, sorry - it should be df -h (h for human readable sizes) but it shares enough information. TBH I dont see any issue. Whats a bit interesting: tmpfs 1024 1024 0 100% /mnt/remotes But it could be normal. Your backup share seems ok: //BACKUP/UnRaid OS Backup 37043960800 20978234480 16065726320 57% /mnt/remotes/BACKUP_UnRaid OS Backup Could you mount this same target again with a dofferent name with no spaces in it? it should make no difference, but better safe than sorry.

I tested it. I see, that the default template has this mapping: I created the container and moved the folders as said - it was working for me. In my understanding, the template should be adapted - but correct me if Iam wrong. Long story short: I could catch this case, but I assume its not an issue which pops up often.

Its fixed, please update to latest version.

Hm, found nothing interesting in the code which could prevent that. could you execute a df -a and share the result?

Please show /mnt/remotes in the file system or the listing at final destination: there must be a partial tar file in case of failure. Is it somewhere?

Since this is not blocking anything, I wont fix this. Should be working with the new plugin within Unraid 6.12

What is the container showing in the logs in that case? Because the new backup (Appdata.backup) is a completely new plugin which will replace ca.backup2. See: The old plugin does not had any clue, which volume belongs to which container. It just stops all and backs up the data inside your given path. The new plugin backs up in a per container config. This includes a detection of needed container volumes. Assigning a volumes subfolder as extra volume seems not a good practice to me (correct me if Iam wrong), but I dont see, why my steps should not work.