KluthR

Yes

Just extend the path when filled in the textbox. You can use * as an wildcard afaik.

Seems so. if you want to ignore that, set the appropriate setting.

Thought exactly the same as I read the posts. Noted!

Thats one reason. The other is that the plugin has absolutely no clue which appdata folder belongs to what container (even if the naming is the same). Thats one thing I want to change in upcoming versions. A bit busy but Iam not in hurry

There is. But Iam currently busy with a refactoring. I dont touch the „old“ code except for urgent changes. Please wait a bit until Iam ready. What do you want to change?

No, there are no bugs. Encountered „errors“ were most probably suppressed in v2 only. Please read the second post.

Definitively not from the plugin itself Is auto Update for containers enabled inside the appdata plugin? I guess AutoUpdating went wrong (image could not be downloaded correctly). To get NC back, just hit „Add Container“ and select the EXACT name of your nextcloud container name from the Templates dropdown. After selecting your network and paths settings should be back. Unraid saves every created container inside a user template.

Yes. As Iam doing some refactoring, this will be fixed later as well. Yes, already discussed. Needs dependency support (my guac would exit if guacamole would exit - or the other way round?). I already thought, that users might think that the new option includes verification - but no: it dont! Those two options are two processes! If the main backup succeeded without error, the verify could still fail. Verification will be skipped if main backup fails.

I'll add an option to let the user completely ignore any errors for now - later this day. In the upcoming options, users have more options for that. Backups while containers are running are no valid backups for me. It would be possible (next versions) to only include a pattern to the backup. Use case would be: If a container creates backups itself, AppData Backup could only pick those up while not stopping this container. Backup and verification would be successful because those files are static at that moment. We will see. @All Plex users: Please share your Plex exclusion list to create a list of useful exclusions for the next big upfates

It adds a bit more safety as it check backup integrity. Yes, some Cache folders or thumbnails. Could any Plex user post their exclusion list? Maybe I add a hint to one click add „useless“ Plex folders to the exclusion list

Neither nor. It just split the backup up by source folders. Its not faster and not slower. Logically it stops them each time the backup starts.

No. That way its the same. The tar command is exactly the same. There is no reason for longer backup times.

@MrTyton Do you have enabled separate archives?

The mechanism wasnt changed. Are you sure your exclusion list etc is set correctly?

+1 😅 It just shows up surpressed errors in first line. Thats the main reason for users thinking „since update I get errors, zhere must be something wrong with the plugin“. It was not clear to determine jow mamy would be affected when I fixed this. It is already. Yep. Because your USB flash backup destination points to your appdata. This usb flash backup uses rsync. Rsync is being told to make a 1:1 copy and therefore deletes any additional file which was not at the source. This mechanism is about to change in the future! I hope to make further progress soon to catch everything

Please open the system log window and execute the backup again. The used commands will be posted there. Please copy one and paste it here. You also can copy and paste it for manual execution.

Is a manual backup (Hit the button at the settings) working?

Interesting. I took a look in the code - destination creation errors are also currently being ignored. But I dont know if that is the issue Could you execute: touch /mnt/remotes/192.168.20.25_Net-Backup/UNRAID/JSW-UNRAID-NUC/AppData/test and see if the file test is being created then?

Exclude the image file Thats planned - a per container config. But for this, we need also dependency chaining for container which need each other. Depends. I see some "differ" warnings - something is running and accessing those files during backup. Another interesting story - The method to start the containers is the exact same method Unraid uses. Something is happening during backup. The message is weird as well - could you post the full log from the Logging/Status tab? Anything which could access it during backup? Indeed - how should that work in a clean way otherwise? Thats the case, yes. I could create a setting to ignore those - but thats not a good way then. Ignoring all errors leads to inconsistent backups. That would be a per container setting "Ignore backup errors" then. For the future Any other container - not stopped - maybe accessing this Pley Cache folders? Sidenote: Some users seems to have Plex stopped but sometimes errors on those Library/Cache/Meta files - but I dont know why

Thats for sure, as said in the initial post already. If you want to remove a functionality, it would be good to know if its still maybe used a lot in the field. But I think, leaving the user the FULL control about it (via opt-in and with explanations) is sufficient.

Seems that something was modifying this file during backup. I dont know why it would shrink otherwise.

Yes but those are the half truth only. I know, this is on the list as well. as you can see, the verify process putputs more errors here: [29.12.2022 14:39:30] Verifying Backup ./adguard_home/workingdir/data/querylog.json: Mod time differs ./adguard_home/workingdir/data/querylog.json: Size differs so it seems, that adguard is not stopped or something is accessing it during backup. Ahh, as I write I realize: your adguard is set to „not stop“ thats the reason. So, either you exclude adguard from the backup files or you wait for the verification skipping feature. Per container settings are coming as well later.

That is one solution but why is your docker.img at /mnt/cache/appdata ? Did you changed the default docker.img location?

Docker.img does not need being backed up. Open CA Appdata backup settings and open the 3rd tab.