Anym001

Ah I see. swag backups contents of Jellyfin, maybe you want to exclude them (/mnt/cache/appdata/Jellyfin/log) as well as the other container mappings (vaultwarden?). I have now tried to exclude the affected mappings. Unfortunately I still get an error message. The tar verifications failed again. Debug log attached [17.04.2023 20:57:45][debug] Backup swag - Container Volumeinfo: Array ( [0] => /mnt/cache/appdata/swag:/config:rw [1] => /mnt/cache/appdata/Jellyfin/config/log/:/var/log/jellyfin/:ro [2] => /mnt/cache/appdata/nextcloud/log/:/var/log/nextcloud/:ro [3] => /mnt/cache/appdata/vaultwarden/vaultwarden.log:/var/log/vaultwarden/vaultwarden.log:ro ) [17.04.2023 20:57:45][debug] Should NOT backup ext volumes, sanitizing them... [17.04.2023 20:57:45][debug] Volume '/mnt/cache/appdata/swag' IS within AppdataPath '/mnt/cache/appdata'! [17.04.2023 20:57:45][debug] Volume '/mnt/cache/appdata/Jellyfin/config/log' IS within AppdataPath '/mnt/cache/appdata'! [17.04.2023 20:57:45][debug] Volume '/mnt/cache/appdata/nextcloud/log' IS within AppdataPath '/mnt/cache/appdata'! [17.04.2023 20:57:45][debug] Volume '/mnt/cache/appdata/vaultwarden/vaultwarden.log' IS within AppdataPath '/mnt/cache/appdata'! [17.04.2023 20:57:45][debug] Final volumes: /mnt/cache/appdata/swag, /mnt/cache/appdata/Jellyfin/config/log, /mnt/cache/appdata/nextcloud/log, /mnt/cache/appdata/vaultwarden/vaultwarden.log [17.04.2023 20:57:45][debug] Target archive: /mnt/user/backup/appdatabackup/ab_20230417_205409/swag.tar.gz [17.04.2023 20:57:45][debug] Container got excludes! /mnt/cache/appdata/Jellyfin/config/log /mnt/cache/appdata/nextcloud/log /mnt/cache/appdata/vaultwarden/vaultwarden.log [17.04.2023 20:57:45][debug] Generated tar command: --exclude '/mnt/cache/appdata/vaultwarden/vaultwarden.log' --exclude '/mnt/cache/appdata/nextcloud/log' --exclude '/mnt/cache/appdata/Jellyfin/config/log' -c -P -z -f '/mnt/user/backup/appdatabackup/ab_20230417_205409/swag.tar.gz' '/mnt/cache/appdata/swag' '/mnt/cache/appdata/Jellyfin/config/log' '/mnt/cache/appdata/nextcloud/log' '/mnt/cache/appdata/vaultwarden/vaultwarden.log' [17.04.2023 20:57:45][info] Backing up swag... [17.04.2023 20:57:51][debug] Tar out: [17.04.2023 20:57:51][info] Backup created without issues [17.04.2023 20:57:51][info] Verifying backup... [17.04.2023 20:57:51][debug] Final verify command: --exclude '/mnt/cache/appdata/vaultwarden/vaultwarden.log' --exclude '/mnt/cache/appdata/nextcloud/log' --exclude '/mnt/cache/appdata/Jellyfin/config/log' --diff -f '/mnt/user/backup/appdatabackup/ab_20230417_205409/swag.tar.gz' '/mnt/cache/appdata/swag' '/mnt/cache/appdata/Jellyfin/config/log' '/mnt/cache/appdata/nextcloud/log' '/mnt/cache/appdata/vaultwarden/vaultwarden.log' [17.04.2023 20:57:52][debug] Tar out: tar: Removing leading `/' from member names; tar: /mnt/cache/appdata/Jellyfin/config/log: Not found in archive; tar: /mnt/cache/appdata/nextcloud/log: Not found in archive; tar: /mnt/cache/appdata/vaultwarden/vaultwarden.log: Not found in archive; tar: Exiting with failure status due to previous errors [17.04.2023 20:57:52][error] tar verification failed! More output available inside debuglog, maybe. [17.04.2023 20:57:52][debug] lsof(/mnt/cache/appdata/swag) Array ( ) [17.04.2023 20:57:52][debug] lsof(/mnt/cache/appdata/Jellyfin/config/log) Array ( ) [17.04.2023 20:57:52][debug] lsof(/mnt/cache/appdata/nextcloud/log) Array ( ) [17.04.2023 20:57:52][debug] lsof(/mnt/cache/appdata/vaultwarden/vaultwarden.log) Array ( ) [17.04.2023 20:57:52][debug] AFTER verify: Array ( [Image] => linuxserver/swag:latest [ImageId] => a51e6e60de2c [Name] => swag [Status] => Exited (0) 3 minutes ago [Running] => [Paused] => [Cmd] => /init [Id] => ff1513d2b608 [Volumes] => Array ( [0] => /mnt/cache/appdata/swag:/config:rw [1] => /mnt/cache/appdata/Jellyfin/config/log/:/var/log/jellyfin/:ro [2] => /mnt/cache/appdata/nextcloud/log/:/var/log/nextcloud/:ro [3] => /mnt/cache/appdata/vaultwarden/vaultwarden.log:/var/log/vaultwarden/vaultwarden.log:ro ) [Created] => 5 hours ago [NetworkMode] => proxynet [CPUset] => [BaseImage] => [Icon] => https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/linuxserver-ls-logo.png [Url] => https://[IP]:[PORT:443] [Shell] => [Ports] => Array ( [0] => Array ( [IP] => [PrivatePort] => 443 [PublicPort] => 4443 [NAT] => 1 [Type] => tcp ) [1] => Array ( [IP] => [PrivatePort] => 80 [PublicPort] => 4480 [NAT] => 1 [Type] => tcp ) ) ) ab.debug.log

Here is a screenshot of the unloaded Docker icons.

Sorry i posted the wrong debug log above. Here is the current debug log, where the problems with duplicacy and jellyfin have been fixed. Error for swag remains. ab.debug.log

I solved this problems with die jellyfin and Duplicacy Container but not for the swag one. Is there any solution for this or should I wait for the future version?

Please show the debug log. backup.debug.log

I have an error in the backup log because of the volume mapping too. (SWAG Container) My volume mappings: /config -> /mnt/cache/appdata/swag /var/log/nextcloud/ -> /mnt/cache/appdata/nextcloud/log/ /var/log/jellyfin/ -> /mnt/cache/appdata/Jellyfin/config/log/ /var/log/vaultwarden/vaultwarden.log -> /mnt/cache/appdata/vaultwarden/vaultwarden.log Is there a way to do these mappings without getting an error message?

Es ist gerade eine V3 in Vorbereitung. https://forums.unraid.net/topic/132721-plugin-ca-appdata-backup-restore-v25/?do=findComment&comment=1243366

Samsung 970 Evo Plus 2TB im Angebot bei Amazon: https://www.amazon.de/dp/B07MLJD32L?linkCode=xm2&camp=2025&creative=165953&smid=A3JWKAKR8XB7XF&creativeASIN=B07MLJD32L&tag=geizhals1-21&ascsubtag=7x0TWUPXsP0Pvfex1smaHQ

Im Anhang die Ausleitung vom zfs list command. Die besagten Shares sind leider nicht vorhanden. Also so wie ich es verstehe, sollten alle Verzeichnisse und Pools bei diesem Befehl aufgelistet werden. Mein Pool „Cache“ ist unter /mnt/cache gemountet und darin befinden sich die Shares lt. ls-Ausgabe. Darum wundert es mich, dass zfs list nicht alle ausgibt. zfs-list.txt

Siehst du ja auch. Aber nicht alle. zB Nextcloud, Paperless, usw. nicht, obwohl auch in dem Pool vorhanden. Versteh ich trotzdem leider nicht ganz. Weil sollte zfs list nicht den kompletten Inhalt des Pools darstellen? Bei meinem Beispiel stellt er ja nur einen Teil dar. Das verwirrt mich ein wenig.

Hey, ich hätte da mal eine Verständnisfrage. Ich hab unter /mnt/cache etliche Shares liegen. (Siehe Screenshot) Wenn ich dann „zfs list“ mache, müsste ich ja diese Shares dann sehen oder nicht? Hier werden nur einige davon angezeigt. Und interessanterweise etliche Ordner aus /mnt/cache/system Ist das normal?

I upgraded to 6.12 RC2 and get the following message in the CA Store. Is this plugin really not compatible anymore? Is there a new version here?

Ja, sogar in zwei verschiedenen externen Safes. Wie genau macht ihr das? Nochmal komplettes Backup zB von appdata auf eine HDD oder wirklich "nur" die Zugangsinformationen für das Cloud Backup? (In meinem Fall RSA Key und Passphrase) Wöchentlich wäre mir das zu wenig. Da hat denke ich jeder seine eigene Sicherheitspräferenz. Mein appdata folder liegt sowieso auf einem "gesicherten" ZFS Mirror Pool und eben wöchentlich nochmal zusätzlich backup aufs Array. Das reicht mir persönlich als Absicherung.

Hallo, ich bin gerade dabei meine 3-2-1-Backup-Strategie zu verfeinern. Hier bin ich auf einen Punkt gestoßen, bei dem es interessant wäre wie ihr das so macht. Grundregeln der 3-2-1-Backup-Strategie: DREI Datenkopien ZWEI verschiedene Medien EIN externes Backup Derzeit sichere ich wiefolgt: Die wichtigsten Daten (appdata) wöchentlich vom Pool ins Array (Appdata Backup/Restore V2 aus den CA) Einmal wöchentlich auf eine externe HDD (Liegt bei mir Zuhause) Täglich bzw. Wöchentlich verschlüsselt (mittels RSA Key) per Duplicacy in die Cloud Angenommen, meine Wohnung bzw. Haus brennt ab, dann wäre sowohl mein Backup auf dem Server als auch die HDD hinüber. Bleibt noch das externe verschlüsselte Backup in der Cloud. An dieses Backup komme ich nur mittels RSA Key + Passphrase ran, die wiederum in meinem Vaultwarden Container auf meinem Server gespeichert sind. Jetzt kommt der spannende Punkt. Wie komme ich an mein Backup, wenn mein RSA Key + Passphrase auf meinem Server durch den Brand quasi vernichtet worden sind? Wie geht ihr damit um? Sichert ihr die Informationen, um an euer externes Backup zu kommen, nochmal irgendwo anders extern bei zB Familie oder Bekannten? Meine Überlegung wäre, entweder... ein zusätzliches HDD Backup, wo die HDD allerdings bei der Familie platziert wird ODER ein einfacher USB Stick, der den RSA Key + Passphrase enthält und der auch bei der Familie platziert wird, damit ich im Notfall dennoch auf das Cloud Backup zugreifen kann

Bin ebenfalls seit gestern auf 6.12 RC2 und hab mir einen ZFS Mirror Pool mit 2x2TB NVME's gebastelt. Läuft ohne Probleme. Von welchem Plugin genau sprichst du hier?

Vorschlag für die Unraid Notification: #unraid notification result=$(upsc $upshost ups.test.result) if [[ $result == "Done and passed" ]]; then /usr/local/emhttp/webGui/scripts/notify -i normal -s "USV test passed." -d "$result" else /usr/local/emhttp/webGui/scripts/notify -i alert -s "USV test failed!" -d "$result" exit 1 fi

Kann ein BIOS Update bei dem Board eigentlich auch ohne eine eingesetzte CPU über die IPMI Schnittstelle gemacht werden?

Ich denk mir halt dabei, wenn die Dinger gleich viel Kosten dann möchte ich auch die Leistung haben für die ich bezahle. Es wäre das Gleiche wenn ich mir einen Porsche mit 500PS kaufe und den auf 150PS limitiere, weil ich weiß das ich die Leistung auf der Bundesstraße eh nie brauche. Und in 2 Jahren komme ich dann drauf, dass es eigentlich cool wäre eine Runde am Nürnberg-Ring zu drehen. Wo ich dann mit 150PS bei weitem nicht den Spaß habe. Ja die Leistung ist echt gigantisch. Zum schwach werden. 😅

Was spricht gegen einen 13700K, wenn der im BIOS auch begrenzt werden könnte? Zumal du hier dann noch Headroom für später übrig hättest.

Warum limitieren? Bleibt der Verbrauch nicht gleich, wenn die Aufgabe durch eine höhere Leistung schneller erledigt ist?

Ja, aber nur bei den PCIe Slots. Der Chipsatz ist 4.0: Gleiches Spiel beim Z790 Chipsatz. Dieser ist auch nur per 4.0 an die CPU angebunden. Der einzige Unterschied ist, dass vom Chipsatz mehr Lanes bereitgestellt werden. (Daher 4x vollwertige M.2 möglich - beim Z690 ist ja der 4te geshared) Sollte daher vom Vebrauch nicht viel schlechter sein. Und @T-Birth hat hier bewiesen, dass selbst mit einem Z690 ATX Board 13 Watt im Idle möglich sind.

Hast du im normalen Docker Betrieb ohne VMs auch dieses Problem mit der iGPU?

Gibt es eigentlich, außer das von Gigabyte, auch ein W680 Board mit DDR4?

Hat schon mal jemand beim MW34-SP0 den Verbrauch mit aktiviertem powertop und sämtlichen anderen Stromspareinstellungen gemessen?