_alo_

häh? wie erzwingst du denn eine statische IP über die Fritz! Box? Und aus welchem DHCP Server kommt diese komische IP? Das WHOIS sagt. die gehört Apple 🤔 Und deswegen nutzt man bei docker den custon netzwork type macvlan und die VMs bekommen ja auch eine eigene MAC Adresse. Somit sind alle virtuellen Systeme auch in der MAT der Fritz!Box unterscheidbar. wieso sollte er? (oder meinst du den HACS? da merkt man i.d.R. nichts von) Es gibt doch insgesamt drei Möglichkeiten, um Homeassistant unter unraid zu bekommen: man erzeugt laut HA-Doku eine VM und lädt dafür das Image runter man installiert die docker Version und verzichtet auf HACS bzw. installiert manuell parallel einfach weitere docker-container die die gewünschten Funktionalitäten bieten man nutzt diesen Ha-in-a-box workaround eines speziellen docker containers, der dann 1. für einen umsetzt (richtig? ich kenn den nicht) d.h. ja, was dieser docker container für eine IP hat ist relativ egal, die HA-VM braucht deine .45 - die würde ich in HA (innerhalb der VM) fest vergeben! Ja stimmt, aber das ist ja nicht wirklich in unraid begründet. Auch Dein PI benötigt mal updates, reboots o.ä. und dann passen die Grafiken doch auch nicht, oder? Oder wo ist der Unterschied, ob HA-OS in einer VM läuft oder direkt auf der Hardware?

als allererstes: lass den Quatsch mit Haken setzen in der Fritz!Box, es macht überhaupt keinen Sinn hier mit dynamischen IPs zu arbeiten und einem Server dann immer wieder dieselbe zu geben - stell sie dort einfach fix ein! Feste IPs für Server/Dienste vergibt man außerhalb der DHCP Range (die Fritz!Box hat standardmäßig 20-200, also von 2-19, oder 201-254) und stellt sie manuell statisch/fix ein! In der FritzBox musst Du dann auch einfach gar nichts machen/löschen bei so einer Hardware-Wechsel-Aktion. Dafür stellst Du bei unraid in den Netzwerk Einstellungen das eth0 auf statisch und trägst dort deine Wunsch-IP ein. Wichtig ist dabei die richtige Netzmaske (bei deinem Standard-Fritz!Box Netz ist das /24 bzw 255.255.255.0), das Gateway (die Fritz!Box = 192.168.178.1) und als DNS-Server kannst Du auch die Fritz!Box nehmen (192.168.178.1). Fertig! So macht man das bei allen Geräten, die dauerhaft einen Dienst bereitstellen sollen (Server, Drucker, ...). In den Docker Settings deines HA kannst Du dann sagen, wie er erreichbar sein soll (network type): entweder per Host/Bridge, dann eben unter der IP des unraid Servers (dann ist auf die Ports zu achten, die am Host ja nur 1x verwendet werden können) oder per Custom br0 und einer fixen IP auf die Du diesen docker-container legen willst Wenn Du die .45 für HA unbedingt behalten willst, würde ich Dir raten, die DHCP-Range in deiner Fritz!Box zu ändern (z.B. 50-200) und die .45 dann statisch im HA-docker zu vergeben.... unraid würde ich eine andere IP geben, z.B. die 192.168.178.2/24

Ja, genau so sollten sie eingebaut werden, wenn es nur 2 Module sind! Dies auf dem Foto sind auch genau diese Mushkin Essentials, die Du auch hast. (zwischenzeitlich hatte ich 2x 32gb + 2x 16GB Mushkin, mittlerweile bin ich auf 4x 32GB Crucial CT32G4DFD832A gewechselt, aber nur, weil Mushkin plötzlich so teuer wurde, als ich auf 128GB erweitern wollte...) Funktionieren beide problemlos.

OK, das reine Einbauen und nicht Verwenden erhöht den Stromverbrauch also nicht signifikant bzw. gar nicht, aber wem hilft das in der Praxis weiter? Hat das schonmal jemand getestet, ob das System immer noch C10 erreicht, wenn auf der NVMe wirklich dauerhaft was los ist, z.B. docker/VM darauf laufen? Einen Test in die Richtung kenne ich jedenfalls nicht, lasse mich aber gerne belehren. Klar nur als gelegentliches Backup Ziel mag es auch völlig OK sein, die dort zu betreiben. (ich hatte das selbst auch nie getestet, nachdem ich von möglichen Pkg-C-State-Problemen gelesen und daher zur Sicherheit ein Board mit ausreichend Alternativen gewählt hatte) Ich habe auf dem Asrock Board allerdings getestet, dass das Verbauen der 10G Karte im CPU-X16-Slot (statt Chipsatz-X4) bei mir den Stromverbrauch um 50% von 16W auf 24W erhöht, da das System nur noch bis C2 (statt C10) gekommen ist. Daher warne ich gerne davor, dass das passieren kann und man möglichst auf die Verwendung der CPU-angebundenen Lanes verzichten sollte, nicht muss 😉 Ja, es ist natürlich sehr individuell, aber ich finde es immer noch besser, mögliche Probleme vorher anzusprechen... Teste es aus!

Kein schlechter Wert 👍 ich liege da einiges drunter: ...reicht für meine Amateur-Anwendungen aber mehr als aus. Ich habe hier einen 4TB (RAID1) NVMe-Pool per 10G direkt an meinen MacStudio angebunden. Vielleicht wäre für deine Zwecke ein zfs Pool aus mehreren NVMes eher das Richtige für ordentlich Geschwindigkeit und ausreichend Platz zum Cutten bei geringem Stromverbrauch? Und dann parallel ein normales unraid Array nur für die Ablage?

wie sieht Dein Array heute aus? Hast du schon eine parity und willst die eine 20tb jetzt als zusätzliche zweite parity einsetzen? Oder hast Du noch gar keine Parity? Oder willst du vielleicht einen "parity-swap" ausführen? Das einfachste wäre m.M.n. aufräumen, dabei lernst Du auch am meisten.... Dateien liegen auf dem Filesystem und config-files auf dem stick, kann man alles finden, verschieben, löschen.... Du kannst das Array anpassen oder auch über tools --> new config eine neue Zuordnung erstellen lassen. Wichtig ist nur, dass du die vorhandenen disks entsprechend zuordnest und keine der alten discs formatierst (=Datenverlust). Die Positionen im Array sind nicht wichtig, die Seriennummern sind der key. stell doch mal einen Screenshot deines aktuellen Arrays (main-tab) ein.

Ja genau das sind reine Stromverteiler-Boards bzw. Sata-Verlängerungen, nichts aktives

alles wichtige wurde ja schon gesagt, hier noch eine Ergänzung das Node 804 als mATX wäre wohl für das Gigabyte gedacht und das Meshify als ATX für das Asrock, richtig? In das "compact" wirst Du aber wohl nicht mehr als zwei 3,5" HDDs reinbekommen, das ist eher die Gamer-Variante des Meshify, wo Du "nur" WaKü, Lüfter und große GPU reinbekommst. Für viele HDDs wird dann das normale meshify2 oder das XL interessant. Wenn Du aber nicht mehr als vier HDDs verbauen willst, sind die ehrlich gesagt zu groß und ich würde was anderes kompaktes für ATX + 4 HDDs suchen... Standardmäßig liegen die Container und deren Daten (Appdata) ja auf dem Cache. In den Einstellungen zu den einzelnen docker containern kannst du aber festlegen, welche Ordner am Ende wo liegen sollen. Liegen sie auf dem Cache, brauchst du dort den Platz (und hast dann dort die Fragen nach RAID/Backup/Datenverlust bei Defekt), wenn sie auf dem Array liegen, muss bei Zugriff immer erst ein Spinup der jeweiligen Platte(n) erfolgen und das ganze wird insgesamt langsamer und stromhungriger... Hier mal ein Beispiel von meinem paperless: Data und Media liegen bei mir auf dem Cache (default). Zum Vergleich: ich habe ca. 1000 Dokumente eingescannt und mein paperless-Appdata-Ordner ist aktuell ca. 2GB groß. Mein Consumption-Order liegt auf einem anderen SSD-share und mein Export-Ordner (hier schreibe ich per User-Script ein wöchentliches Backup der Medien/DBs) zeigt aufs Array. Parallel läuft übrigens noch das Plugin "Backup Appdata", welches mir den kompletten Appdata-Ordner täglich aufs Array sichert. Bei Immich habe ich den Foto-Ordner dagegen aktuell aufs Array gelegt, weil hier bei mir viele Daten zu erwarten sind. Noch mache ich damit fast nix, weil ich die Menge an Fotos noch nicht importiert habe, aber ich empfinde das aktuell schon etwas nervig wenn ich die Webansicht mit meinen ersten 20 Testbildern aufrufe, erstmal nur Platzhalter dargestellt werden, dann die HDDs anlaufen und die Bilder nach und nach geladen werden. Das dauert schon etwas. Für hunderte GB an Fotos wäre mir das Nachladen von HDD wahrscheinlich zu lahm, da weiß ich noch nicht, ob ich dafür vielleicht besser doch noch ne schnellere SSD/NVMe spendiere... Kommt also immer drauf an, wo die Daten am besten liegen und wie viel Platz Du brauchst bzw welche Kompromisse Du eingehen kannst/willst... Da haben @DataCollector und ich nun mal unterschiedliche Sichtweisen. Ich stimme ihm ja zu, dass SSDs sehr selten bis nie ausfallen, aber ich gönne mir den Luxus eben trotzdem, zusätzlich zum Backup (s.o.), gerade weil ich auch ausreichend PCIe Lanes und Slots für mehrere NVMes zu Verfügung habe 😉 Zur Boardausstattung: Du brauchst für NVMEs nicht zwingend onboard M.2 Slots, Du kannst auch Adapter auf PCIe verbauen, die gibt es als x1 oder x4, je nachdem, welche Anbindung Du brauchst bzw. Dein Board im Slot maximal bietet. (so hatte ich z.B. 5 NVMes im Asrock verbaut, obwohl der CPU-angebundene M.2 Slot noch frei war) Wenn Stromsparen wichtig ist, solltest du übrigens das Nutzen der CPU-angebunden PCIe-Lanes möglichst vermeiden, das betrifft i.d.R. den X16-Grafikkartenslot sowie den obersten M.2 Slot und manchmal sogar noch mehr. Der Rest ist dann am Chipsatz angebunden. Von daher wäre es beim gigabyte-Board evtl. auch stromsparender die zweite NVMes per Adapter zu verbauen (also am Chipsatz anzubinden). Z-Chipsätze auf ATX-Boards bieten da eben mehr Lanes/Slots und brauchen trotzdem kaum mehr Strom als (m)ATX B-Chipsätze, erst recht, wenn dort noch SATA-Zusatzkontroller ins Spiel kommen müssen. Ist halt die Frage wo man evtl. noch hin will...

ich auch nicht, ich hab bislang nach einem Jahr noch nicht mal 1000 Dokumente erreicht 🥱 Aber ja, auf jeden Fall wird da ne Zeitlang rechnen und das sicherlich einiges mehr, als nur einmalig in den Dokumenten zu greppen. (Ist aber natürlich auch abhängig den Dokumenten....) Aber das ist dann ja quasi ne einmalige Sache, danach profitierst Du ja von der schnelleren Suche. P.S.: darf man fragen, wie du auf 30.000 PDFs kommst? "wget *.pdf" ? 🤣

ja ich bin da Fan von, warum? weil ich: einen schnellen Cache zum Reinpumpen von großen Mengen über 10G haben möchte ein "sicheres" Array mit Parity haben möchte aus stromspargründen das Array nur möglichst selten laufen soll, deshalb bei mir der Mover nur nachts läuft die Daten auf dem Cache solange auch möglichst sicher sein sollen Um den cache auch möglichst sicher gegen Hardwareausfall zu bekommen, sehe ich hier halt nur zwei Möglichkeiten: mover intervall maximal klein stellen, damit möglichst sofort verschoben wird --> hoher Stromverbrauch durch das Array --> Datenverlust bei Ausfall minimiert aber trotzdem vorhanden RAID1 nutzen --> ? Ich weiß nicht, wieso es beim Cache immer gleich um lebenswichtige Dinge gehen muss (unwiederbringliche Fotos z.B. finde ich persönlich auch wichtig!) , aber beim Array ist es völlig ok, wenn man parity-Platte(n) einsetzt oder ein Hardware-RAID. Warum macht ihr das dann noch? Ihr habt doch Backups.... was ist denn da schon wichtiges drauf? Gibt es außer dem Preis und dem "vergeudeten" Slot noch weitere Nachteile von Raid1 für den Pool? P.S.: wirklich lebenswichtig ist die ganze unraid-Kiste nicht, das ist insgesamt pure Luxusspielerei und nicht NOTwendig, egal ob mit Raid1 oder ohne! 😉 aber jeder wie er mag

klingt vielversprechend (du bräuchtest dann ein slackware-Paket das du auf den Stick unter extra speichern kannst, oder vielleicht über "un-get" installieren kannst), aber mal ehrlich: ein grep über 30.000 Dateien (alle einzeln öffnen, suchen, schließen) dauert doch Stunden/Tage bis Du ein Ergebnis hast, oder arbeitet pdfgrep da anders? Da wäre eine Datenbank-Indizierung wie paperless schon geeigneter, oder?

😵da sind aber doch die bestehenden Dokumente in Paperless auch schon doppelt (verarbeitet/original) dabei, oder?

wenn hauptsächlich um diese PDFs geht, dann pack sie doch einfach auch in paperless 🤷‍♂️ zur Not unter einem anderen User

Für 10G kann ich aus Erfahrung nur empfehlen, die Netzwerkkarte, sowie auch die NVMe(s) mit mindestens PCI3.0x2 anzubinden. PCIe3.0x1 ist zwar auch nah an 1GB/s, aber es ist zu nah an der Grenze, d.h. die Übertragungsrate bricht oft ein, siehe hier. Bei PCIe4.0 bist du ab x1 auf der sicheren Seite. Auf welchem Board/System soll das ganze denn laufen (hat das überhaupt genug Anschlussmöglichkeiten für all die Laufwerke)? Ist Stromsparen für Dich ein Thema (dann weniger Laufwerke einbauen, z.B. 3x 20TB statt 5x 8TB - kostet das gleiche, belegt weniger Ports, verbraucht weniger Strom und bietet 8TB mehr Speicher)? Ansonsten bin ich durchaus ein Fan von Raid1 für die Pools..... Beim Array reicht m.M.n. eine parity. Lieber mehr externe Backups vorhalten....

die Frage war doch, ob er mit seinen zwei NVMEs RAID1 machen soll, oder wie Du vorschlägst lieber zwei getrennte xfs single NVMEs (Daten + schnelles Backup) Mein Punkt war, dass bei Deinem Vorschlag die neu geschriebenen Daten zwischen zwei schnellen Backups auf die zweite NVMe weg sind, falls die erste NVMe stirbt und RAID1 genau das eben abfängt. Der neue Punkt ist jetzt, was für Daten das sind (auf den Server verschoben oder kopiert), aber das ist eigentlich nebensächlich für den Punkt und darum ging es mir nicht. daher hatte ich das eben nicht verstanden und dachte Du machst hier einen neuen Punkt auf 😉

gar nicht 😉 ich mounte meine Shares in den Clients und die haben Suchfunktionen in ihren Betriebssystemen dafür eingebaut. Eine suche über mehrere Shares ist zugegebenermaßen schwieriger... ansonsten zur Not noch global in der Konsole von unraid

Ich rede nicht von Backup. Manche nutzen NAS-Shares zur Ablage von Daten 😉 Auf meinem single-disk-PCs befinden sich kaum Daten, sondern nur OS/Programme, d.h. ich verschiebe vom PC auf's NAS - dort liegen die Daten in meinen Augen sicherer dank RAID1 bzw. Array mit Parity. BackupJobs laufen dann dort zusätzlich automatisiert. Verschieben deswegen, weil es früher oder später immer Probleme gibt mit doppelter Datenhaltung und der Frage "hab ich das schon kopiert? welcher Ordner ist aktuell(er)?..." Man kann auch alles kopieren und die Daten auf dem NAS (single Cache) dann als 1. Backup seiner Daten ansehen ("Datengrab") und die Daten dann erst später auf dem PC löschen. Wie gesagt, sehr individuell das ganze...

Wenn Du jetzt alles in einem Netz hast, also Client, NPM, Zielsystem, unraid-Netzwerkkarte und keine falsche Route sollte ja sonst alles passen. aber was mir gerade noch auffällt: "connection refused" kann ja auch darauf hindeuten, dass dein webserver, den Du erreichen willst, die Aufrufe von deinem NPM gar nicht zulässt. Hast Du dort eine ACL, "allowed hosts" o.ä. eingerichtet und den NPM da vergessen? Dann war das Thema VLANs und https vielleicht alles nur Ablenkung 😉

Vollkommen richtig. Ich denke, der beste Weg ist nicht das eine oder das andere, sondern eine Kombination aus RAID + Backup. ... und kann dann z.B. die Shares auf den anderen Datenträger zeigen lassen und ggf. docker/VM von da starten und kann sofort weiterarbeiten, aber eben mit mehr oder weniger Datenverlust: Wenn Dir die single NVMe z.B. beim Verschieben Deiner Urlaubsbilder stirbt, hast du ggü. Raid1 definitiv Datenverlust, nämlich die Daten, die Du zwischen zwei Backupdurchläufen auf diesen single Datenträger geschrieben hast. Übertragungsgeschwindigkeit und Backupintervall bestimmen dann wie viele Daten es maximal sein können... Wenn Du das Intervall jetzt extrem klein wählst, hast Du deinen beschriebenen Vorteil nicht mehr und kannst auch gleich RAID1 fahren. (den Mehrverbrauch einer dauerhaft laufenden Raid-NVMe ggü. einer seltener laufenden Backup-NVMe sehe ich übrigens in den meisten Fällen echt nicht als relevant an, WENN sie nicht an die CPU angebunden ist, was das System dann ja nicht selten in C2-3 stecken lässt) Das muss man also individuell abwägen, gegen welches Szenario man sich wodurch am geeignetsten schützen möchte. m.M.n.: menschliche Fehler (Ransomware eingefangen, falschen Ordner o.ä. gelöscht, Dateisystem kaputtgespielt,....) --> Backup Intervall groß genug oder genügend Versionen, damit der Fehler auffallen kann, bevor auch alle Backups betroffen sind Intervall klein genug, um möglichst wenig Daten durch den Fehler zu verlieren plötzlicher Hardwareausfall --> Raid(>0) Also in Kombination finde ich persönlich RAID1 + Backup (ggf. mehrstufig) ideal. Du kannst es ja sogar auch auf der NVMe kombinieren (falls Du dort ausreichend Platz hast): z.B. Deine 2x 4TB für Dokumente Bilder als RAID1 und zusätzlich auf das gleiche schnelle NVMe-RAID noch Sicherungen (z.B. stündlich), dann noch eine auf's Array (z.B. nachts) dann nochmal extern (weiteres System), so als GFS-Rotation... P.S.: Gerade bei docker/VM sind (häufige) Backups nicht gerade trivial. Nicht wenige arbeiten mit Datenbanken, die man nicht einfach im laufendem Betrieb stumpf kopieren sollte. Für einen konsistenten Stand stoppen gute Backupsysteme laufende Datenbanken für die Sicherung, Plugins wie "Backup Appdata" stoppen dazu zur Sicherheit einfach den kompletten docker-container, sichern und starten ihn dann wieder. Das möchte man tagsüber sicher nicht zu häufig. Ist aber auch am Ende die gleiche Frage wie oben: wie viele Daten fallen pro Backup-Intervall überhaupt an, wie schlimm wäre es die zu verlieren und wie verhält sich demnach Aufwand/Nutzen von häufigen Sicherungen oder teurem RAID1?

Also 3 Pools, ok Für die gespiegelten zfs ok Für den Single würde ich wahrscheinlich xfs statt zfs nehmen Die hdds im Array dann auch xfs Was Du da drauf packst und wie viel Platz du dafür brauchst musst du wissen da können wir nichts empfehlen Wenn du zb 2tb ausschließlich für die virtuellen Systeme brauchst ….ok Hast du denn auch das klassische primär/sekundär Prinzip von unraid mit dem mover geplant oder wie verschiebst du die ungesicherten filme/Serien nach 1 Monat auf das Array?

Naja, jede Datei bzw. Ordner hat spezifische Rechte und einen Besitzer/gruppe Klar ist es erstmal wichtig(er) alle Daten zu sichern aber wenn du sie brauchst und wiederherstellen willst, kann es bei bestimmten dockern zb schon wichtig sein, wem die Daten gehören und wer alles wie drauf zugreifen darf, damit der Dienst auch wieder richtig startet und funktioniert… Nur weil sie dem richtigen User gehören heißt das ja nicht automatisch dass du nicht drauf zugreifen (lesen) darfst. Ich würde möglichst „Rechte beibehalten“

Ne nicht ganz. Der öffentliche DNS Server von strato lässt die (sub) Domain wohl eher auf deine öffentliche (fix? Dyndns?) zeigen und du leitest dann am Router (FRITZ!Box bzw speedport) weiter auf deinen unraid npm oder? Was löst dein endgerät denn für eine ip für deinen hostnamen per DNS auf? Was macht dein endgerät wenn du diese ip aufrufst? Hast du den lokalen DNS auch eingestellt für die internen IPs der Dienste?

Kurzform für change owner Ich würde nicht den docker als Root laufen lassen sondern dem Ziel-Ordner einfach passende Rechte geben, zur Not erstmal 777

Was meinst du damit? Ohne DNS ist wlan generell sinnlos (hat dann nix mit npm zu tun)

Wie ich schon eingangs schrieb, sehe ich das Problem hier: Das ganze VLAN Zeugs (NPM & Dienst) spielt sich scheinbar nur auf eth1.16 ab, trotzdem routest Du das Netz von VLAN16 zum eth0 (hatte ich auch schonmal geschrieben!) Ich weiß nicht wie dein Netzplan aussieht (hatte ich auch nach gefragt), ob vielleicht noch irgendwelches Kreisrouting passiert, aber ich würde da erstmal aufräumen und eine vernünftige Erreichbarkeit der Geräte im VLAN 16 herstellen. Ja es ist etwas abgedriftet in die Fragen der Sinnhaftigkeit der Vorhaben VLANs & https im LAN, aber auf diese Anregungen darf @marhal auch ruhig mal eingehen....😉