Make a post-run script that encrypts the backups into another location and deletes the source.

Edited April 14, 20251 yr by Kilrah

I'm looking at moving from 6.12.15 to 7.0.1 and wanted to make sure I had an appdata backup. I have this set to run automatically but have never checked the file before. I noticed in my appdata backup folder the last time it ran a file labeled ab_20250422_145240-failed was created. I ran one manually and it also failed, [22.04.2025 16:28:38][⚠️][Main] An error occurred during backup! RETENTION WILL NOT BE CHECKED! Please review the log. If you need further assistance, ask in the support forum.". I notice a few warnings "SpeedTest-By-OpenSpeedTest] SpeedTest-By-OpenSpeedTest does not have any volume to back up! Skipping. Please consider ignoring this container." If I ignore this container during appdata backups will this remove these errors? I have two other containers with the same message. Thanks

Nope those aren't errors that will mark it failed, look for other problems.

There is maybe some weird conflict with the docker compose plugin going on. I had a Container that i first deployed over the Unraid GUI but then switched to a docker compose. Now whenever the Backup Scripts stops and restarts the Containers, this one Container is always created outside docker compose. Its weird, because its not happening to any other Container that is in a compose stack

Go to Apps -> Previous Apps, delete the old template. Probably has the same name as the container in compose causing confusion.

Can anyone tell me if i have this right? The way ive set it, it only moves stuff that’s older than 30 days IF 85% or more of the cache is full, right? The old mover tuning had a “force move it over xx% of cache” which i really liked bc that way if i have no files over 30 days old it wouldn’t keep them in cache if it got more full than 85% or whatever i set it to. 

7 minutes ago, pleasehelpmeguys said:

Can anyone tell me if i have this right?

I can tell you that you are on the wrong support thread.

 

You can go directly to the correct support thread for any of your plugins by clicking its Support link in the Plugins page of your Unraid webUI.

Good Morning, thank you for the wonderful app, it just backs up half of my containers, the others say: [27.04.2025 09:32:06][ℹ️][wrapperr] Should NOT backup external volumes, sanitizing them...

 

Is there anything i am doing wrong?

DEbug id: de024fb3-88bc-4737-8c9a-d48015f8c657

Edited April 27, 20251 yr by aymanibousi

On the way, so not able to check debug log. But if its just this message: Open the per container settings and read the info about external and internal volumes. Check if you want to include any external volume. Default is to NOT backup external volumes, hence this message (which is just an info)

Edited April 27, 20251 yr by KluthR

I'm also getting padding with zeros error.

This container is not even started, and the mapped path is not in use for any other docker container

 

 

[05.04.2025 12:44:44][ℹ️][ferdium] No stopping needed for ferdium: Not started!
[05.04.2025 12:44:44][debug][ferdium] Not executing script: Not set!
[05.04.2025 12:44:44][debug][ferdium] Backup ferdium - Container Volumeinfo: Array
(
    [0] => /mnt/user/appdata/ferdium:/config:rw
)

[05.04.2025 12:44:44][debug][ferdium] usorted volumes: Array
(
    [0] => /mnt/user/appdata/ferdium
)

[05.04.2025 12:44:44][ℹ️][ferdium] Should NOT backup external volumes, sanitizing them...
[05.04.2025 12:44:44][debug][ferdium] Volume '/mnt/user/appdata/ferdium' IS within AppdataPath '/mnt/user/appdata'!
[05.04.2025 12:44:44][ℹ️][ferdium] Calculated volumes to back up: /mnt/user/appdata/ferdium
[05.04.2025 12:44:44][debug][ferdium] Target archive: /mnt/user/appdata-disks/CommunityApplicationsAppdataBackup/ab_20250405_110002/ferdium.tar
[05.04.2025 12:44:44][debug][ferdium] Generated tar command: -c -P -f '/mnt/user/appdata-disks/CommunityApplicationsAppdataBackup/ab_20250405_110002/ferdium.tar' '/mnt/user/appdata/ferdium'
[05.04.2025 12:44:44][ℹ️][ferdium] Backing up ferdium...
[05.04.2025 12:45:12][debug][ferdium] Tar out: tar: /mnt/user/appdata/ferdium/.config/Ferdium/Partitions/service-1954dbfc-c6e4-49e9-8564-8e96ad85444f/Cache/Cache_Data/012cb887f079a2f9_0: File shrank by 520 bytes; padding with zeros
[05.04.2025 12:45:12][❌][ferdium] tar creation failed! Tar said: tar: /mnt/user/appdata/ferdium/.config/Ferdium/Partitions/service-1954dbfc-c6e4-49e9-8564-8e96ad85444f/Cache/Cache_Data/012cb887f079a2f9_0: File shrank by 520 bytes; padding with zeros
[05.04.2025 12:45:29][debug][ferdium] lsof(/mnt/user/appdata/ferdium)
Array
(
)

[05.04.2025 12:45:29][debug][ferdium] Not executing script: Not set!
[05.04.2025 12:45:29][ℹ️][ferdium] Installing planned update for ferdium...
[05.04.2025 12:45:40][ℹ️][ferdium] Starting ferdium is being ignored, because it was not started before (or should not be started).

 

For everyone using Tailscale: It seems, that the plugin gets irritaed by the hook-script which is inserted as volume.

 

• Can someone confirm the issue oin their side?
• Can someone confirm also, that adding "/usr/local/share/docker/tailscale_container_hook" to the global exclusion list fixes the issue?

For reference: https://github.com/Commifreak/unraid-appdata.backup/issues/50#issuecomment-2843085311

Hi all,

Just reinstalled all my dockers.  Now getting this when I run a backup.  Any ideas what it means as it causes the backup to be classes as a failure.  Note at the end of the backup is: [Main] An error occurred during backup! RETENTION WILL NOT BE CHECKED!  Please review the log. If you need further assistance, ask in the support forum.

 

Backup used to run fine.

 

Any suggestions would be welcome.

 

Thanks,

Dwarfboysim

You have 2 containers using the same appdata folders. Group them so they're both stopped, and maybe add some exclusions so the same folders don't get backed up twice like they are now.

Edited May 2, 20251 yr by Kilrah

Greetings....Been thus this for a long time, so thanks!  I did receive my first error ever last night where none of my dockers restarted.  I can not seem to find the local degug log, looked and looked and can just find the backup log which tells me to look in the debug log.    (I can find no TMP directory anywhere.)   But it seems I can share it with the developer for help...So...HELP!   

 

If I reboot the server, all dockers come back started.  If I try running a backup, they fail again to restart.  

 

(I am not out of drive space anywhere.)

 

9b514ef6-4d0c-45be-8da9-6c709178a192   Looking forward to a response. 

 

Thank you.

 

UPDATE: So I restarted the server again and tried a manual backup again and it seemed to work without issue.  Still would like to know what the degug log reported as to an issue.  Pondering.

 

David

Edited May 4, 20251 yr by David Bott

2 hours ago, David Bott said:

 (I can find no TMP directory anywhere.) 

 

/tmp/appdata.backup/

 

They'll be gone if you rebooted though, so copy straight away if you have an error again.

So I'm having a weird issue... I noticed a bunch of failed backups so I was trying to troubleshoot and started a manual backup last night. Looked at the logs and everything seemed to be running as expected.

 

When I went to verify that the backup completed properly this morning I found that it was still running. Tried to abort it and that didn't seem to have any effect. I even uninstalled and reinstalled the plugin, set it up again, started a new manual backup and when I went to the log screen it does indicate that it's running but still shows the same logs that were present before uninstall/reinstall. No new information is being logged. Again, aborting doesn't seem to have any effect.

Hm. What was the last log line before you first tried to cancel it?

@Kilrah your post regarding misbehaved restore is gone? Did you found the issue?

On 5/4/2025 at 4:12 PM, David Bott said:

Still would like to know what the degug log reported as to an issue

Your docker service had an issue. Any stop or start command failed with:

 

stream_socket_client(): Unable to connect to unix:///var/run/docker.sock (Connection refused) /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php:725

 

so a reboot should sort this out.

1 hour ago, KluthR said:

@Kilrah your post regarding misbehaved restore is gone? Did you found the issue?

Yeah it was my fault, I filled up the destination without looking thinking it was the source for some stupid reason...

Am I doing something wrong?

 

I'm having a situation wherein I am backing up my flash to a custom folder but it doesn't look like the script is including the flash in it's retention check. 

 

I noticed today because I am moving the flash backups to a cloud provider and I keep going over my space. When I checked the flash backup folder it had backups going back to early last year even though my retention is to keep backups for two weeks.

 

Is there another retention setting for the flash backup or, perhaps, this is because I am copying the flash to another folder?

 

Any suggestions as to what I might need to change? I can see that the retention is being check according to the logs and it's certainly cleaning up the appdata backup.

1 hour ago, jjross said:

but it doesn't look like the script is including the flash in it's retention check. 

Thats right. 
 

Personally I include the flash backup inside the normal backup folder. Retention deletes this flash backup as well. But custom locations are out of its scope.

In the last two days, my Appdata Backups fails with an error message.

Before, it was working fine, nothing changed to the immich compose, so I am not really sure where this is coming from?

Maybe you guys have any hints?

 

Appdata Backup fails at this point:

 

[10.05.2025 03:25:56][❌][immich_machine_learning] 'immich_model-cache' does NOT exist! Please check your mappings! Skipping it for now.
[10.05.2025 03:25:56][ℹ️][immich_machine_learning] Should NOT backup external volumes, sanitizing them...
[10.05.2025 03:25:56][⚠️][immich_machine_learning] immich_machine_learning does not have any volume to back up! Skipping. Please consider ignoring this container.

 

 

My compose has a volume mapping

 

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-openvino
    volumes:
      - /dev/bus/usb:/dev/bus/usb
      - model-cache:/cache

 

The volume itself is available on the host

root@cloud:~# docker volume inspect immich_model-cache
[
    {
        "CreatedAt": "2025-01-11T15:26:28+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "immich",
            "com.docker.compose.version": "2.29.2",
            "com.docker.compose.volume": "model-cache"
        },
        "Mountpoint": "/var/lib/docker/volumes/immich_model-cache/_data",
        "Name": "immich_model-cache",
        "Options": null,
        "Scope": "local"
    }
]
root@cloud:~# ls -la "/var/lib/docker/volumes/immich_model-cache/_data"
total 4
drwxr-xr-x 4 root root 4 Feb  5 16:36 ./
drwx-----x 3 root root 3 Jan 11 15:26 ../
drwxr-xr-x 3 root root 3 Feb  5 16:36 clip/
drwxr-xr-x 3 root root 3 Feb  5 16:36 facial-recognition/

 

In the settings, there is no immich_model-cache volume specified nor deselectable

 

Edited May 10, 20251 yr by mil4N

Yes. Named volumes are not supported at this moment. Only bind-mounts.

 

this issue must be there for more than two days. Except this machine learning is new.

Edited May 10, 20251 yr by KluthR

Need help resolving backup error. Seems to be failing most of the time but I did not know. Have not gotten any notifications but I happened to test restoring a backup today..

 

log id ce24cff1-f045-4c52-8e3a-4eabe2eed25a