[Plugin][BETA] Appdata.Backup


Recommended Posts

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.

Link to comment
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!

Link to comment
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?

Link to comment
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 by KluthR
Link to comment
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.

Link to comment
3 hours ago, KluthR said:

Yea, thats strange. Will think about it.

@craven_mooreheadI got you :)

grafik.png.2e6712559bd17d3ad3eeedc0b13827c5.png

 

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 :)

Link to comment
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. 

maria.thumb.png.377a5dc0b2f085ac472a061f0378ca8f.png

Link to comment

No, the plugin has a list of known appdata paths + the one configured in your docker setting:

grafik.png.412c9dd41aa9d4c81f94b4c75c6a6d77.png

 

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 by KluthR
Link to comment

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' 

 

 

Link to comment
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. 

Link to comment
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.

Link to comment
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:

 

grafik.thumb.png.f7b4757c06d070b61106c45d89df48fe.png

?

Link to comment

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 by Roddi
Link to comment

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.

Link to comment

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.

Link to comment
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 by KluthR
  • Like 1
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.