KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 Thats intereisting, yes. Because the test for a running script is absolutely failsafe. It seems, that something remains running. The started pids are stored within /tmp/appdata.backup.beta/running and extCmd files. I tested it a few hours ago and it brought the desired result. I will test it again, thanks for the input! I also working on a bsaic migration from the old plugin config. Quote Link to comment
xaositek Posted March 29, 2023 Share Posted March 29, 2023 1 minute ago, KluthR said: Thats intereisting, yes. Because the test for a running script is absolutely failsafe. It seems, that something remains running. The started pids are stored within /tmp/appdata.backup.beta/running and extCmd files. I tested it a few hours ago and it brought the desired result. I will test it again, thanks for the input! I also working on a bsaic migration from the old plugin config. It took about 3-5 minutes for it to recognize the backup had stopped. I did edit my post but it fixed itself. Great update to this app also! Quote Link to comment
craven_moorehead Posted March 29, 2023 Share Posted March 29, 2023 What is that little square with the arrow on the configured volumes? is that where I should be able to choose if I want to include the configured volumes or not? Ideally that would be a check box. But whatever it is, it doesn't do anything. Quote Link to comment
KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 The square icon is part of a hidden setting. Volumes with those icon are „external“ volumes which can be optionally included soon. Quote Link to comment
KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 33 minutes ago, xaositek said: did edit my post but it fixed itself. But something must happened, because the end-message instantly should turn the status to „stopped“. I will see. @craven_moorehead I see that your container options are set to „Yes/No“ instead of defaults. Was that intended or a leftover from the previous bug? Quote Link to comment
craven_moorehead Posted March 29, 2023 Share Posted March 29, 2023 So if someone is using /mnt/cache instead of /mnt/user for example on mariaDB for performance reasons it does not consider that an "internal" volume it appears. Even if that's the path to the appdata. Quote Link to comment
Govnah Posted March 29, 2023 Share Posted March 29, 2023 An error occurred during backup. RETENTION WILL NOT BE CHECKED! Please review the log. ab.debug.log Quote Link to comment
KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 (edited) 2 hours ago, craven_moorehead said: So if someone is using /mnt/cache instead of /mnt/user for example Yes. In default config, the path other than /mmt/appdata is seen as „external“. The primary path is examined from the Docker settings page. If that is set to /mnt/bla, then this is the path I work with. combining two appdata sources was not able within the previous plugin either. If such a feature is really wanted, we find a solution EDIT: NOW I understood your concerns: In the unraid world, /mnt/user/appdata and /mnt/cache/appdata would be the same at the end of the day. So if all containers are mapped to /mnt/user/appdata and only your mariadb is linked to /mnt/cache/appdata, it would treat it as external path. Yea, thats strange. Will think about it. Edited March 29, 2023 by KluthR Quote Link to comment
KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 15 minutes ago, Govnah said: An error occurred during backup roonserver/data/RoonServer/Database/Core/e129e95b6f294aa3b3640f06446ede68/broker_4.db/777531.ldb: Contents differ; seems like the old bug: docker container is stopped but something is accessing its files. The detailed debug does not show much, I need to add more environmental info. The next update will include such, then we will try again. Quote Link to comment
KluthR Posted March 29, 2023 Author Share Posted March 29, 2023 3 hours ago, KluthR said: Yea, thats strange. Will think about it. @craven_mooreheadI got you I changed the complete internal/external volume handling! Per default, /mnt/user/appdata and the cache equivalent are allowed to say "its internal" + the configured Appdata path inside the docker settings. Everything else is handled as "extra". Thats done by the cost of tar's -C option. Thats means, that I use absolute paths for the tar creation. I thought a bit about it and I would say, thats no issue. If you recover from those backup, the EXACT SAME paths are being created then. That would also match the containers Volume mapping. If someone wishes to make changes, one must change it after restore or restore by hand. I finalize and test this first "big" change and let you test Quote Link to comment
KluthR Posted March 30, 2023 Author Share Posted March 30, 2023 Please try the new version ( @craven_moorehead ) . Quote Link to comment
craven_moorehead Posted March 30, 2023 Share Posted March 30, 2023 3 hours ago, KluthR said: Please try the new version ( @craven_moorehead ) . You mentioned that it will pull the name from the container's app data path. Is there any chance that it's not considering volumes if they don't have the default name of "cache" because it appears to still be considering these as "external volumes". Or probably because in the container this is not called 'app data' path its just called 'data'. none of this would matter if it would just pull a list of all configured volumes and just have a check box beside each one for manual selection. Quote Link to comment
KluthR Posted March 30, 2023 Author Share Posted March 30, 2023 (edited) No, the plugin has a list of known appdata paths + the one configured in your docker setting: I believe none of this is applicable? One could have multiple such volumes to store data which should be considered "internal" (sorry if the naming is a but ugly, dont had better idea). What was your source config in the previous plugin? Whats about configurable appdata source(s) which should consider always-to-backup data? Edited March 30, 2023 by KluthR Quote Link to comment
craven_moorehead Posted March 30, 2023 Share Posted March 30, 2023 OK, this kind of works. If I change my "default appdata storage location" to my cache location /mnt/vmachine_cache/ as shown above in my screen shot from previous post, then it will resolve the issue where for mariaDB it considers those to now be 'internal' volumes. For me this is ok (because cache is basically my default appdata location), but for other people their "default appdata storage location" might be /mnt/user and they only changed it manually for mariaDB (or similar) database performance. In that case their situation would be what I've shown in the screen shot in previous post, that is their 'default appdata storage location' = /mnt/data but in their mariaDB (or similar) container they are pointing manually to /mnt/any_name_cache/ and based on my experience that would be considered 'external volume' Quote Link to comment
KluthR Posted March 30, 2023 Author Share Posted March 30, 2023 Ok. A new options for allowed appdata paths would fix it. I dont would add a checkbox next to each volume, I believe thats no good practice. I will see. Quote Link to comment
craven_moorehead Posted March 30, 2023 Share Posted March 30, 2023 On 3/29/2023 at 9:58 AM, KluthR said: roonserver/data/RoonServer/Database/Core/e129e95b6f294aa3b3640f06446ede68/broker_4.db/777531.ldb: Contents differ; seems like the old bug: docker container is stopped but something is accessing its files. The detailed debug does not show much, I need to add more environmental info. The next update will include such, then we will try again. I also had this error in prior releases but appears to be resolved now. Quote Link to comment
KluthR Posted March 30, 2023 Author Share Posted March 30, 2023 59 minutes ago, craven_moorehead said: I also had this error in prior releases but appears to be resolved now. No, thats nothing I can deal with. So if it does not happens currently is pure luck. latest revision has detailed debug info for that case, so share if it happens again. Quote Link to comment
KluthR Posted March 31, 2023 Author Share Posted March 31, 2023 On 3/30/2023 at 5:09 PM, craven_moorehead said: In that case their situation would be what I've shown in the screen shot in previous post, that is their 'default appdata storage location' = /mnt/data but in their mariaDB (or similar) container they are pointing manually to /mnt/any_name_cache/ and based on my experience that would be considered 'external volume' How about: ? Quote Link to comment
craven_moorehead Posted April 1, 2023 Share Posted April 1, 2023 I tested this and it works 1 Quote Link to comment
KluthR Posted April 1, 2023 Author Share Posted April 1, 2023 Did anyone found another issue? Did anyone tested migration? Quote Link to comment
Roddi Posted April 2, 2023 Share Posted April 2, 2023 (edited) Problem not directly, but can it be that the backup now takes longer? That's the first question, the second would be can it be that the backup program has problems with directories. I use Grafana Unraid Stack as a Container and it gives me Problems and I always get an error message that the tar verification fails. P.S. Since my English is grottig the text is created with DeepL...Sorry🙁 ab.debug.log Edited April 2, 2023 by Roddi Quote Link to comment
KluthR Posted April 2, 2023 Author Share Posted April 2, 2023 I noticed, that your grafana volume mapping is: [6] => /mnt/user/appdata/Grafana-Unraid-Stack:/config:rw [7] => /mnt/user/appdata/Grafana-Unraid-Stack/data:/data:rw it seems, that tar has a verification issue with that. While it seems to work, i would rather change the mapping for /config to an own folder. the backup should not take longer but you can test it if you are able to. Quote Link to comment
Roddi Posted April 2, 2023 Share Posted April 2, 2023 I have tried this, but unfortunately Grafana does not work anymore. No login works and no databases are found. Since I am not an expert, I ask the question if there is another way to work around the error? If not, I have to live with it and always rename the backup. Quote Link to comment
KluthR Posted April 2, 2023 Author Share Posted April 2, 2023 (edited) 48 minutes ago, Roddi said: I have tried this, but unfortunately Grafana does not work anymore How did you tried to change it? I dont know if this container requires this strcuture, but I would: create a folder within "/mnt/user/appdata/Grafana-Unraid-Stack" called "config". Then move evyrthing except data to the new config folder. So you end up having: /mnt/user/appdata/Grafana-Unraid-Stack/config:/config/ /mnt/user/appdata/Grafana-Unraid-Stack/data:/data EDIT: You updatedt your debug log file. I see, that you configured each volume as own allowed sources. That not needed, unless you exactly want this. Just put in /mnt/user/appdata. Thats all. It will make no difference though. Edited April 2, 2023 by KluthR 1 Quote Link to comment
MyKroFt Posted April 2, 2023 Share Posted April 2, 2023 Is there a way to see verbose during backup in the running window? Quote Link to comment
Recommended Posts
Posted by KluthR,
0 reactions
Go to this post
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.