KluthR

Bekenne mich schuldig 😂 Programmiererlaune wenns gut läuft 😂 In Zukunft wird das Plugin noch eingedeutscht btw Multisprache fähig gemacht (am Rande).

All. Otherwise you cant guarantee a consistent and working backup. Imagine backing up a running opened database. This can work but isnt optimal. Therefore we stop, backup, start.

Observiums files changed because you set it to „Dont stop“. That causes an error for backup verification. Best option is to wait until Unraid 6.12 is stable. Update to 6.12 and install „Appdata Backup“. Ca.backup2 will be EOL with Unraid 6.11.5. see first post.

No. ca.backup up to 6.11.5 its successor „appdata.backup“ starting with 6.12 see 1st post.

It is! Noted.

It could be, yes. I think the Abort function was broken after I implemented separate archive function. TBH: I dont want to take any more time for the old plugin. It is definitively working with the new one. this behavior occurs sometimes. Due to lack of diagnosis inside the old plugin, I please you to try the new plugin with unraid 6.12+

It seems, that the container is still running. Then we talk about appdata.backup which has an own thread. See 1st post.

I believe you are refering to ca.backup2? because your requested feature is availble inside the new appdata.backup.

Every issue is fixed with the rewritten plugin appdata.backup for Unraid 6.12+ =>

@schreibman: Regarding Not a real bug here - I dont thought, that there will be the same mapping twice - at least for host point of view. Is a nice to have to deduplicate detected volumes - noting. But how does your plex was working before? You just changed the mapping paths as I see, or do you reorganized the files as well? All files were in the same place at first.

This is not ca.backup2. You are showing logs from appdata.backup (https://forums.unraid.net/topic/137710-plugin-appdatabackup/). Please find my answer there.

@tlrmcknzSorry, I was confused. So - you have ca.backup2 setup and set the exclusion to "/mnt/user/appdata/data", but the backup does NOT contain "/mnt/user/appdata/ms-sql-server/data", right? Looking at the code: You should have entries like "Ignoring *foldername*". The code uses the latest portion of your exclusion ("data" in that case) and ignores folders inside SOURCE folder option with that name. Subfolders are not scanned. So, i dont see the issue yet. Please upload a complete backup log. EDIT: Please share your source folder value as well.

What is the question?

Because it was not checked correctly. That was a big which is being fixed. There is no problem. Without stopping, no consistent backup. So the real issue existed with the old behavior

IMO thats worth a warning. They are not exact matches, so this is working as expected. I dont resolve any path matching syntax. Thats tars task. Only if a mapping is exact listed 1:1 inside exclusion, I dont event take it to tar. So, I assume all current issues are now fixed. @MothyTimYour nc should be backing up now as well.

Lets go Could you update as well and upload a new debug log? I saw an issue inside your log and want to confirm its fixed.

Warnings are just warnings, no issue here. But I can change that to info. I need some more time to adjust the beta again, there is another issue.

As far as I can see, this is a permanent note saying, you should use an extra folder for the backup destnation. SOrry, not possible with the old ca.backup2

Thanks for the report, checking that. I bet if you reboot, it will stop working again.

Ahh, I see. There is a detail missing. The nested mapping detection ignores allowed sources. I think, it should check that. Ill prepare another update, would be great, if you test this again

I need some clarification… do we talk about ca.backup2? If yes, your exclusion works as expected. if not, then we talk about appdata.backup. Post in the right thread with the debug log attached, please

This is because of a bug which is fixed within latest BETA version (volume mapping nesting). You are also mapped the whole appdata - this is being ignored as well within next update They are working - but not, if you exclude a whole volume. Only subcontents of it. This seems to be a limitation from tars verify command. The next update remove volumes/exclusion pairs. Should be self solving as well then. Warnings are no errors. Just warnings. They tell you, there might be an issue. Some functions change the behavior if some conditions are met. Those produce warnings to let you know. That being said: There is a new beta version with all current issues fixed. Before public relleasing, I want you (all quoted ones, and @MothyTim - did I forgot someone?) to test it. Note: This require to configure the beta version from scratch (or your simply copy over the confoig.json from appdata.backup to appdata.backup.beta - yes, automating that would be nice, noted)

For what reason? To exclude it? If yes, the exclusion filter will adapt a more things in the next update.

Since Plex was already down, someone/something has done it before.

Exactly what it states: Something is accessing mentioned paths during backup/verification though plex is stopped. any 3rd party script/plugin which is working with Plex‘ container? It also was stopped 3 mins before the backup.