Not a major issue. Rename the folder and you should be good to go.

10 minutes ago, KluthR said:

Not a major issue. Rename the folder and you should be good to go.

Thanks for your help!

One small suggestion, the ordering of restart should, by default, be the same as the order they appear on the Docker tab, otherwise I am just setting the same thing twice (databases before apps, etc)...

16 hours ago, KluthR said:

Check the debug log at that line and show what it was trying to do right before it.

[27.01.2026 05:32:08][][Main] Backing up the flash drive.
[27.01.2026 05:33:19][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260127-0532.zip
[27.01.2026 05:35:02][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 18874368 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191
[27.01.2026 05:35:02][][Main] Copying flash backup to destination failed!

When I manually backed up the flashdrive, the size was about 1.6GB. It has backed up previously with similar sizes.

7 hours ago, semtex41 said:

[27.01.2026 05:32:08][][Main] Backing up the flash drive.
[27.01.2026 05:33:19][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260127-0532.zip
[27.01.2026 05:35:02][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 18874368 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191
[27.01.2026 05:35:02][][Main] Copying flash backup to destination failed!

When I manually backed up the flashdrive, the size was about 1.6GB. It has backed up previously with similar sizes.

How much RAM do you have? How much free for the root in the output of df -h?

The flash backup is created by the system in the rootfs.

22 hours ago, Kilrah said:

How much RAM do you have? How much free for the root in the output of df -h?

The flash backup is created by the system in the rootfs.

16GB RAM. 
# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       490Mi       2.1Gi       6.5Gi       4.5Gi
Swap:             0B          0B          0B


# df -h
Filesystem                     Size  Used Avail Use% Mounted on
rootfs                         7.8G  2.0G  5.8G  26% /

Edited January 31Jan 31 by semtex41
correct values this time.

Hi everyone, I looked through this thread and saw that a couple of people were having similar issues with tar verification when backing up /mnt/cache/appdata, but not sure I saw the resolution?

I have two dockers using /mnt/cache/appdata preferentially for their backups since they use sqlite heavily and lock states cause messes if they point to /mnt/user/appdata - pocket-id and bazarr.

I checked their individual docker entries, and the plugin correctly pulls in the /mnt/cache/appdata/pocket-id path, but I still get tar verification failures.

> tar verification failed! Tar said: tar: /mnt/cache/appdata/pocket-id: Not found in archive; tar: Exiting with failure status due to previous errors

Any iudea how to get rid of this error and have it validate correctly?

Plex Backup issues - Appdata Backup BETA (2025.09.17b1) - Giant backup sizes & Verification Errors

Hello everyone,

I am experiencing a critical issue with the latest Beta version of the Appdata Backup plugin (2025.09.17b1) on Unraid 7.2.3. As a SysAdmin, I've tried to debug the situation, but I've encountered a loop that makes the backup either massive (355GB+) or completely empty (0 bytes).

The Environment:

• Unraid Version: 7.2.3.

• Plugin Version: 2025.09.17b1 (Beta).

• Affected Container: Plex-Media-Server (official plexinc/pms-docker).

• Mapping: I have /mnt mapped to /data:rw within the container for media access.

The Issues:

1. Massive Backup Size: When I tried to perform a manual backup, the process attempted to include the external volume /mnt. Even though I explicitly added /mnt and /mnt/user/PLEX/Transcode to the "Excluded folders/files" list, the log showed: Backing up EXTERNAL volumes, because its enabled!. This resulted in a 600GB+ backup file before I had to manually abort the process to prevent disk exhaustion.

2. Verification Failure: When the backup does complete for other containers or a smaller Plex set, I frequently get: tar verification failed! Tar said: tar: /mnt/user/appdata/Plex-Media-Server: Not found in archive. It seems like the verification engine is having trouble with the internal pathing or the sheer number of small metadata files in the Plex directory.

3. UI/Logic Conflict: In the container settings, I noticed that the "Save external volumes?" option seems to override the exclusion list or behaves inconsistently when multiple paths are mapped. If I exclude everything to avoid the 355GB size, the backup finishes in 0 seconds with no data saved at all.

Log snippet of the failure:

Plaintext

][Plex-Media-Server] Backing up EXTERNAL volumes, because its enabled! [04.02.2026 07:30:46][debug][Plex-Media-Server] Container got excludes! /mnt, /mnt/user/PLEX/Transcode... [04.02.2026 07:30:46][ℹ️][Plex-Media-Server] Backing up Plex-Media-Server... [04.02.2026 07:30:46][X][Plex-Media-Server] tar verification failed!

Questions:

• Is there a known issue where "Save external volumes = Yes" completely ignores the exclusion of the root /mnt path?

• Why does the verification fail with "Not found in archive" even when the .tar.zst file was just created?

Any help or guidance would be greatly appreciated. I'm trying to keep my appdata backups lean and synced to the cloud via rclone, but this Plex behavior is currently blocking my automation.

Best regards,

Can someone please explain how exclude actually works? I'm pulling my hair out trying to figure this out.

EDIT: Problem solved. I was trying to exclude like this:

/mnt/cache/appdata/[program]

but it has to be like this:

/mnt/user/appdata/[program]

Edited February 4Feb 4 by ratmanjones

On 1/29/2026 at 7:16 PM, semtex41 said:

[27.01.2026 05:32:08][][Main] Backing up the flash drive.
[27.01.2026 05:33:19][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260127-0532.zip
[27.01.2026 05:35:02][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 18874368 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191
[27.01.2026 05:35:02][][Main] Copying flash backup to destination failed!

When I manually backed up the flashdrive, the size was about 1.6GB. It has backed up previously with similar sizes.

1 week later:

[03.02.2026 05:31:20][][unifi-controller-reborn] Starting unifi-controller-reborn... (try #1) done!
[03.02.2026 05:31:23][][Main] Backing up the flash drive.
[03.02.2026 05:32:35][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260203-0531.zip
[03.02.2026 05:32:39][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 32702464 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191
[03.02.2026 05:32:40][][Main] Copying flash backup to destination failed![03.02.2026 05:32:40][][Main] Checking retention...
[03.02.2026 05:32:40][debug][Main] toKeep after slicing:


root@tower:~# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        10Gi       597Mi       3.3Gi       7.6Gi       4.6Gi
Swap:             0B          0B          0B
root@tower:~# df -h
Filesystem                     Size  Used Avail Use% Mounted on
rootfs                         7.8G  3.2G  4.7G  41% /
devtmpfs                       7.8G     0  7.8G   0% /dev

Still having this issue and not sure of the root cause. The appdata backup appears to have saved correctly otherwise.
Manual flash backup is: 1.2GB
In the backup location today, it did attempt to save the flash, but it is corrupted at 480.8MiB.

I'm having an odd issue with the backup of the Plex appdata folder :

[05.02.2026 10:16:18][ℹ️][plex] tar creation failed! Tar said: tar: /mnt/user/appdata/plex/Plex Media Server/Plug-in support/Databases/com.plexapp.plugins.library.blobs.db-wal: file changed as we read it

I already have all the recommended items and paths excluded, the issue seems to be that one of the database files is always altered during the backup.

I tried making it so that plex is shutdown for backup, but this plugin refuses to allow that (shows an error message saying it's recommended not to shut down plex and keeps it running).

I considered adding that blob to the exclusions, but it's a database file so I assume it's going to be a pain if I don't have a backup of it if I ever want to recover the plex install later!

I've also tried setting the backup time to a time of day when noone is using plex, but that seems to make no difference the database backup still fails.

19 hours ago, Nirin said:

I tried making it so that plex is shutdown for backup

Well it is not here.

When I go to the docker page and enable advanced view I have a lot of Orphaned images.

I believe this happens when updating a docker image that has 2 (or more) images.
Am I understanding it correctly that adding all these apps to a group stop these orphan images from appearing?

No, that wouldn't help, container being stopped is not enough, it has to be deleted to be able to remove the image.

Orphan images will also appear if you change tags.

Edited February 10Feb 10 by Kilrah

Dang I was hoping that would be the solution. I have two instances of radarr for 4k and HD movies. Basically I'm getting 4 orphans a month and I forgot to delete them for a while. Going one by one in the ui is annoying because it scrolls to the top each time. Could run -prune in the cli but I have a few stopped containers that I'm not ready to get rid of.

So appdata backup force shutdown my postgresql17 container and corrupted the database.

Is there a good solution for this? Because right now I am thinking this thing might be worse than having no backup. If I am trying to safeguard my data, the one thing it should absolutely never do is exactly what it did.

Yeah, I could probably script something to make it wait longer - and maybe I will (realistically I want it to wait a long time for a graceful shutdown and if it doesn't get it, then skip it that container now and flag it to me to deal with in the morning).

For now I guess I am just going to have it not backup my databases, which is a total garbage solution.

Am I missing something obvious here?

7 hours ago, daithi said:

Could run -prune in the cli but I have a few stopped containers that I'm not ready to get rid of.

docker image prune -f -a will only delete really orphan images, not images that are used by a stopped container.

2 hours ago, kesx said:

Yeah, I could probably script something to make it wait longer - and maybe I will (realistically I want it to wait a long time for a graceful shutdown and if it doesn't get it, then skip it that container now and flag it to me to deal with in the morning).

The plugin doesn't control the timeout so you'd still be likely to encounter the same issues outside of the backup scenario (shutdown, reboot, just manually stopping the container). Increase the global container stop timeout in Docker settings.

hi. i'm getting warning notification to check logs. but, from the actual logs doesnt seem to show any error or warning from the appdata backup gui. or maybe i missed something?
could help to verify what is wrong? attached are the recent logs.

thank you


ab(1).logab.debug(3).log

Is it possible to configure the backup to not package the files? Ideally i want the result of the backup to just be non packaged and non compressed copies of the data. I found the option to disable compression but that still packages the files into a .tar instead of just leaving them as a folder

I use Appdata Backup daily and I have a backup of Nextcloud. Recently, I had to remove and re-install Nextcloud and in particular the Cookbook app. In UnRaid, I can see the path to the recipes folder: /mnt/dockers_ssd/appdata/Nextcloud/data/Fred/files.

I thought I could just open the ab_20260301_200020 folder, and extract just the recipes to this folder. There is a Nextcloud.tar.gz I can get to, but no recipes folder anywhere. Indeed, while there is a \mnt\user\appdata\Nextcloud folder, there is no /data/Fred/files.

Does Appdata backup not backup the actual data files? I see no Nextcloud/data/Fred/files folder structure anywhere?

I have no copies of these recipes outside of what I had on Nextcloud and the backup's.

Edited March 7Mar 7 by RaidPC

Need to check the backup settings for that container that it backs up the paths you want.

Also besides the main "file storage/sync" function of Nextcloud the apps will often NOT have their data in folders but stored in the database. So it's crucial to back that up too.

Hi everyone,

I've been using the Appdata Backup plugin in Unraid and it's been a game-changer for managing my Docker containers. However, I have a few suggestions and questions that could make it even better. I'd love to hear the developer's thoughts or if anyone else has workarounds.

Default Backup Behavior for New Containers

The plugin currently backs up every new (unknown) container with default settings. Is it possible to add a toggle to change this to an opt-in approach? I run a lot of Docker containers and install new ones frequently (that's the point of a lab environment), but I only want to back up the ones I consider "permanent" on my server. Instead of having to disable backups every time I install something new, I'd prefer to enable backups only for specific containers.

Clarification on Start Order Panel

I'm a bit confused about the "Start order" panel. It says, "This defines the start sequence. Stop would be this order in reverse." Does this refer to the start sequence of Docker containers on my Unraid server, or the start sequence of the backups themselves?

Request for Pre-Container Stop Hook

For custom scripts, is there any way to add a hook for "pre-container stop" with arguments like "pre-stop" and the container name? The default behavior is to stop the container, back it up (optionally update the image), and bring it back up.

I have a lot of containers running, and some require special attention. For example, I have an rclone container that FUSE mounts a remote WebDAV into my host filesystem. This container runs at position 67/100 in my setup, so before stopping it, I need to run a custom script to safely decouple everything.

Unfortunately, none of the current hooks work: "Pre-run" executes at position 0/100, so any containers from 0-67 that need sue the mounted WebDAV would fail if the decoupling script runs then. "Pre-container-backup" doesn't work either because it triggers after the container has already stopped.

Other than these points, this plugin is amazing, and I thank you for your hard work!

Best regards

Found a fun little UI bug.

\

Turns out I wasn't saying 'Yes' to updating the container after backup, I was saying 'Yes' to saving external volumes, which is 20TB of media.

Cache filled and server crashed.

Might also be a good idea to have the option to save the log files to a location other than /tmp as since this stores in RAM, they are lost on a reboot.

On 2/3/2026 at 6:36 PM, kesx said:

Hi everyone, I looked through this thread and saw that a couple of people were having similar issues with tar verification when backing up /mnt/cache/appdata, but not sure I saw the resolution?

I have two dockers using /mnt/cache/appdata preferentially for their backups since they use sqlite heavily and lock states cause messes if they point to /mnt/user/appdata - pocket-id and bazarr.

I checked their individual docker entries, and the plugin correctly pulls in the /mnt/cache/appdata/pocket-id path, but I still get tar verification failures.

> tar verification failed! Tar said: tar: /mnt/cache/appdata/pocket-id: Not found in archive; tar: Exiting with failure status due to previous errors

Any iudea how to get rid of this error and have it validate correctly?

did you manage to find a solution to this?

i'm encountering the same issue. I have excluded the paths correctly, but still fails