_alo_

laut syslog sieht es aus, es hätte dein XFS ein Problem: danach starten die smb Fehler also am besten wie angegeben mal xfs_repair probieren

und Du meinst, das funktioniert auch, wenn ich jeden Tag eine neue tar-Datei schreibe? Appdata Backup erzeugt bei mir z.B. jeden Tag einen Ordner und in jedem Ordner ist u.a. eine paperless-ngx.tar.gz Diese einzelnen tar.gz-files sind bei mir inhaltlich sehr identisch, da kaum Dokumente hinzukommen. Kann Borg diese Gemeinsamkeiten auf Block-Ebene erkennen, so wie es Sven wünscht, und demnach nur die Unterschiede übertragen? Ich denke nicht. Der springende Punkt: wir reden ja nicht von derselben Datei, die sich vergrößert, sondern von neuen Dateien, die nur zufällig einen z.T. gemeinsamen Inhalt haben.... Was Du hier machst, ist ja, das Plugin "Appdata Backup" zu umgehen und es quasi mit deinem Borg-Skript zu ersetzen Du machst also kein tar lokal, sondern direkt ein Borg-Backup der appdata-Ordner auf einen remote host. Gute Idee, aber das würde dann auch genauso mit rsync funktionieren, auf Dateiebene synct das auch nur die diffs. Rsync scheitert beim Threadersteller ja gerade genau an dem, was ich oben schrieb. Borg mag seine Vorteile haben (z.B. Verschlüsselung), aber mittlerweile bin ich persönlich weg von Backuptools, bei denen man ohne das richtige Tool nicht mehr an die Daten kommt... Der Ansatz, das Plugin zu ersetzen ist aber definitiv eine gute Idee für diesen UseCase.

Naja, nach dem booten läuft das System komplett im Ram, von daher: ja, kann iirc schon sein - ich frage mich eher, wieso es bei Dir plötzlich nicht mehr komplett lief (docker und co ja schon, nur die GUI nicht??). Nach dem Reboot ist dann auf jeden Fall Ende, wenn er die korrupten Dateien nicht mehr lesen kann. natürlich kannst Du Dir den Stick bzw das Konfig-Verzeichnis kopieren/sichern, dafür hast Du ja bereits ein Backup. Nur der Punkt Lizenz ist da eine Ausnahme, da die Lizenz am USB-Stick (dessen UUID) hängt. d.h. Du kannst nicht einfach ein Backup auf einen neuen Stick laden und starten. Ich weiß nicht 100%ig wie weit man kommt, ob man den neuen Stick ggf. 30 Tage zum Laufen bekommt o.ä. um die Lizenz noch zu migrieren.....den Fall hatte ich noch nicht, aber steht bestimmt in der Doku ;)

Zum Beispiel Diesem dann natürlich auch sagen, dass er als erstes von usb booten soll. Wenn das geht, wüsstest du, dass es nicht am Stick sondern an der Server-Hardware, z.B. ram liegt. Wenn du da den gleichen Fehler kriegst, liegt’s vermutlich doch am Stick bzw. den Dateien darauf. 🤷🏻‍♂️ einfaches ausschlussverfahren Natürlich findet er dann kein Array etc, aber du siehst doch trotzdem ob er über diese checksum Prüfung hinweg bootet….

du kannst auch den bootstick in einem anderen Rechner versuchen zu booten Einen neuen erstellen kannst Du auch, aber dann muss limetech deine Lizenz übertragen

Mach doch bitte mal einen Screenshot deines Main tabs und diagnostics anhängen is auch immer gut

Das ist mir schon klar, dass das geht aber ist das jetzt wirklich das Ziel? Gibt’s da Docker seitig keine andere geeignete Lösung?

ja gibt es in Jellyfin ähnlich: in den Bibliotheken und generell da hier nichts angeklickt/eingetragen ist, speichert er alle Infos unter /mnt/user/appdata/binhex-jellyfin/cache|data daher frage ich mich, was ich noch vergessen habe, bzw. wieso beim scrollen durch jellyfin doch hin und wieder HDDs anspringen..... aber wirklich stören tut es mich nicht, wenn ich da rumstöber will ich ja i.d.R. auch was schauen ;) und dann machen es die unnötigen 5W/15min einer HDD im Vergleich zum laufenden Heimkino dann auch nicht mehr....

hm, ich hab ja jellyfin und nutze kodi mit dem jellyfin-addon. Bei mir kommt scheinbar nicht alle Infos von der SSD. Wo finde ich die entsprechenden Einstellungen zum Kontrollieren? Vielleicht liegts auch nur an Mediathek-Inhalten, wo er keine Infos zu scrapen konnte?

....das Update auf Immich 3.1.0 bzw. das aktuelle node.js ist "schuld": Ausgangslage bei mir war (lief ja bislang): immich läuft auf custom br0 mit eigener IP 192.168.178.249:8080 postgres-immich läuft auf der unraid-IP im Bridge Modus und angepasstem Port: 192.168.178.6:5433 redis ebenfalls 192.168.178.7:6379 also alles im gleichen IP-Netz, Ports passen Das führte aber nach dem Update zu obigem Fehler. [Der vom Standard abweichende Postgres-Port 5433 statt 5432 ist natürlich nicht das Problem] Das Node.js v24 scheint jetzt strikter zu arbeiten und das Routing zur DB hat daher nicht mehr funktioniert, Zitat Gemini: Den postgres-container ebenfalls in custom br0 zu setzen (auf IP 192.168.178.251) hat geholfen, jetzt startet immich wieder 😃 Jetzt kommt aber noch die nächste Fehlermeldung bzgl. Redis: Das ist dann der Redis-Container, den ich allerdings auch z.B. für Paperless (192.168.178.6:8000) benötige... Da ich nicht alle container auf eigenen IPs laufen lassen kann/möchte, ist die Frage, was jetzt zu tun wäre... Gemini schlägt vor, den immich container parallel manuell ins bridge-Netzwerk zu hängen ("docker network connect bridge [Dein_Immich_Container_Name]"), das hatte er auch schon für die postgres-db vorgeschlagen, und dann die docker Bridge 172.17.0.1 als host für postgres/redis einzutragen. Alternativ schlägt er noch das Plugin "docker net connect" vor, welches ich allerdings nicht finde...gibt's scheinbar nicht (mehr) oder gab es nie? Wenn ich redis direkt auf 172.17.0.1 oder 172.17.0.10 (seine aktuelle interne IP) im immich container konfiguriere, kommt: Immich erreicht die bridge also nicht. Der manuelle Weg, immich zusätzlich ins bridge Netzwerk zu hängen, klingt für mich allerdings, als würde das keinen restart des Containers überleben, oder? Gemini schlägt noch eine Custom-bridge vor, aber das Grundproblem von node.js wäre damit doch auch nicht gelöst, oder? Hat jemand noch eine Idee oder hat eine Erklärung dafür? Das ganze läuft übrigens auf unraid 6.12.15, falls sich da seitdem grundlegend etwas geändert haben sollte. Klar könnte ich auch noch eine IP für Redis spendieren und paperless kommt wahrscheinlich damit klar, aus der bridge (paperless) ins br0 zu kommunizieren... Ich könnte natürlich auch einfach immich auf der bridge laufen lassen und den Port 8080 abändern... Aber das eigentliche Thema der Docker-Netzwerke und -Zugriffe ist damit ja nicht vom Tisch - hier bin ich offenbar noch nicht wirklich im Thema, bin eher froh, dass die container alle laufen auf dem unraid host oder eigenen IPs ;)

danke für den Tipp, ich hatte das Repo geändert und Immich lief danach (ich nutze das noch nicht wirklich produktiv sondern nur ab und zu zum Testen). Heute wollte ich im Zusammenhang mit diesem neuen Thread nochmal sehen welche Version ich habe, aber mein Immich läuft nicht mehr wieder mal. Heute nacht hatte ich noch eine Update Benachrichtigung vom Server....Habt ihr das Problem heute auch? Ich nutze ghcr.io/imagegenius/immich:openvino - das sollte doch noch eine verfügbare Variante sein, oder? Immich-Log: Node.js v24.15.0 (node:2693) ExperimentalWarning: WASI is an experimental feature and might change at any time (Use node --trace-warnings ... to show where the warning was created) node:internal/process/promises:394 triggerUncaughtException(err, true /* fromPromise */); ^ Error: connect EHOSTUNREACH 192.168.178.6:5433 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1705:16) { errno: -113, code: 'EHOSTUNREACH', syscall: 'connect', address: '192.168.178.6', port: 5433 }postgres-Log: 2026-07-29 08:00:24.938 GMT [1] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-07-29 08:00:24.939 GMT [1] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-07-29 10:00:26.474 CEST [1] LOG: starting PostgreSQL 16.10 (Debian 16.10-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit 2026-07-29 10:00:26.475 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2026-07-29 10:00:26.475 CEST [1] LOG: listening on IPv6 address "::", port 5432 2026-07-29 10:00:26.509 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-07-29 10:00:26.544 CEST [34] LOG: database system was shut down at 2026-07-29 10:00:22 CEST 2026-07-29 10:00:26.564 CEST [1] LOG: database system is ready to accept connections 2026-07-29 10:03:49.765 CEST [41] LOG: invalid length of startup packet 2026-07-29 10:04:21.910 CEST [42] LOG: invalid length of startup packet 2026-07-29 10:05:26.642 CEST [32] LOG: checkpoint starting: time 2026-07-29 10:05:26.663 CEST [32] LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.003 s, total=0.022 s; sync files=3, longest=0.003 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=1/52B2BA68, redo lsn=1/52B2BA30 Using SSD storage PostgreSQL Database directory appears to contain a database; Skipping initializationDie DB läuft, der Port horcht (ja, auf 5433).

Ist es vielleicht ein reservierter Begriff in Unraid, der eben auch in den GUI-Übersetzungen zu finden ist? Was passiert denn, wenn man Shares nach anderen internen Begriffen z.B. aus dem Menu benennt, wie "shares", "tools", "settings", "plugins", "apps",...?

Ein Hauptgrund ist neben Bequemlichkeit und abfangen der Peaks eben auch der Stromverbrauch. Wenn für jede Mini Datei immer zwei hdds (Daten+parity) anspringen und für 15min (default spindown) laufen und dabei ja 5W ziehen kann das über den Tag schon viel werden. Der Verbrauch der ssd ist dagegen kaum messbar. Mein Backup Server läuft ohne parity. Wenn das skript läuft zeigt rsync nahezu volle Bandbreite an (meist über 200MB/s bei 2,5Gb LAN mit Flow Control), k.a. Warum das bei dir so langsam ist.

Verstehe ich nicht. Ich dachte du hast das raid aufgelöst und Docker / Daten aufgeteilt auf die beiden nvmes…. Jetzt willst du sie wieder zusammenfassen zu einem raid? Hast du denn vorher alles kopiert und ist die zweite auch leer?

noch eine weitere Aktualisierung ich habe wieder zurückgesteckt (ca. 10:58) und die Cyberpower muss anscheinend auch wieder nachladen. Umstecken wie gesagt ca. 1min, danach lädt (anders kann ich mir den Mehrverbrauch nicht erklären) die USV über 20min nach: die ersten ca. 10min lag sie bei >40W, danach etwas niedriger bei ca. 35W und jetzt liegt sie wieder bei ca. 25W. die Eaton dagegen: wird vielleicht auch etwas weniger, aber längst nicht so stark.