I have recently struggled a lot with backing up containers with docker volumes mapped to them. Saw something in the road map about distinguishing between bind voumes and named volumes, but unsure what that entails.

My struggle is this:
[11.05.2026 05:02:53][❌][teamspeak-server-1] 'teamspeak-data' does NOT exist! Please check your mappings! Skipping it for now.
[11.05.2026 05:02:54][debug][teamspeak-server-1] usorted volumes: Array

The volume exists:
docker volume ls | grep -i 'teamspeak'

local teamspeak-data

It is mapped like such:

    volumes:
      - teamspeak-data:/var/tsserver

It's from here I am unsure what to do. This problem happens to a lot of containers, all of which have a docker-volume. Unsure if the backup is worth anything if it truly hasn't taken the data in the volume. If anyone has any advice, it would be much appreciated.

34 minutes ago, Thor_Storm said:

It is mapped like such:

    volumes:
      - teamspeak-data:/var/tsserver

It's from here I am unsure what to do. This problem happens to a lot of containers

/var is a path in the host OS. Unraid OS is in RAM, so anything mapped there will not survive reboot. You must map to actual storage, typically a user share in /mnt/user/...

2 hours ago, trurl said:

/var is a path in the host OS. Unraid OS is in RAM, so anything mapped there will not survive reboot. You must map to actual storage, typically a user share in /mnt/user/...

It seems to me like the directory where volumes are stored is not stored in memory on my part, and in the Unraid docker image file (which maybe isn't ideal, but it works):

Filesystem Size Used Avail Use% Mounted on

/dev/loop2 100G 77G 22G 78% /var/lib/docker

/dev/loop2: [0040]:1613693 (/mnt/cache/system/docker/docker.img)

Is there something in the way that Unraid handles that mapping, or is it something with the way the app interacts with docker volumes? I was positive this was working for me before updating to Unraid 7.x, so maybe I'm missing something.

9 hours ago, trurl said:

/var is a path in the host OS.

/var is the container path here, host side is a docker volume.

6 hours ago, Thor_Storm said:

or is it something with the way the app interacts with docker volumes?

Just don't use docker volumes unless it's absolutely necessary which it doesn't seem like it is in this case, change to an appdata folder.

Edited May 11May 11 by Kilrah

Hi, someone has already tried this on the new internal boot ?
The old "flash backup" will still backup the internal boot too ?

2 minutes ago, Yusseiin said:

Hi, someone has already tried this on the new internal boot ?
The old "flash backup" will still backup the internal boot too ?

I just went and checked this on my backup NAS as I had the same question!

And it seems to work! Instead of "tower-v7.2.4-flash-backup-20260514-0013" I have "tower-v7.3.0-boot-backup-20260515-0210"!

Appdata Backup plugin performance degradation / stalls when encountering sparse files with large logical size (LMDB/Meilisearch pattern)

The Unraid Appdata Backup plugin appears to become very slow or stall when backing up Tunarr appdata due to a massively sparse LMDB database file (data.mdb) inside Meilisearch storage.

The file reports a logical size of ~2TB but only ~44KB of actual disk usage, which likely causes the backup process to treat it as a large file and process it inefficiently.

```
ls -lh data.mdb
-rw------- 1 root root 2.0T May 15 05:19 data.mdb

du -h data.mdb
44K data.mdb
```
Sparse file (high logical size, minimal physical blocks)
LMDB / Meilisearch backend storage

What happened:
Backup process slows significantly or stalls when reaching sparse files with large logical size

Disk I/O spikes on backup destination

Backup time disproportionately increases compared to dataset size (~141MB total appdata directory)

No corresponding increase in actual data size (verified via du)

What should happen:
Sparse files should be handled efficiently (skip unwritten blocks)

Backup time should correlate with actual disk usage, not logical file size

No excessive I/O caused by sparse LMDB mappings

The file is a sparse LMDB database used by Meilisearch:

LMDB preallocates a large virtual address space

File reports large logical size (2TB)

Actual disk usage is tiny

• Backup plugin likely:

  Reads full logical file size

  Does not use sparse-aware copying (--sparse)

  Or calculates progress based on apparent size
  
  ls -lh /mnt/cache/appdata/*/data.mdb

  du -h /mnt/cache/appdata/*/data.mdb

  stat /mnt/cache/appdata/*/data.mdb
  
  tar cf /dev/null /mnt/cache/appdata/tunarr/data
  completes in ~1second, confirming real data size is small.
  
  The backup tool should use sparse-aware copying:

  rsync -S

  • tar --sparse
    
    This is likely not a Tunarr bug directly, but a combination of:

    • Meilisearch LMDB storage behavior

    • Backup plugin not handling sparse files efficiently

Hello,

I've been getting this error recently. It's not the same containers each time and has happened when running in stop all then backup and stop, backup start each container modes.

On 5/16/2026 at 6:56 PM, widowshyper said:

Hello,

I've been getting this error recently. It's not the same containers each time and has happened when running in stop all then backup and stop, backup start each container modes.

Do you have compression with multicore enabled? I found this to cause issues and had to set it to enabled/normal.

On 5/22/2026 at 9:07 PM, totalhavoc said:

Do you have compression with multicore enabled? I found this to cause issues and had to set it to enabled/normal.

Just tried that and still got the same error on one docker container tautulli

Any idea why I receive "There is no configfile... Hmm..."? I'm trying to run a backup for the first time.

Is there a way to set scripts per container instead of a global script? I have a script that I am wanting to run for one container after backup & update but before container start?

6 hours ago, Johnoldiges said:

Is there a way to set scripts per container instead of a global script? I have a script that I am wanting to run for one container after backup & update but before container start?

Perhaps update your script to only run when the passed container name is for your desired script, and just exit the script for the other containers?

I was thinking about that earlier but wanted some clarification on exactly when these two options trigger the script:

• Post-container-backup script - I know this says immediately after the tar file is created so it sounds like it would fire the script before any update to the container happens.
  

• Post-backup script - Sounds like it is what I need (fires off after backup and container update but before container start) as it says it would trigger after backup is complete and before the container starts but doesn't mention before or after an update run so I would like to make sure as this script has to run after an update but before container start so as to not have to stop then start the container when it was already stopped after the update...

Any confirmation on this would be very helpful!

Edited May 26May 26 by Johnoldiges
grammer

Not certain, but would guess this is where these three would run:

Basically, the first is run after each container backup is done.

The second is after all containers are backed up (and maybe the flash?).

The third is the last thing run before the plugin exits.

You could test this by creating some (almost) do nothing scripts, configure them in the backup plugin, and running manually. Then check the logs.

It this working on 7.3.x include Backup the Internal Boot, Docker/AppData, ...?

Yes.

Hi,

Every day I get a notification of an error with my unraid backup, it says to check the debug log but the error message is the same. How do I go about finding out what the problem is please? The only VM I have running on this server is my OPNSense instance.

This app is amazing! I have been using it for years but I am definitely now doing something wrong!!

I have gluetunvpn running and I have some dockers that use this network. When the backup runs some of the other containers fail to start. I have been trying to troubleshoot this, but I am now a little stuck!!

I have noticed that I did have my apps the wrong way round in the 'Start order' So now Gluetun is at the bottom and my other containers are at the top. So this means the gluetun gets backed up first, updated and started.

So gluetun backed up at 03:03 and succeeded

[21.06.2026 03:03:00][debug][GluetunVPN] Volume '/mnt/user/appdata/gluetun' IS within AppdataPath '/mnt/user/appdata'!
[21.06.2026 03:03:00][][GluetunVPN] Should NOT backup external volumes, sanitizing them...
[21.06.2026 03:03:00][debug][GluetunVPN] Volume '/mnt/user/appdata/gluetun' IS within AppdataPath '/mnt/user/appdata'!
[21.06.2026 03:03:00][][GluetunVPN] Calculated volumes to back up: /mnt/user/appdata/gluetun
[21.06.2026 03:03:00][debug][GluetunVPN] Target archive: /mnt/user/backup/appdata_backup/ab_20260621_030002/GluetunVPN.tar.gz
[21.06.2026 03:03:00][debug][GluetunVPN] Generated tar command: --exclude '/usr/local/share/docker/tailscale_container_hook' -c -P -z -f '/mnt/user/backup/appdata_backup/ab_20260621_030002/GluetunVPN.tar.gz' '/mnt/user/appdata/gluetun'
[21.06.2026 03:03:00][][GluetunVPN] Backing up GluetunVPN...
[21.06.2026 03:03:00][debug][GluetunVPN] Tar out:
[21.06.2026 03:03:00][][GluetunVPN] Backup created without issues (took 00:00:00 (hours:mins:secs))
[21.06.2026 03:03:00][][GluetunVPN] Skipping verification for this container because its not wanted!
[21.06.2026 03:03:00][debug][GluetunVPN] Not executing script: Not set!
[21.06.2026 03:03:00][][GluetunVPN] Installing planned update for GluetunVPN...
[21.06.2026 03:03:03][][GluetunVPN] Starting GluetunVPN... (try #1) done!

Here you can see that sonarr started at 03:28 and failed to start:

[21.06.2026 03:28:36][debug][sonarr] Volume '/mnt/user/appdata/sonarr' IS within AppdataPath '/mnt/user/appdata'!
[21.06.2026 03:28:36][debug][sonarr] Volume '/mnt/user/appdata/sonarr' IS within AppdataPath '/mnt/user/appdata'!
[21.06.2026 03:28:36][][sonarr] Should NOT backup external volumes, sanitizing them...
[21.06.2026 03:28:36][debug][sonarr] Volume '/mnt/user/appdata/sonarr' IS within AppdataPath '/mnt/user/appdata'!
[21.06.2026 03:28:36][][sonarr] Calculated volumes to back up: /mnt/user/appdata/sonarr
[21.06.2026 03:28:36][debug][sonarr] Target archive: /mnt/user/backup/appdata_backup/ab_20260621_030002/sonarr.tar.gz
[21.06.2026 03:28:36][debug][sonarr] Generated tar command: --exclude '/usr/local/share/docker/tailscale_container_hook' -c -P -z -f '/mnt/user/backup/appdata_backup/ab_20260621_030002/sonarr.tar.gz' '/mnt/user/appdata/sonarr'
[21.06.2026 03:28:36][][sonarr] Backing up sonarr...
[21.06.2026 03:28:43][debug][sonarr] Tar out:
[21.06.2026 03:28:43][][sonarr] Backup created without issues (took 00:00:07 (hours:mins:secs))
[21.06.2026 03:28:43][][sonarr] Skipping verification for this container because its not wanted!
[21.06.2026 03:28:43][debug][sonarr] Not executing script: Not set!
[21.06.2026 03:28:43][][sonarr] Starting sonarr... (try #1) Container 'sonarr' did not started! - Code: Server error
[21.06.2026 03:28:48][][sonarr] Starting sonarr... (try #2) Container 'sonarr' did not started! - Code: Server error
[21.06.2026 03:28:53][][sonarr] Starting sonarr... (try #3) Container 'sonarr' did not started! - Code: Server error
[21.06.2026 03:28:53][][sonarr] Container 'sonarr' did not started after multiple tries, skipping. More infos in debug log
[21.06.2026 03:28:55][debug][sonarr] docker ps -a:
Array
(
[0] => CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[1] => efa25f4b0b81 lscr.io/linuxserver/firefox "/init" 35 seconds ago Up 31 seconds firefox
[2] => 0089b3d99b44 pihole/pihole "start.sh" 2 minutes ago Up 2 minutes (healthy) binhex-official-pihole
[3] => 343cf7628d47 linuxserver/duplicati "/init" 3 minutes ago Up 3 minutes duplicati
[4] => 6ab407a953fd adminer "entrypoint.sh docke…" 25 minutes ago Created adminer
[5] => 9eb5ea083b7f tautulli/tautulli "./start.sh python T…" 25 minutes ago Up 25 minutes (healthy) tautulli
[6] => 422c05663e0e qmcgaw/gluetun "/opt/unraid/tailsca…" 25 minutes ago Up 25 minutes (healthy) 0.0.0.0:3000-3001->3000-3001/tcp, [::]:3000-3001->3000-3001/tcp, 0.0.0.0:5880->5880/tcp, [::]:5880->5880/tcp, 0.0.0.0:5990->5990/tcp, [::]:5990->5990/tcp, 0.0.0.0:6767->6767/tcp, [::]:6767->6767/tcp, 0.0.0.0:6881->6881/tcp, [::]:6881->6881/tcp, 0.0.0.0:7878->7878/tcp, [::]:7878->7878/tcp, 0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp, 1080/tcp, 1080/udp, 0.0.0.0:8112->8112/tcp, [::]:8112->8112/tcp, 0.0.0.0:8888->8888/tcp, [::]:8888->8888/tcp, 0.0.0.0:8989->8989/tcp, [::]:8989->8989/tcp, 0.0.0.0:9696->9696/tcp, [::]:9696->9696/tcp, 8388/tcp, 8388/udp, 0.0.0.0:58846->58846/tcp, [::]:58846->58846/tcp, 0.0.0.0:6881->6881/udp, [::]:6881->6881/udp GluetunVPN
[7] => f48cffe8e418 lscr.io/linuxserver/prowlarr "/init" 6 days ago Exited (128) 2 minutes ago prowlarr
[8] => f62cc172c6fa lscr.io/linuxserver/radarr "/init" 6 days ago Up 41 hours radarr
[9] => 84074e0729bc lscr.io/linuxserver/nextcloud "/init" 6 days ago Up 24 minutes nextcloud
[10] => 15914174190f jlesage/jdownloader-2 "/init" 6 days ago Up 41 hours JDownloader2
[11] => 278b5e198170 lscr.io/linuxserver/bazarr "/init" 6 days ago Up 41 hours bazarr
[12] => 54e0d7040941 mongo "docker-entrypoint.s…" 7 days ago Up 2 minutes MongoDB
[13] => 2513e61e7fb8 linuxserver/sonarr "/init" 7 days ago Exited (128) 18 seconds ago sonarr
[14] => 2875c7941aa8 lscr.io/linuxserver/deluge "/init" 7 days ago Up 41 hours deluge
[15] => ed5b555f2c82 ghcr.io/haveagitgat/tdarr "/init" 7 days ago Created tdarr
[16] => 51638610e706 jlesage/filezilla "/init" 11 days ago Up 24 minutes FileZilla
[17] => 9fc7d4db72b9 linuxserver/duckdns "/init" 2 weeks ago Up 2 minutes duckdns
[18] => 443627fb1d18 lscr.io/linuxserver/mariadb "/init" 2 weeks ago Up 3 minutes mariadb
[19] => 64453ad755e7 jc21/nginx-proxy-manager "/init" 2 weeks ago Up 3 minutes Nginx-Proxy-Manager-Official
[20] => 3f8b845185b0 ghcr.io/imagegenius/immich "/init" 2 weeks ago Up 22 minutes immich
[21] => 0cdab2c885b4 lscr.io/linuxserver/unifi-network-application "/init" 2 weeks ago Up 24 minutes unifi-network-application
[22] => ac69de526bac drakkan/sftpgo "sftpgo serve" 3 weeks ago Up 22 minutes SFTPGo
[23] => e945f258f535 plexinc/pms-docker "/init" 4 weeks ago Up 16 minutes (healthy) Plex-Media-Server
[24] => 438fa916eb57 tensorchord/pgvecto-rs:pg16-v0.3.0 "docker-entrypoint.s…" 5 weeks ago Up 25 minutes PostgreSQL_Immich
[25] => 0670cd2ccc6d vaultwarden/server "/start.sh" 6 weeks ago Up 3 minutes (healthy) bitwardenrs
[26] => 756da835e256 ghcr.io/lovelaze/nebula-sync:latest "nebula-sync run" 6 weeks ago Up 25 minutes (healthy) nebula-sync
[27] => f6f702206033 rdavidoff/twitch-channel-points-miner-v2:latest "python run.py" 3 months ago Up 22 minutes Twitch-Channel-Points-Miner
[28] => 8508c20e174b jasonbean/guacamole "/etc/firstrun/first…" 4 months ago Up 22 minutes ApacheGuacamole
[29] => 9d41a93e75f6 louislam/uptime-kuma "/usr/bin/dumb-init …" 4 months ago Up 24 minutes (healthy) UptimeKuma
)

[21.06.2026 03:28:55][][sonarr] The container has a delay set, waiting 10 seconds before carrying on

It says to check the debug log, but this is from the Appdata backup debug log.

If I then go into Docker I can start sonarr without issue. I get this with some, but not all, of my docker containers that run under gluetun. Can anyone see what I am doing wrong here?

Edited June 22Jun 22 by showstopper

The amount of posts in this thread is huge, sorry if this has been asked already. Now that there is an internal boot option, is it safe to assume the 'Backup the flash drive?' option works with a boot drive in the same fashion as the flash drive? Thanks