The restore just restored the volume(s) and the template(s), if any. I wanted to add a docker container restore in a future version. 

I have been trying to update to this plugin from the previous but can't seem to get it installed.  When I attempt to install it I see the following error:

 

plugin: installing: appdata.backup.plg
Executing hook script: pre_plugin_checks
plugin: downloading: appdata.backup.plg ... done

Executing hook script: pre_plugin_checks
No cleanup of old plugin archive needed!
Removing plugin files...
plugin: downloading: appdata.backup-2023.09.12.tgz ... done

Extracting plugin files...
Checking cron.
plugin: run failed: '/bin/bash' returned 255
Executing hook script: gui_search_post_hook.sh
Executing hook script: post_plugin_checks

 

I've tried rebooting Unraid as well but always end up seeing the run failed '/bin/bash' error when attempting to install it.  Any thoughts?

 

Please retest with new version uploaded just now. Any occurring error should now show up.

Still seeing the same I think

 

plugin: installing: appdata.backup.plg
Executing hook script: pre_plugin_checks
plugin: downloading: appdata.backup.plg ... done

Executing hook script: pre_plugin_checks
No cleanup of old plugin archive needed!
Removing plugin files...
Creating plugin files directory...
Extracting plugin files...
Checking cron.
plugin: run failed: '/bin/bash' returned 255
Executing hook script: gui_search_post_hook.sh
Executing hook script: post_plugin_checks

On 6.12.4? What other plugins are installed? Maybe add a diagnostic file.

6.12.3, I've been working through a few things before updating to 6.12.4.  Here are the plugins that I have installed, as well as diagnostics.

 

 

 

tower-diagnostics-20230928-2049.zip

I find no entries within the logs regarding plugin installation. At which time did you tried the setup?

Anyone else having problems with the "excluded folders" being ignored on the latest version?  Sometime in Sept my backup size increased dramatically, looked at the .tar.gz files and my Photoprism cache folder is now being backed up even though I have it excluded.

 

Does this make sense for excluded folders for Plex?
 

3 hours ago, decadent-thickness2345 said:

Anyone else having problems with the "excluded folders" being ignored on the latest version?  Sometime in Sept my backup size increased dramatically, looked at the .tar.gz files and my Photoprism cache folder is now being backed up even though I have it excluded.

 

Try using /mnt/cache/appdata instead of /mnt/user.

1 hour ago, daithi said:

Does this make sense for excluded folders for Plex?
 

You have to use absolute paths. But yes, then it would work

Edited September 29, 20232 yr by KluthR

15 minutes ago, KluthR said:

You have to use absolute paths. But yes, then it would work

 

Oh I should have '/mnt/cache/appdata/' in front of each line, that's a dumb mistake.

Does it include subfolders in that format? For example if I use the GUI to add the '/Plex Media Server/Media/' folder, then the Plugin adds two lines to that text field:
/mnt/cache/appdata/plex/Library/Application Support/Plex Media Server/Media/
/mnt/cache/appdata/plex/Library/Application Support/Plex Media Server/Media/localhost/

Are both lines needed or can I get rid of the second/localhost one?

The last one can be ommited. And yes, that includes all subfolders as well.

6 minutes ago, KluthR said:

The last one can be ommited. And yes, that includes all subfolders as well.

Thanks. Lots of housekeeping now that I'm finally brave enough to leave 6.11.5

16 hours ago, KluthR said:

I find no entries within the logs regarding plugin installation. At which time did you tried the setup?

 

I don't recall what time I attempted, but here is a fresh diagnostics.  I attempted to install it right before downloading these diagnostics at 6:03pm CST on 9/29.

tower-diagnostics-20230929-1804.zip

Thanks bit this time the syslog file is empty. The syslog.1 (previous one) last line is dated 28.9. weird.

 

please try this: open the log window and observe the output while install the plugin. Maybe you can copy and paste the section during install.

First of all, I would like to congratulate you for the good work on the current version.

 

However, I just needed to restore some data and I have verified that not all containers have been copied. I've doble verified the setup and it is ok. I'm using two appdata folder and both are correctly added and it internal data is copied good from both.

 

EDIT: Problem solved. It was a error on setup. Some of my internal folders were defined as /mnt/user/cache and some as /mnt/cache.

Edited October 5, 20232 yr by JAnguita

Hey last night the backup hung and none of the docker containers came back up still I started them manually which caused a flood of backup error messages. 
 

here is the debug log: 3de97d8e-0484-4e6a-854d-8b633caeae87

Hi!

I'm loving the plugin, it completely replaced my custom script. I'm only having a little issue about the notification settings, it doesn't seem to work?

 

I still receive a summary message:

 

Thank you!

Hello all. First of all, thank you for this excellent plugin. @Squid's version was already pretty good, but you've taken it to the next level, @KluthR! I have a couple of tiny problems and one medium-sized one, though. Let's get the small ones out of the way:

 

Firstly, could I please prevail upon you to not raise notifications about configuration warnings at runtime? Every week I get notifications generated telling me "NOT stopping [container] because it should be backed up WITHOUT stopping!". I know! I chose that setting! In defiance of the very clear advice on the UI that this isn't recommended, too. By all means note in the log that the backup isn't stopping the container, or even raise a warning dialog when saving the settings, but please don't raise a notification. It doesn't tell me anything, and is just noise. I'd turn off warnings, but sometimes there are warnings about things I don't already know about, and want to do something about. Talking of which...

 

Last night, for several containers I got three warning notifications in addition to the configuration one mentioned above. They weren't obvious in the log because they had the [ℹ️] that I presume denotes information, not the [⚠️] for warnings, making them hard to spot. They were of the format "[[timestamp]][ℹ️][[container]] Stopping [container]... Error while stopping container! Code: - trying 'docker stop' method". That brings me on to my medium-sized problem:

 

I got a warning for some, but not all, of my containers saying "Stopping [container]... Error while stopping container! Code: - trying 'docker stop' method". The next message notes that "That _seemed_ to work.". Indeed, if I SSH into Unraid and do "docker stop [container]", it does work. By what method does the plugin try to stop containers on its first attempt? Do you have any tips for how I can debug my containers to see why they don't stop on that first attempt?

On 9/30/2023 at 1:37 AM, KluthR said:

Thanks bit this time the syslog file is empty. The syslog.1 (previous one) last line is dated 28.9. weird.

 

please try this: open the log window and observe the output while install the plugin. Maybe you can copy and paste the section during install.

 

The log window shows the following when trying to install it.

 

Oct  2 17:43:19 Tower root: plugin: running: anonymous
Oct  2 17:43:19 Tower root: plugin: checking: /boot/config/plugins/appdata.backup/appdata.backup-2023.09.27.tgz - SHA256
Oct  2 17:43:19 Tower root: plugin: skipping: /boot/config/plugins/appdata.backup/appdata.backup-2023.09.27.tgz already exists
Oct  2 17:43:19 Tower root: plugin: running: anonymous
Oct  2 17:43:19 Tower root: plugin: running: anonymous

 

I also tried deleting that file and then reinstalling it and get the following.

Oct  2 17:44:20 Tower root: plugin: running: anonymous
Oct  2 17:44:20 Tower root: plugin: creating: /boot/config/plugins/appdata.backup/appdata.backup-2023.09.27.tgz - downloading from URL https://github.com/Commifreak/unraid-appdata.backup/releases/download/2023.09.27/appdata.backup-2023.09.27.tgz
Oct  2 17:44:20 Tower root: plugin: checking: /boot/config/plugins/appdata.backup/appdata.backup-2023.09.27.tgz - SHA256
Oct  2 17:44:20 Tower root: plugin: running: anonymous
Oct  2 17:44:20 Tower root: plugin: running: anonymous

 

With both instances I still see the same error (plugin: run failed: '/bin/bash' returned 255) in the install window. 

SOLVED - seems tdarr_node is linked to the same logs folder.

 

Hi,

 

I'm picking up an error when backing up tdarr - anyone have any idea of what could be causing the file to get modified while the docker is stopped? here are the logs

 

[03.10.2023 02:40:49][ℹ️][tdarr] Stopping tdarr... done! (took 4 seconds)
[03.10.2023 02:40:53][ℹ️][tdarr] Should NOT backup external volumes, sanitizing them...
[03.10.2023 02:40:53][ℹ️][tdarr] Calculated volumes to back up: /mnt/user/appdata/tdarr/logs, /mnt/user/appdata/tdarr/server, /mnt/user/appdata/tdarr/configs
[03.10.2023 02:40:53][ℹ️][tdarr] Backing up tdarr...
[03.10.2023 02:41:22][ℹ️][tdarr] Backup created without issues
[03.10.2023 02:41:22][ℹ️][tdarr] Verifying backup...
[03.10.2023 02:41:58][❌][tdarr] tar verification failed! Tar said: tar: Removing leading `/' from member names; mnt/user/appdata/tdarr/logs/Tdarr_Node_Log.txt: Mod time differs; mnt/user/appdata/tdarr/logs/Tdarr_Node_Log.txt: Size differs
[03.10.2023 02:42:15][ℹ️][tdarr] Starting tdarr... (try #1) done!

Edited October 3, 20232 yr by ultimz

@KluthR I just wanted to say thanks for your hard work on supporting the old plugin for so long and this awesome new one. Appreciate it!

On 10/1/2023 at 3:20 PM, robbiered said:

Hey last night the backup hung and none of the docker containers came back up still I started them manually which caused a flood of backup error messages.

Not true. the debug ID has not any error in it and successful backups.

 

On 10/2/2023 at 6:42 PM, bexem said:

I'm only having a little issue about the notification settings, it doesn't seem to work?

The final message is new and is triggered always, just for information, like a normal success-notification. If this really causes flood messages, I would bring in an option to disable it?

 

On 10/2/2023 at 7:33 PM, ScottAS2 said:

Firstly, could I please prevail upon you to not raise notifications about configuration warnings at runtime? Every week I get notifications generated telling me "NOT stopping [container] because it should be backed up WITHOUT stopping!". I know! I chose that setting!

I implemented that with the idea of "maybe the user is not aware of it, notice it inside the log as a warning". Maybe setting the notification level to errors only is better for your setup? Its really just a warning. Any critical would be reported as error.

On 10/2/2023 at 7:33 PM, ScottAS2 said:

By all means note in the log that the backup isn't stopping the container, or even raise a warning dialog when saving the settings, but please don't raise a notification. It doesn't tell me anything, and is just noise.

Hmm. Thinking about it, maybe its just worth an information then.

On 10/2/2023 at 7:33 PM, ScottAS2 said:

They weren't obvious in the log because they had the [ℹ️] that I presume denotes information, not the [⚠️] for warnings, making them hard to spot.

Thats right and needs to be fixed. Its because of the ".. done" suffix, if the result is ok. No need for 2 2nd line then. But in case of an error, there is a need for a second line. Noted.

On 10/2/2023 at 7:33 PM, ScottAS2 said:

I got a warning for some, but not all, of my containers saying "Stopping [container]... Error while stopping container! Code: - trying 'docker stop' method". The next message notes that "That _seemed_ to work.".

Thats a weird thing I never managed to understand completely:

On 10/2/2023 at 7:33 PM, ScottAS2 said:

By what method does the plugin try to stop containers on its first attempt?

The 100% Unraid way. And thus said, I dont get why it does not work sometimes. The Unraid way calls the Docker API. And docker itself returns a failure here. I catch this and try it via "docker stop xxx" which seems to work then. The docker API does not tell me whats the problem. I never faced the issue on my end, so no permanent issue which I could try to debug.

On 10/2/2023 at 7:33 PM, ScottAS2 said:

Do you have any tips for how I can debug my containers to see why they don't stop on that first attempt?

You could check the /var/log/docker.log for infos or check the Unraids log terminal if any messages appeared for those failures.

 

On 10/3/2023 at 12:48 AM, faulty_lamp said:

With both instances I still see the same error (plugin: run failed: '/bin/bash' returned 255) in the install window.

Those messages are ok. I still dont get whats causing the error. Never seen that before

 

On 10/3/2023 at 8:08 AM, ultimz said:

SOLVED - seems tdarr_node is linked to the same logs folder.

That was my fiurst idea as well. I need to let the plugin check for volumes used in multiple containers..

1 hour ago, KluthR said:

The final message is new and is triggered always, just for information, like a normal success-notification. If this really causes flood messages, I would bring in an option to disable it?

Thank you for your reply! 

It doesn't cause any issues/flood, I just thought that "Errors only" would not send any other notification; I am a "no news is good news" type of person. 
Again, thank you for your work!

What is going on.  I found this on both of my Unraid servers today!

 

 

And here is the contents of backup.log file:

 

I really don't like that Share, ab_20231005_0211002, being created as root share!   IT is non-descriptive and should not be at this point in the tree structure!

Edited October 5, 20232 yr by Frank1940