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.

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!

 

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. 

The square icon is part of a hidden setting. Volumes with those icon are „external“ volumes which can be optionally included soon.

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?

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.

An error occurred during backup. RETENTION WILL NOT BE CHECKED! Please review the log.

 

 

ab.debug.log

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, 20233 yr by KluthR

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.

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

Please try the new version ( @craven_moorehead ) .

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. 

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, 20233 yr by KluthR

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' 

 

 

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.

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. 

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.

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:

 

?

I tested this and it works

Did anyone found another issue?

Did anyone tested migration?

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, 20233 yr by Roddi

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.

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.

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, 20233 yr by KluthR

Is there a way to see verbose during backup in the running window?