Total: 123 (running: 122, paused: 0, stopped: 1)

So there’s nothing I can do about it, right? Or what were the workarounds?

Thanks for the quick reply!

A permanent fix is in the pipeline. I still await feedback from some beta testers and then there will be a plugin update available.

I've been seeing this odd issue the last few weeks, but haven't taken the time to post about it.
I do a weekly appdata backup. The backup works great (thank you!), updating the containers works great (thank you again!), and then all the containers start back up as they should (thanks yet again lol), however, about half the containers report that they fail the first start up attempt, but then report that the second attempt is skipped because they're already running. It's like the first attempt DID work, it just didn't wait long enough to check?

Log looks like this (but with a lot more containers)

[01.09.2025 01:15:43][ℹ️][Main] Set containers to previous state
[01.09.2025 01:15:43][ℹ️][mariadb] Starting mariadb... (try #1) done!
[01.09.2025 01:15:56][ℹ️][nextcloud] Starting nextcloud... (try #1) done!
[01.09.2025 01:16:25][ℹ️][plex] Starting plex... (try #1) done!
[01.09.2025 01:16:54][ℹ️][radarr] Starting radarr... (try #1) done!
[01.09.2025 01:17:54][ℹ️][sonarr] Starting sonarr... (try #1) Container did not started! - Code:
[01.09.2025 01:19:02][ℹ️][sonarr] Starting sonarr... (try #2) Hmm - container is already started!
[01.09.2025 01:19:04][ℹ️][bazarr] Starting bazarr... (try #1) Container did not started! - Code:
[01.09.2025 01:20:53][ℹ️][bazarr] Starting bazarr... (try #2) Hmm - container is already started!
[01.09.2025 01:20:55][ℹ️][ddns-updater] Starting ddns-updater... (try #1) Container did not started! - Code:
[01.09.2025 01:22:43][ℹ️][ddns-updater] Starting ddns-updater... (try #2) Hmm - container is already started!
[01.09.2025 01:22:45][ℹ️][immich] Starting immich... (try #1) Container did not started! - Code:
[01.09.2025 01:25:05][ℹ️][immich] Starting immich... (try #2) Hmm - container is already started!

I understand this plugin to be frozen and only bugfixes moving forward.

I am not requesting a bugfix or anything. Just a note to others.

Thank you for the time and effort you have given the community.

---

Plex backup isn't working for me.

"plex does not have any volume to back up! Skipping. Please consider ignoring this container."

I think the issue is this: "/mnt/cache/appdata/plex" is showing as external somehow.

Weird. I will look at debug logs next.

---

Also groups, you simply make one by typing text in the group field and hitting save. Current help text doesn't make a ton of sense. Hope that helps others.

8 hours ago, NathanR said:

I think the issue is this: "/mnt/cache/appdata/plex" is showing as external somehow.

That would mean that /mnt/cache/appdata is not included in the Appdata Sources setting.

@theothermatt_b The script doesnt wait itself. It calls Unraids Docker Helper (which in turn calls docker itself) to start container X. And waits until docker returns the result. In your case docker returns a non successful start result. However, somehow it DID started, yes. Maybe docker is so busy to time out on the start request, returns a non successful result code but in the meantime it worked. No clue. And nothing I can fix.

Try a reboot and monitor again

@NathanR Yes, the grouping field is not that self explaining. I try to add some more text.

On 9/8/2025 at 2:23 AM, Kilrah said:

That would mean that /mnt/cache/appdata is not included in the Appdata Sources setting.

Agreed. However that is not the case as all my other dockers backup properly.

(I did not show that screenshot, but I have tried multiple source types in the settings box. Even going so far to list every plex sub-directory. All yield the same result.)

It’s a weird bug. No worries here. I’ll probably move to zfs snapshots at some point and won’t worry about this.

@KluthR no worries, I’m not asking you to change anything. I figured it out by reading other messages in this thread. Thank you :)

Hey, me again.

This month my gitlab got deleted AGAIN during the backup process, thank you!

🤷 The plugin has no code to delete containers. Not sure what you want to read as an answer now. If you have some debug log from the affecting run, upload it here please.

Hello, I have a rather precarious Problem: The Appdata Backup Settings page has disappeared.
I was doing some stuff on my server and noticed that a few containers were stopped even though they are on auto-start. I quickly realized that it was just AB shutting them down for backups, and wanted to view the progres on the settings page. I then thought I was crazy for about 5 minutes because i couldn't find it. When I looked in the Plugins Tab, its name was "appdata.backup" with no further description, and clicking on the settings icon brought me to "[Server Address]/Settings/AB.Main", which was a completely blank page.

I was able to open the settings page not too long ago and i don't remember there being any updates. what might cause this problem?

Thanks in advance for the help and for this neat plugin!

On 8/18/2025 at 11:30 AM, Haskida said:

Hello all,

I got an error with my backup this morning and would like to read the debug log

However, I could not for the life of me figure out how to access the debug logs

I tried the "SHARE DEBUG LOG" button but all it does is send the log to the developer, and tells me that I can find the log at "/tmp/appdata.backup", which I have no idea where it is. I tried to look for /tmp/appdata.backup with krusader to no avail too

Can someone please tell me how I can access my own debug log?

Thanks in advance

Does anybody know the answer to this?

Thanks in advance

Keep at least this many backups

It is actually a bit misleading. It implies that we're always going to have 3 remaining backups (as set above) of a container appdata.
Actually, Plugin will not keep 3 backups. It will keep only 3 backup folders.
If a container was temporarily removed, new backups created, the plugin will eventually delete 3 backup folders, effectively removing all existing backups for the container /appdata.

A simple solution could be:
- Backup completed ---> prior to deleting the oldest backup folder, move unique files to the newer backup folder?


Another handy safety feature:
Option to by default automatically back up all other folders inside /appdata apart from excluded ones.
Current behaviour requeries going through the whole list of containers and excluding their data when /mnt/cache/appdata is added to extras

the backup failed last night on all containers with this reason:

tar creation failed! Tar said: tar (child): /mnt/user/backup/AppdataBackup/ab_20250917_040001/Posterizarr.tar.gz: Cannot open: No space left on device; tar (child): Error is not recoverable: exiting now; tar: /mnt/user/backup/AppdataBackup/ab_20250917_040001/Posterizarr.tar.gz: Cannot write: Broken pipe; tar: Child returned status 2; tar: Error is not recoverable: exiting now

Cant figure out why though since im nowhere near out of space at that location (1.8TB free at the disk unraid is currently using and 5.1TB free in total amongst all disks in the array) and one backup run (all containers) uses about 25GB of data total.

any suggestions?

Edited September 17, 2025Sep 17 by kakburken

On 9/15/2025 at 6:52 PM, Haskida said:

Does anybody know the answer to this?

Thanks in advance

Latest release has inplace button to switch logs.

1 hour ago, KluthR said:

Latest release has inplace button to switch logs.

Awesome! didn't realize a new update was available. I am able to see the debug log now.

Thanks!

After updating to version 2025.09.17 the plugin throws an error after every backup. It seems to be caused by my use of folder groups (the FolderView2 plugin). It's done this multiple nights in a row now (set to daily backup).

It knows about the group, but ends up duplicating the group name as a container (i.e [backups][backups]. I have multiple groups, but there is one group that I've ignored two of the 3 containers inside and that's where the problem happens.

The debug log indicates that it hasn't identified the groups correctly; it only shows one, "backups", and my proxmox backup server container isn't in it. The other two (kopia and rsync) are set to skip.

ab.debug.log

Yea, seems like I maybe have messed up something there. Ill check it asap

Edited September 21, 2025Sep 21 by KluthR

It all worked fine for a bit but recently its not doing any flash backups. Plenty of space. It has access. But it fails to backup flash.

[21.09.2025 15:07:18][ℹ️][Main] Backing up the flash drive.
[21.09.2025 15:07:47][debug][Main] flash backup returned: messiah-v7.1.4-flash-backup-20250921-1507.zip
[21.09.2025 15:07:55][ℹ️][Main] Flash backup created!
[21.09.2025 15:07:55][ℹ️][Main] Copying the flash backup to '/mnt/remotes/R2_Backup/' as well...
[21.09.2025 15:07:55][debug][Main] PHP-ERROR occured! 2 / copy(/mnt/remotes/R2_Backup//messiah-v7.1.4-flash-backup-20250921-1507.zip): Failed to open stream: No such file or directory /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:197
[21.09.2025 15:07:55][❌][Main] Copying the flash backup to '/mnt/remotes/R2_Backup/' FAILED!
[21.09.2025 15:07:55][ℹ️][Main] Checking retention...
[21.09.2025 15:07:55][debug][Main] toKeep after slicing:
Array
(
[0] => /mnt/remotes/192.168.0.146_Backup/ab_20250921_145836
[1] => /mnt/remotes/192.168.0.146_Backup/ab_20250915_030001
[2] => /mnt/remotes/192.168.0.146_Backup/ab_20250908_030002
)

[21.09.2025 15:07:55][debug][Main] Delete backups older than 20250914_150755
[21.09.2025 15:07:55][debug][Main] Discarding /mnt/remotes/192.168.0.146_Backup/ab_20250921_145836, because its newer or already in toKeep
[21.09.2025 15:07:55][debug][Main] Discarding /mnt/remotes/192.168.0.146_Backup/ab_20250915_030001, because its newer or already in toKeep
[21.09.2025 15:07:55][debug][Main] Discarding /mnt/remotes/192.168.0.146_Backup/ab_20250908_030002, because its newer or already in toKeep
[21.09.2025 15:07:55][debug][Main] Discarding /mnt/remotes/192.168.0.146_Backup/ab_20250901_030001, because its newer or already in toKeep
[21.09.2025 15:07:55][debug][Main] Cannot create date from ab_20250602_000001-failed
[21.09.2025 15:07:55][debug][Main] Resulting toKeep: /mnt/remotes/192.168.0.146_Backup/ab_20250921_145836, /mnt/remotes/192.168.0.146_Backup/ab_20250915_030001, /mnt/remotes/192.168.0.146_Backup/ab_20250908_030002, /mnt/remotes/192.168.0.146_Backup/ab_20250602_000001-failed
[21.09.2025 15:07:55][debug][Main] Resulting deletion list: /mnt/remotes/192.168.0.146_Backup/ab_20250901_030001
[21.09.2025 15:07:55][ℹ️][Main] Delete old backup: /mnt/remotes/192.168.0.146_Backup/ab_20250901_030001
[21.09.2025 15:07:55][ℹ️][Main] DONE! Thanks for using this plugin and have a safe day ;)
[21.09.2025 15:07:55][ℹ️][Main] ❤️
[21.09.2025 15:07:56][debug][Main] Not executing script: Not set!

17 hours ago, spyder said:

After updating to version 2025.09.17 the plugin throws an error after every backup

I still dont see why the update triggered this (because I did not changed much within the grouping logic) but I found an issue regarding empty groups, which is your issue here. The plugin group is empty after resolving, because your only group member is set to "skip: Yes". Thats the only reason.

Please replace the contents from /usr/local/emhttp/plugins/appdata.backup/include/ABHelper.php with the contents from this: https://raw.githubusercontent.com/Commifreak/unraid-appdata.backup/bf027f6231487b8011573ca893fbc64f054f5b82/src/include/ABHelper.php

and let it run again. Please upload the debug log afterwards.

7 hours ago, KluthR said:

I still dont see why the update triggered this

I'm afraid I can't help with that, my server rebooted not long after upgrading plugins. Maybe it was just not throwing an unraid notification error before?

I could perhaps downgrade the plugin to check, but I'm not sure it matters exactly why I suddenly had the issue. Your patch fixed it. Thank you.

ab.debug.log

6 minutes ago, spyder said:

Your patch fixed it. Thank you.

The debug log confirmed it.

I make another test and will release a fix tomorrow morning. Thanks for testing!

Hi

my usershare "appdata" is set to use /mnt/cache_nvme/appdata (no secondary storage)

some of my docker templates use a direct file path for appdata "/mnt/cache_nvme/appdata/<appname>"

instead of a user share "/mnt/user/appdata/<appname>"

... I did this to remove the file system overheads ...

Is this a problem with using this backup plugin or are there any special considerations for me?

Thanks
Mike

Edited September 26, 2025Sep 26 by kiwijunglist

As long as both paths are in appdata sources no.

These days you should be using the user share path and enable exclusive shares, that would bypass the overhead as well without requiring direct paths.

I've been having issues ever since i updated to the latest plugin. Plex fails majority of the time with similar errors. I've tried optimizing and cleaning up plex database prior to doing a manual update and it will give me a similar failure. Also tried deleting the offending file that it calls out but it then fails with a different file. Only source file I have backing up is /mnt/cache/appdata. For Plex specfically, i have /mnt/cache/appdata/plex as internal. My temp transcode and media folder is set as excluded.