On 11/21/2024 at 11:36 PM, KluthR said:

Your previous screenshot shows the issue during backup: the oom-killer was kicking in. The ram was full resulting in killing docker (and system?) processes.

 

Thats another issue you have to look at. Something is eating the ram during docker container starts?

I have the same issue with crashing during the weekly backup. First observed on my weekly backup on 11/4/2024. The process that eventually consumes all memory and causes the OOM is shfs. I'll try comparing the settings with debug, and maybe try running it live where I can try to see what is causing shfs to consume so much memory.

On 12/9/2024 at 11:01 AM, Kilrah said:

Yes, or put it as exlcuision under each container that has it separately. First is easier obviously.

That is not working!

 

The Log ID: ecb89b2c-77e1-4709-abf6-04b479d47422

Edited December 18, 20241 yr by Revan335

A good Feature for Tests.

Only Backup on Docker Container.

Can we became an Option for this in the Feature?

Actually we deactivated/ignored any other Docker Containers.

A Button for Backup only this Docker Container was much easier.

On 12/10/2024 at 6:16 AM, Fribb said:

I currently have an issue in which my backups fail because, from what I can tell, the verification of the backup of some docker containers fails. This isn't exclusive to certain containers but rather happens with a bunch of them, one day one fails, the next day everything works fine, another day some other fails. 

 

But whenever it fails, it is always the same process, here is an example:

 

First, it tries to stop the container which, for some reason, doesn't work

[10.12.2024 00:10:02][ℹ️][plex] Stopping plex... Error while stopping container! Code: Container already started - trying 'docker stop' method
[10.12.2024 00:10:02][ℹ️][plex] That _seemed_ to work.

 

then it does the backup and the TAR verification fails

[10.12.2024 00:42:59][ℹ️][plex] Should NOT backup external volumes, sanitizing them...
[10.12.2024 00:42:59][ℹ️][plex] Calculated volumes to back up: /mnt/user/appdata/plex
[10.12.2024 00:42:59][ℹ️][plex] Backing up plex...
[10.12.2024 01:15:30][ℹ️][plex] Backup created without issues (took 00:32:31 (hours:mins:secs))
[10.12.2024 01:15:30][ℹ️][plex] Verifying backup...
[10.12.2024 01:22:46][❌][plex] tar verification failed! ...
[10.12.2024 01:24:31][ℹ️][plex] Installing planned update for plex...

 

I don't know why the stopping of the container would fail since there is no error being logged.

However, it seems that the verification failed because the backup was done while the container was running. At least that is what I am guessing because the verification failed and also states "Contents differ".

 

I also tried to help the plugin out by stopping all running containers in a pre-run script but with the command listed below, it says the following log message.

#! /bin/bash
docker stop $(docker ps -a -q)

 

[10.12.2024 00:00:02][ℹ️][Main] Executing script '/mnt/user/appdata/pre-run-backup.sh' 'pre-run' '/mnt/user/system-backup/appdata/ab_20241210_000002'...
[10.12.2024 00:00:02][ℹ️][Main] Script executed!
[10.12.2024 00:00:02][⚠️][Main] Script did not returned 0 (it returned 127)!

 

Which, to my knowledge, that return code 127 means that it is a "command not found". I mean the command itself runs without issues, I also have executed the script manually and it does what it is supposed to do without issues. How can the docker command not be found? Is the script executed in some way that some basic Unraid parts are not available? 

 

This whole thing raises some questions for me:

• Why is the log message "Container already started" when there is a log message of "stopping the container"?
• Apparently, the "docker stop" command never works (for me) even though it says that it "seems to work". (there is no restart=always or anything like that on the docker container). If this isn't "docker stop" that is attempted here, what is being used here to stop the containers?
• Why is a simple pre-run script with "docker stop" returning 127 instead of 0 even though I can execute it just fine manually?

 

Because of this, My backup has failed for 4 days in a row. Is there any solution?

Out of the blue I get this error that its not available now. I haven't touched settings at all, it just has always worked correcly. Any idea what's going on?

Seems like an GitHub error. The plugin infos comes directly from GitHub repository.

Thank you for this wonderful plugin that I've been using for years! I just noticed today that the backup folder contains a lot of my-*.bak files.

 

I guess these are old container configurations? The names speak to me. How can I exclude/delete these files from the backups?

 

Thank you

 

Edited December 23, 20241 yr by Alex.b

You are right

 

and you cannot exclude them for now.

5 hours ago, KluthR said:

You are right

 

and you cannot exclude them for now.

Duly noted! Thanks for the reply.

19 hours ago, Alex.b said:

I guess these are old container configurations? The names speak to me. How can I exclude/delete these files from the backups?

Delete them manually from the flash drive in /boot/config/plugins/DockerMan/templates-user

I noticed my weekly appdata backup was suddlenly HUGE 133gb per backup in size and it appears that the backup and restore appdata plugin is not ignoring the requested folders in Plex, its backing them up anways. Is this currently bugged?

Debug ID: 65e268a4-e3b3-457f-9909-2c259253839a

37 minutes ago, widowshyper said:

I noticed my weekly appdata backup was suddlenly HUGE 133gb per backup in size and it appears that the backup and restore appdata plugin is not ignoring the requested folders in Plex, its backing them up anways. Is this currently bugged?

Debug ID: 65e268a4-e3b3-457f-9909-2c259253839a

I did have to cancel the plex backup as I already left a backup running overnight which took an hour and a half to complete.

No bug known. I have to check the debug log tomorrow.

Hello All, I use the Appdata Backup plugin and was trying to restore my home assistant VM data, but cant seem to get it working. when I run restore, the VM is still missing. so I installed the VM from scratch and wanted to load the backup, but HA is asking for a .tar file, which the backup doesnt seem to have...

VMs are not being backed up. Only the metadata of the VM.

Hi all, running into an issue recently that I have neglected for too long and need to actually fix. I get an error from during the backup for my Plex Media Server container. It says "tar creation failed" it lists the path and then says "the file shrank by xxxx bytes; padding with zeroes." I have shared the debug log through the tool. Here is my debug ID: ef0ea819-254d-459a-91aa-0faac9dffd0c

Are all containers using the Plex volume in one group?

 

Those errors normally mean that some other process is accessing the file. No general solution known for this if nothing is accessing the path during backup

Yeah the plex docker volume should only be used by the Plex container as far as I know.  Any suggestions on how to figure out what would be accessing that path?

Nothing is accessing the path.

 

The debug log does not show anything accessing this path. Not clear what tar's issue here is.

Hi all, I'm a bit stuck with an issue where tar verification fails for 2 of my containers. it also seems that it's not creating any backup of those containers as in the logs just before the failed tar verification it sais : "[Duplicacy] backup created without issues (took 00:00:00(hours:mins:secs))" which seems fishy to me.

 

I don't know where to find the logs to share other than copy pasting the log available in the plugin's status/logs tab here's a run where i set the problematic plugins as first to run and then cancelled the backup process after they had failed:

 

[29.12.2024 10:24:54][ℹ️][Main] 👋 WELCOME TO APPDATA.BACKUP!!
[29.12.2024 10:24:54][ℹ️][Main] Backing up from: /mnt/user/appdata
[29.12.2024 10:24:54][ℹ️][Main] Backing up to: /mnt/user/backups/appdata/ab_20241229_102454
[29.12.2024 10:24:54][ℹ️][Main] Selected containers: Duplicacy, Nginx-Proxy-Manager-Official, PostgreSQL_Immich, Thunderbird, foldingathome, homer, immich, jellyfin, jellyseerr, mariadb, minecraftbasicserver, nextcloud, pihole-unbound, protonmail-bridge, prowlarr, qbittorrentvpn, radarr, sonarr, vaultwarden
[29.12.2024 10:24:54][ℹ️][Main] Saving container XML files...
[29.12.2024 10:24:55][ℹ️][Main] Method: Stop/Backup/Start
[29.12.2024 10:24:55][ℹ️][Duplicacy] Stopping Duplicacy... done! (took 0 seconds)
[29.12.2024 10:24:55][ℹ️][Duplicacy] '/mnt/user/appdata/Duplicacy/logs' is within mapped volume '/mnt/user/appdata/Duplicacy'! Ignoring!
[29.12.2024 10:24:55][ℹ️][Duplicacy] Should NOT backup external volumes, sanitizing them...
[29.12.2024 10:24:55][ℹ️][Duplicacy] Calculated volumes to back up: /mnt/user/appdata/Duplicacy
[29.12.2024 10:24:55][ℹ️][Duplicacy] Backing up Duplicacy...
[29.12.2024 10:24:55][ℹ️][Duplicacy] Backup created without issues (took 00:00:00 (hours:mins:secs))
[29.12.2024 10:24:55][ℹ️][Duplicacy] Verifying backup...
[29.12.2024 10:24:55][❌][Duplicacy] tar verification failed! Tar said: tar: /mnt/user/appdata/Duplicacy: Not found in archive; tar: Exiting with failure status due to previous errors
[29.12.2024 10:24:58][ℹ️][Duplicacy] Starting Duplicacy... (try #1) done!
[29.12.2024 10:25:01][ℹ️][qbittorrentvpn] Stopping qbittorrentvpn... done! (took 2 seconds)
[29.12.2024 10:25:03][ℹ️][qbittorrentvpn] Should NOT backup external volumes, sanitizing them...
[29.12.2024 10:25:03][ℹ️][qbittorrentvpn] Calculated volumes to back up: /mnt/user/appdata/qbittorrentvpn
[29.12.2024 10:25:03][ℹ️][qbittorrentvpn] Backing up qbittorrentvpn...
[29.12.2024 10:25:03][ℹ️][qbittorrentvpn] Backup created without issues (took 00:00:00 (hours:mins:secs))
[29.12.2024 10:25:03][ℹ️][qbittorrentvpn] Verifying backup...
[29.12.2024 10:25:03][❌][qbittorrentvpn] tar verification failed! Tar said: tar: /mnt/user/appdata/qbittorrentvpn: Not found in archive; tar: Exiting with failure status due to previous errors
[29.12.2024 10:25:07][ℹ️][qbittorrentvpn] Starting qbittorrentvpn... (try #1) done!
[29.12.2024 10:25:10][ℹ️][Nginx-Proxy-Manager-Official] Stopping Nginx-Proxy-Manager-Official... done! (took 5 seconds)
[29.12.2024 10:25:15][ℹ️][Nginx-Proxy-Manager-Official] Backing up the flash drive.
[29.12.2024 10:25:22][❌][Nginx-Proxy-Manager-Official] Flash backup failed: no answer from script!
[29.12.2024 10:25:24][⚠️][Main] Backup cancelled! Executing final things. You will be left behind with the current state!
[29.12.2024 10:25:28][ℹ️][Main] DONE! Thanks for using this plugin and have a safe day
[29.12.2024 10:25:28][ℹ️][Main] ❤️

 

thanks for any help I can get

Michael

Check those folders actually have content? That's what you'd get if they're simply empty.

Edited December 29, 20241 yr by Kilrah

4 hours ago, Kilrah said:

Check those folders actually have content? That's what you'd get if they're simply empty.

had a look and they do have stuff in them, not much but 90MB and 16MB with files and not just empty folders

Any exclusions set?

Hello @KluthR 

Since around mid-November, I've been struggling with server crashes during appdata backups. Going through this thread, I've noticed at least two similar situations since November.

 

From my observations, it doesn't matter which container is being backed up - it crashes randomly. While trying to understand this better yesterday, even when I pressed "Manually Run Backup" and then stopped it to check something, the server crashed anyway. So there must be some kind of process initiated at the beginning that causes a memory leak or something else.

 

Do you have any ideas what to check and where I should start?

Additional information: I ran htop and sorted by memory usage. I noticed a bunch of /usr/bin/dockerd processes were slowly eating up the memory until the server crashed. I didn't want my server to crash, so I went to settings and disabled Docker before it happened. After that, the memory was freed up, and I was able to enable Docker again.I tried changing the method to stop all containers, perform a backup, and start them again, but this didn't help either. I also disabled the USB Flash backup, but this didn't resolve the issue.