kaymer327

I'm having problems with the exclude functionality also... I thought it was working previously, but I honestly haven't checked on it in a while... [11.07.2025 05:02:28][debug][plex] Generated tar command: --exclude 'Cache,Metadata,Media,MediaCover,models/blobs' -c -P -f '/mnt/user/backup/unraid/ab_20250711_050001/plex.tar' '/mnt/user/appdata/plex' When Appdata Backup runs, plex.tar is 27GB When I run it manually adding -v, I confirm that the dirs are added. I also confirm that they exist in the output tar with -tvf... I tried manually running like this: tar --exclude 'Media' --exclude 'Cache' --exclude 'Caches' --exclude 'Metadata' -c -v -P -f '/mnt/user/backup/unraid/test_plex.tar' '/mnt/user/appdata/plex' and my output tar file is only 2.7 GB.

I was having the "[warn] Failed to bring 'up' WireGuard kernel implementation" issue with :latest, I had to rollback to 5.1.1-1-01, tested with :test per above and it's working properly so far... Thanks!

Understood... I'll go a different route then - I'll schedule this as a user script to run 5 minutes before my scheduled back up. problem solved. Thanks!

So referencing my previous post: Setting the "Path To Custom Pre-start Script:" didn't work as expected... [03.02.2023 05:00:45] Backing Up /usr/bin/tar: ./binhex-qbittorrentvpn/qBittorrent/config/ipc-socket: socket ignored [03.02.2023 05:02:48] Verifying Backup ./binhex-qbittorrentvpn/qBittorrent/config/qBittorrent.conf: Mod time differs ./binhex-qbittorrentvpn/qBittorrent/data/logs/qbittorrent.log: Mod time differs ./binhex-qbittorrentvpn/qBittorrent/data/logs/qbittorrent.log: Size differs [03.02.2023 05:04:52] tar verify failed! [03.02.2023 05:04:52] done [03.02.2023 05:04:52] Executing custom pre-start script /mnt/user/data/scripts/backup-pre-start My script kicked off successfully and killed the target processes as expected... Just a bit too late.. Looks like it's pre-start of dockers, not pre-start of backup as I was expecting/assuming. I couldn't find any documentation confirming what it's supposed to be, but from the code, looks like it's a pre-start of dockers: https://github.com/Commifreak/ca.backup2/blob/master/source/ca.backup2/usr/local/emhttp/plugins/ca.backup2/scripts/backup.php#L323 I haven't touched php in a minute and don't have a good way to test, so I'd be hesitant to submit a PR, but anyway to get a pre-backup-start script option added in?

I was running into the common backup error related to dockers. Came to this thread for some research. Found a lot of people that weren't stopping all dockers - that's not my case as I am in fact stopping all dockers... So I was poking around a bit more and testing... For the record here are the errors that I ran into: [27.01.2023 05:04:31] Verifying Backup ./binhex-qbittorrentvpn/qBittorrent/config/qBittorrent.conf: Mod time differs ./binhex-qbittorrentvpn/qBittorrent/data/logs/qbittorrent.log: Mod time differs ./binhex-qbittorrentvpn/qBittorrent/data/logs/qbittorrent.log: Size differs [27.01.2023 05:06:36] tar verify failed! Last successful backup (scheduled weekly, Friday's, 5AM) was Dec 9th. While manually running a backup, confirming that all dockers remained down via the web UI (they did) - it still failed. So I did it again and ran ps -ef | grep -i qb while the back up was running... Found this guy: root 19499 1 0 2022 ? 00:00:02 /usr/bin/ttyd -d0 -t disableLeaveAlert true -t theme {'background':'black'} -t fontSize 15 -t fontFamily monospace -i /var/tmp/binhex-qbittorrentvpn.sock docker exec -it binhex-qbittorrentvpn bash bingpot! Killed that process, re-ran and I've got successful backups again. Looks like this process is from opening the console to that docker from the UI. I'm able to reproduce this hanging process - typing "exit" in the console windows just re-opens a new shell. Closing the browser window seems to be the only way to "close" it - but the process remains. The following command will kill all running docker exec commands - but may potentially be too greedy depends on your specific needs - good enough for what I do though: ps -ef | grep -i "docker exec -it" | grep -v grep | awk '{print $2}' | xargs kill I will likely be putting this command in a pre-start script. Thought I post here in case anyone is having similar problems.

I had a kernel panic last night as well. Was stable on 6.8.3 since it was released. My Flash drive went bad around the time of/during the 6.9.1 upgrade - I had replacement waiting since I've had that flash drive for a while. Replaced it with one of spaceinvaderone's recommendations (SAMSUNG BAR Plus). And all was fine for about a week. Syslog doesn't seem to have any details in it from prior to the restart to recover from the panic. Any suggestions for ensuring that logging is retained in such a scenario? Syslog server? While I understand that hardware can and does go bad - the catalyst here was the 6.9.1 upgrade. Other users are reporting similar experiences (6.8.x stable, 6.9.x kernel panics) here in the forums as well as on Reddit: https://www.reddit.com/r/unRAID/comments/m5n0za/kernel_panic_help_happens_every_few_days/ https://www.reddit.com/r/unRAID/comments/m3ncd5/weird_crash_and_lost_all_appdata/ https://www.reddit.com/r/unRAID/comments/m3n0wv/nextcloud_docker_not_working_after_crash/ So seems more like a software issue than a hardware one with multiple users reporting. Thanks for any assistance!