44 minutes ago, morphodone said:

Need help resolving backup error

 

code-server is using servarr as volume path which contains many other container appdata. I think excluding it in its advanced container settings should do the trick.

Have another error... please see.

 

626d1b04-33be-47d7-b965-0187fc522425

On 5/10/2025 at 11:19 AM, KluthR said:

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.

Before, the named volume wasn't even taken into account:

[07.05.2025 03:27:37][][immich_machine_learning] Should NOT backup external volumes, sanitizing them...
[07.05.2025 03:27:37][][immich_machine_learning] immich_machine_learning does not have any volume to back up! Skipping. Please consider ignoring this container.

Nevertheless, how to properly exluce those from backup then? 

Set the container to 

 

Skip backup? Only stop/start

 => Yes, skip backup and do stop/start only 

 

Still, the error was thrown.

[13.05.2025 03:24:39][❌][immich_machine_learning] 'immich_model-cache' does NOT exist! Please check your mappings! Skipping it for now.
[13.05.2025 03:24:40][ℹ️][immich_machine_learning] Should NOT backup this container at all. Only include it in stop/start. Skipping backup...

 

@KluthR

where do i find the log files (this log is just from a manuall backup, i can't find the backup specific one's, if they exist)? i have backups with -failed at the end and there is no logfile attached to that failed backups.

or is it just because of those warnings:

 

 

 

 

Edited May 15, 20251 yr by Holle88

No. Those warnings do not let them fail

 

the log should be copied over to those directories. Nothing in there? What is inside of those failed ones?

the manual backup just worked fine which i did yet and with ERROR that the VM XML could not be read ( which is clear, because i stopped VM service which mount the libvirt to my libvirt.img which then there is no access).

 

but it (the manual backup i did now) is also not marked as failed anyway.

 

there is no logfile contained in the directories (there is just a config.json with the backupsettings itself).

 

the backups itself looks intact (this is one of the "failed" one's)

Edited May 15, 20251 yr by Holle88

Then please disable VM XML backup setting

but that's what i am telling you: it is not the issue and also in the failed one's the VM metadata is perfectly backed up. the Error was now only on the manual backup because the virths VM service was not running AND it is NOT marked as failed....

Edited May 15, 20251 yr by Holle88

Hi, does anybody know of a way to disabled docker containers and appdata backup? These are already on a synced zfs volume. I would like to only backup the flash drive and the vm config data.

Things I have tried already:
- Just disable a specific container backup. -> I add remove containers every day. There is no "new containers do no backup" option.
- Disable container shutdown. -> Works.
- Leave appdata path empty. -> This is not allowed.
- Add appdata path but also add the same path to the global exclusion list. -> Tar verify errors.

Any help would be much appreciated!

@Holle88 Ill check why the log is not included. Even if the backup fails, the log should be included. Hm

15 minutes ago, SixFive7 said:

Any help would be much appreciated!

Hm. There is no such option, maybe I add it in future updates. Should be no big deal.

 

but you can skip tar verify at global scope in global advanced options for now.

18 minutes ago, KluthR said:

Hm. There is no such option, maybe I add it in future updates. Should be no big deal.

 

but you can skip tar verify at global scope in global advanced options for now.

 

I now have:
- Included appdata path.
- Global exclusion on same appdata path.
- Notifications on warnings disabled.
- Tar verify disabled.
- Disable container shutdown enabled.

This seems to work. Thank you!
If you'd consider a "What do you want to backup?" list of checkboxes (vms, containers, flash, etc) for the someday maybe future, that would be beyond all expectations.
Thank you for thinking through this workaround with me 🙂

On 5/8/2025 at 12:57 PM, KluthR said:

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.

 

OK, so retention doesn't work on custom paths? Sounds good, I'll need to move my flash backup to the default location. Any chance we could add a tooltip or something to the plugin to make that clear?

Does anyone have a post-run script that will automatically zip up a given backup into a single file and delete the folder, leaving only the archive? I want each backup to be a single file. I searched the thread a bit and saw several people asking for this over the years, but I couldn't find an actual script to do it.

Also, will such a script interfere with the plugin's ability to clean up old backups? If so, how can I avoid this issue?

 

The end result I want is for 3 days of backups to be kept, with each backup being a single archive file.

I tried to ask ChatGPT to write one, but it completely failed to do so.

 

Alternatively, if someone could point me to documentation about scripts (e.g., I saw a post saying there is variable support to target backup directories directly, but did not see documentation listing variables, etc.) that would be helpful too.

 

EDIT

Looks like ChatGPT was able to pull it off after all! This is working for me. I'll include it here in case anyone else wants something like this. You'll need to change the log file directory to be wherever you want it, though, and change 3 days to whatever you want as well.

#!/bin/bash

# Accept input from plugin
ARCHIVE_FOLDER="$2"

# Log file
LOG_FILE="/mnt/user/Backups/post_backup_debug.log"
echo "[$(date)] ARCHIVE_FOLDER=$ARCHIVE_FOLDER" >> "$LOG_FILE"

# Safety check
if [ -z "$ARCHIVE_FOLDER" ]; then
    echo "[$(date)] ❌ ARCHIVE_FOLDER not set" >> "$LOG_FILE"
    exit 1
fi

# Zip destination
ZIP_DEST=$(dirname "$ARCHIVE_FOLDER")
BASE_NAME=$(basename "$ARCHIVE_FOLDER")
ZIP_PATH="$ZIP_DEST/${BASE_NAME}.zip"

# Create zip
zip -r "$ZIP_PATH" "$ARCHIVE_FOLDER"

# Delete original folder if zip succeeded
if [ $? -eq 0 ]; then
    rm -rf "$ARCHIVE_FOLDER"
    echo "[$(date)] ✅ Zipped and deleted $ARCHIVE_FOLDER" >> "$LOG_FILE"
else
    echo "[$(date)] ❌ Zip failed for $ARCHIVE_FOLDER" >> "$LOG_FILE"
    exit 1
fi

# Retention: Only delete zips with Appdata format older than 3 days
find "$ZIP_DEST" -type f -name "ab_[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_[0-9][0-9][0-9][0-9][0-9][0-9].zip" -mtime +3 \
  -exec rm -f {} \; \
  -exec echo "[$(date)] 🧹 Deleted matching zip: {}" >> "$LOG_FILE" \;

exit 0

 

Edited May 17, 20251 yr by andell
chatgpt made a script

Is there anything about Appdata backup running that could be causing a unassigned drive to drop out of system?
 

I know this sounds crazy but not sure where else to turn/to look at?

 

Here and a few posts down diagnostics can be found. All weekend Appdata backups were NOT scheduled and Unassigned disk never dropped; backups were scheduled middle of the night and the disk dropped:
 

 

2 hours ago, blaine07 said:

Is there anything about Appdata backup running that could be causing a unassigned drive to drop out of system?

No. As it does not interact with the system on that level.

On 5/15/2025 at 1:25 PM, KluthR said:

@Holle88 Ill check why the log is not included. Even if the backup fails, the log should be included. Hm

that would be nice for debugging, thxs mate. if you need further information (system, filesystem, user-rights, etc.) feel free to ask.

Edited May 20, 20251 yr by Holle88

Since a few days I'm getting this error: 

[18.05.2025 04:46:57][❌][Jellyfin] tar verification failed! Tar said: tar: Removing leading `/' from member names; mnt/user/appdata/Jellyfin/plugins/Trakt_26.0.0.0/meta.json: Mod time differs; mnt/user/appdata/Jellyfin/plugins/Trakt_26.0.0.0/jellyfin-plugin-trakt.png: Mod time differs; mnt/user/appdata/Jellyfin/plugins/Kodi Sync Queue_14.0.0.0/meta.json: Mod time differs; mnt/user/appdata/Jellyfin/plugins/Kodi Sync Queue_14.0.0.0/jellyfin-plugin-kodisyncqueue.png: Mod time differs; mnt/user/appdata/Jellyfin/plugins/Playback Reporting_16.0.0.0/meta.json: Mod time differs; mnt/user/appdata/Jellyfin/plugins/Playback Reporting_16.0.0.0/jellyfin-plugin-playbackreporting.png: Mod time differs

Is there something I can do to fix this? It's giving me errors every time I backup.

As usual, make sure that if containers share a folder they're all stopped together using the group feature.

No folders are shared, that's the first thing I checked.

@KluthR nvm: the manual backup i did, fixed all my problems: backups not marked as failed anymore, i can see the log from the last automated backup in the browser log and there is now a logfile in the backupdir.

 

so i have not changed anything in settings just done the manual backup and everything is working properly in automated backups now again.

it looks like the manual backup has reset some value or variable that caused the problem. just wanted to let you know.

I'm trying to get the global exclusions working, but I had some issues, copying the ones in the example didn't work.

I eventually figured it out - while the example says to format it like this:

logs, log, *.png, .cache (etc etc, using comma and space to break up each one)

This doesn't actually work. It only works if you put each entry in a new line.

I assume this is a new change, as the per-container exclusions seem to work that way (new lines) by default (if you manually select the folders with the file-browser) so I guess the example text didn't get updated (?)

Edit:
I'll also add that because of the way the text box works, it currently also means that when you load the settings page it only shows the first two entries and doesn't indicate that there are a whole bunch more (you have to manually enlarge the text box to see them). I don't know if this is an unraid limitation or not, but if there's a way to fix it then it would be better!

Edited May 22, 20251 yr by Nirin

There is a new BETA.

It includes fixes for TailScale and includes the settings-form-does-not-save fix.

Please test and report back.

One minor suggestion - Shouldn't default ordering of containers be the same as what is the docker tab rather than just alphabetical

Ive reported the padding with zeroes error before for Chrome, Im now getting it for PhotoPrism also.

Woudl be great if this can be looked at as it appears in this forum for a while already.

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

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

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

Its worth noting Ferdium and Chrome are not even running in the first place...