Ford Prefect

...zumindest, solange die NVME über PCIe und nicht SATA angeschlossen werden, sonst verlierst Du einen der anderen SATA-Ports. Da muss man bei jedem MB aufpassen und eigentlich auch immer ins Handbuch schauen... An dem Board gefällt mir der Realtek-NIC nicht...verspricht öfter Ärger unter Linux. Ein Intel ist da deutlich entspannter. NICs in 2.G halte ich eh für eine Zwischenwelt....1G oder gleich 10G gehen. Leider ist das ASRock B560 nur in ATX gelistet.

Das Gehäuse hat für die 12 HDDS wohl 3x Mini-SAS Anscglüsse auf der Backplane (12 ports SAS / SATA to Mini-SAS HD SFF-8643 x 3 with SGPIO). SAS und SATA sind abwärtskompatibel, aber bei Einsatz von SATA in der Kommunikation Richtungsgebunden. Welche Kabel hast Du genau verwendet, vom SATA-Anschluss des MB zum SFF8643 der Backplane? Du brauchst (4x)SATA -> (1x)SAS, nicht (1x)SAS -> (4x)SATA. Edit: mt dem SFF-8643 ist das schwer zu finden...Du brauchst das: https://www.silverstonetek.com/de/product/info/accessories/CPS05-RE/ (SAS = Target, SATA = Host)....nicht anders herum (das hier zB ist falsch)

Nein, eigentlich kann das nur bei einem Problem passieren....das kann auch "nur" das SATA-Kabel (oder Strom) betreffen, nicht die Disk an sich. Wieso wiederhergestellt? Sie ist doch wieder da... Die Platten haben absolut NULL Probleme ...weil sie alle NULL Probleme haben.

...jaaa, aber das würde selbst für ein Rack mit innen 600mm zu viel, da Du vorn und hinten noch was brauchst. ...wie oft machst Du das wirklich? Ausserdem sind SATA Ports nur dann Hot-Swap, wenn sie beim Boot auch belegt waren, also aktiviert wurden....das ist kein "echtes" Hotswap. Also wirklich nur was für den Plattentausch, was man ja eigentlich nur sehr selten machen will. No worries...das Nanoxia 4 ist übrigens nicht so tief, wenn man dem Datenblatt trauen kann (Abmessungen (BxHxT): 200x380x480mm), wenn Du es quer reinbekommst (Tiefe Gehäuse = Breite im Rack) erst recht.

...da ist dann ja sooo viel Platz...warum ein Mini-MB und komisches Gehäuse nehmen? Selbst ein schönes, "normales" Midi-Tower würde ja auf ein Shelf in das Rack liegend passen (zB Nanoxia Deep Silence 4)....muss ja kein Rack-Gehäuse mit hotswap sein. Ein Mini-ITX mit Mini-CPU hat einfach nicht genug Lanes dafür... Es gibt mMn genug Auswahl....alles ab S1200 gibt es noch. Meine "Basis"-Wunschliste, mal zur Inspiration: https://geizhals.de/wishlists/2960302 Mit Pentium G oder i3 ... und PCIe Slots zum nachrüsten für "mehr" (SATA, 10G Nic, dGPU, ...)

Wie viel Platz ist denn im Netzwerksschrank (oder oben drauf)...ein System mit nem ordentlichen MB, 16GB RAM und schallgedämmten Gehäuse (Ports für 6x SATA, 2x NVME) fängt bei 400-450EUR an....in DE gekauft.

...da steht auch: storage: -6 x SATA3 6Gb/s ports -SAIA1 is native (2-6SATA is JMB585 expansion) ...Finger weg....nicht OK, da ist ein SATA Switch-Chip drin...wird nur Ärger machen.

Nein, keine Erfahrungen. Grundsätzlich scheinen da keine Komponenten drin zu sein, die "verdächtig" inkompatibel wären. Wenn das Ding echte 6 SATA und 2xNVME via PCIe hat, ist das schon prinzipiell OK. Was mir auffällt: man sieht das Innenleben nicht...ist das ein normales ITX Board...von wem? man sieht das Front-Cover nicht zwischen den beiden Front-Lüftern klafft ne Lücke im Gehäuse...soll man das mit Tape verschliessen, oder was? unklar welche Lüfter verbaut sind...60-80mm, wie es scheint...laut wird es also wohl werden. Das 1U NT wird auch gehörig zum Lärm beitragen...und hat unbekannte Effizienz 3x 1Gbps NICS...Realteks machen oft Probleme in Linux, aber sind ja noch 2 Intel da. nur 1x PCIe-x1 Erweiterung...keine Nachrüstung eines 10G NICs möglich

Ich weiss tatsächlich nicht, was ich Dir darauf antworten soll/kann. Du scheinst gedanklich in einer Zwickmühle zu stecken. Die Frage in erster Linie wäre, was Du wirklich erreichen willst (brauchst Du bestimmte Features von unraid, die es nur im v612RC gibt?), in zweiter Linie, welche Risiken Du dabei eingehst, wenn Du einen RC einsetzt. Hier mal meine subjektiven 2cent: gibt es eine allgemeine Empfehlung für den Einsatz von BTRFS oder ZFS auf dem cache/Primary Storage? -> Nein, weil es die ja für einen RC nicht geben *kann*. Aktuell, wenn Du Redundanz für den Cache willst, ist die Empfehlung BTRFS weil nur das in v6.11 drin ist. Ob es eine andere Empfehlung - zB für ZFS - geben wird, sobald v6.12 offiziell ist - weiss ich nicht. BTRFS und ZFS für sich betrachtet...ist ZFS neue Technologie/ist BTRFS bewährte Technologie ZFS in unraid ist neu, aber genaugenommen ist ZFS von seiner Entstehungsgeschichte her viel älter und in viel mehr Installationen/grösseren Infrastrukturen im Einsatz als BTRFS . In Linux, vor BTRFS gab es ReiserFS (praktisch eine one-man-show), IBM hat (via Redhat) dann in BTRFS investiert und es in den Linux-Kernel eingebracht. ZFS kommt von SUN Solaris, was eine ganz andere Kernel-Architektur hat, als Linux...die erste, native Linux Implementierung ZoL (ZFS-on-Linux) ist/war daher nie ein direkter Ableger von ZFS von Solaris, sondern immer mit viel extra "Glue-Code" verbunden. Mit openZFS ist das aber praktisch Geschichte. Was ist stabiler/verursacht weniger Probleme (allgemein/in unraid)? Ich denke, das ist aktuell von der persönlichen Erfahrung und Vorlieben abhängig. BTRFS hat in unraid eben die längere Historie...daher wird man auch viele User finden, die damit Probleme haben....vielleicht noch mehr, haben keine, aber die findet man dann nicht im Forum. User, die schon auf anderen Plattformen mit ZFS (TrueNAS, Proxmox, Linux, Solaris) ihre Erfahrungen gemacht haben werden diese auf unraid "übertragen". Wenn positiv -> nimm ZFS auf unraid, wenn negativ -> nimm kein ZFS Genauso eben mit BTRFS...wenn keine Probleme, aber keine Erfahrung mit ZFS -> warum wechseln? P.S.: ich gehöre zur Fraktion mit viel positiver ZFS Erfahrung und letztlich sehr negativer Erfahrung mit BTRFS...hätte es keine v6.12beta/RC gegeben, hätte ich meine unraid Server wieder beerdigt und wäre auf Proxmox o.ä gegangen. konkreter Einsatzzweck Cache/Primary Storage mit Redundanz Redundanz heisst eben einen Raid-Level (für zwei Disks Raid1/Mirror) nutzen. Ob BTRFS oder ZFS ist unraid selbst egal. Mit ZFS kommen weitere Features, die in v6.13 weiter integriert werden (zB in s UI, Plugins, statt CLI) - snaps und Replication, zum Beispiel). Risiko, wenn man sich für "die falsche Fraktion" entscheidet Die Prozedur, den Cache/Primary Storage auf einen anderes FS umzustellen bzw. analog die Disks zu tauschen/zu ergänzen ist hinlänglich bekannt. Es kostet Zeit und Arbeit...da man das nicht täglich macht, gibt es das Risiko, dass man was falsch macht / nicht das gewünschte Ergebnis erzielt. Wer Backups hat ist klar entspannter...ansonsten gibt es kein wesentliches Risiko.

...nur als Info, ich habe auch 2x Force MP600 (Rev1, 1TB, FW: EGFM13.0) als Cache und keine Probleme in den Logs. Die haben folgende Werte: Supported Power States ST OP MAX ACTIVE IDLE RL RT WL WT ENT_LAT EX_LAT 0 + 9.78W - - 0 0 0 0 0 0 1 + 6.75W - - 1 1 1 1 0 0 2 + 5.23W - - 2 2 2 2 0 0 3 - 0.0490W - - 3 3 3 3 2000 2000 4 - 0.0018W - - 4 4 4 4 25000 25000 Kann diese NVME auch nur empfehlen (was die die aktuelle R2 der Force MP600 betrifft kann ich nix sagen - ob die besser oder schlechter ist).

Jein, wenn der Server unerreichbar ist und Du nicht im lokalen GUI Modus mit Monitor und Tastatur agieren kannst, bleibt Dir nur der Hard-Reset. je nachdem, was Du bis zum Crash aktiv hattest, was Daten aufs Array schreibt/verändern könnte, können diese Daten ein Problem haben: https://docs.unraid.net/unraid-os/manual/troubleshooting#unclean-shutdowns Wichtg wäre also, rauszufinden, was das Problem verursacht haben könnte. Evtl. im GUI Mode mit Monitor und Tastatur starten, dann inn den Settings die Speicherung des Syslog auf den Stick aktivieren. Wenn das Problem danach wieder auftritt, die Diagnostics erzeugen und hier posten ...evtl ist ein ein Hardware Problem .. auch ein defekter Stick kann Probleme machen.

...die Platten starten automagisch wieder ... egal ob Mover oder andere Ursache für einen Zugriff aufs Array.

Ja, so steht es im Manual. Das stimmt auch, war aber nicht Grundlage Deine Frage..... An anderer Stelle steht es nochmal genauer, auf Deinen o.a. UserCase mit den Daten, die auf ein Share transferriert werden: https://docs.unraid.net/unraid-os/manual/storage-management#backing-up-the-pool-to-the-array ...da steht: ...also mit Daten auf/von einem Share kann das nicht passieren...nur mit Daten, die da (auf das root-Verzeichnis des pool) auf andere Weise hingekommen sind.

Ja, mit zwei kleinen Einschänkungen: unraid Host muss natürlich laufen und das Array gestartet sein (Klugscheisser Mode, ich weiss ) die Dateien dürfen nicht (mehr) geöffnet sein (zB Cient-seitig noch das .doc im Word offen? -> das lässt der Mover liegen).

...um da nochmal eine Info an Doofheit draufzusetzen.... windows unterscheidet bei den Netzwerkverbindungen nur den Server, nicht den kompletten Pfad zum Share ...und nicht den User (den du bei unRaid im SMB-Share ja angeben kannst). Also: In Deinem Windows Account musst Du also alle Netzwerkfreigaben zu unraid Shares mit dem einen, gleichen USER und PWD verbinden (den Du in den unraid Freigaben verwendest und bei den User Settings definiert hast) nimm für die User in unraid *nicht* den gleichen User (und Passwort) wie von Deinem Windows-Account. Nur damit kannst Du von Windows aus die Freigabe immer mittels "mit anderem User und Passwort verbinden" nutzen und bleibst unabhängig von User/PWD Änderungen vom Windoof selbst..

...welche Möglichkeiten sollen das sein? Es wird in v6.13 wohl die Trennung von Array und Pool aufgehoben. Dann könnte man (spekulativ) auch einen "normalen, echten" zfs-pool als Array (secondary storage) nehmen. Dann müsstest Du aber trotzdem Dein Array auflösen (die bestehenden Disks formatieren), weil eine "in-place" Migration mit zfs auch nicht geht. Mein ZFS-pool als unraid-pool schläft quasi ewig/normal.

Es gibt bei nur einer Disk in einem zfs-pool kein self-healing..aber Du kannst eben andere Features von zfs nutzen, we zB snapshots oder zfs-send.

In the unraid Array, parity is optional ... it is not dependant on the filesystem used, but works on disk block-level. Hence the parity must always be the largest drive in the array. See here: Yes, it does. you can do so just now, with the current release candiate.

Das Problem dürften zum einen die Bestigungspunkte des MB im Case sein (kein mATX, mITX, ...) und Du wird zum anderen keine passende Blende für die externen Anschlüsse für ein Gehäuse haben/finden. Vielleicht eher ein open Frame / Benchtable nehmen...dann sieht es nicht ganz so shice aus

No, you can't. The main Array in unraid is a different concept, hence the name "unRaid". Each disk in the Array is formatted individually, no raid, no striping....each file willl always reside fully on a single disk. This concept is applied independent of the filesystem used. Redundany can be achieved by deploying up to two parity disks. However, with v6.12 you can (should be able to) import a zfs pool into an unraid pool (or "primary storage" as now the naming of this "unraid pool"-concept has changed)....but I personally never tried that. Yes, that is advisable / best practice....also it is recommended to use some sort of redundancy, like a zfs mirror or btrfs raid1 with this, hence using two NVME devices (best made of same size, technology (PCIe- or SATA-SSD) and model).

Anzahl SATA Ports wäre das Eine, evtl. zu lösen mit dem M.2-e Port...aber die Unterbringung der HDDs im Gehäuse wäre das eigentliche Problem. Wie viel soll das werden? Bei 4TB ist Schluss bei den 2.5er HDDs... Ich habe da nicht reingeschaut....HP hat da meist keine Standard-Abmessungen fürs Mainboard und keine Standard NT-Anschlüsse....aber evtl kann man es verpflanzen? ...ansonsten sieht es mMN schlecht aus. Ja, richtig.

....wie wäre es noch mit nem Motherboard? Ohne wird's ja wohl nicht gehen, oder hab ich was übersehen? ..und womit greift Tochter auf die VM zu? Was ist, wenn Tochter auf Teile / Daten in der VM zugreifen muss, während sie in der Schule ist (Präsentation o.ä.)? Das würde ich sparen, bzw in ein Laptop für Tochter investieren. Was gibt denn die Schule vor? Wirklich Windows & Office? MS-Teams ist bei uns hier verboten und seit Corona gibt es Apple Tablets... ....grundsätzlich finde ich einen AiO mit Desktops für User schwierig....diese benötigen eh ein Gerät mit passendem Zugriff und passender Grafik-Auflösung.

Zumindest war das mein Eindruck, auf Basis Deiner Ausführungen. Computer sind doof und dazu da, die Probleme zu lösen, welche wir ohne Computer garnicht hätten Du musst Dich also schon ein wenig einlesen...der Teufel liegt im Detail. Ich würde mit dem VPS und WG-"Clients" auf dem Phone oder Laptop anfangen. Auf jeden Fall den VPS auch absichern (kann das nicht offt genug wiederholen). Zum Verständnis, was ein WG-"Client" und/oder -"Server" ist...WG ist ein Mesh...es gibt keinen wirklichen Client oder Server....nur Peers. Alle Peers können untereinander Tunnel aufbauen. Wenn ein Peer beim anderen "anklopft" macht dieser die Tür auf und prüft, ob er den öffentlichen Schlüssel des Anklopfers kennt....der Anklopfer schaut, ob hinter der Tür der erwartete öffentliche Schlüssel des "Angeklopften" sitzt....dann erst bauen beide einen Tunnel auf Basis ihrer privaten Schlüssel auf. Den Peer, der anklopft könnte man für diesen Fall als "Client" bezeichnen, den angeklopften Peer quasi als Server. Was macht einen Peer zum Client? -> Hat der Peer den öffentlichen Schlüssel und einen Endpunkt/Endpoint konfiguriert zu einem anderen Peer, benutzt er diesen Endpunkt (die externe, öffentliche IP des anderen Peers) um dahin eine Verbindung aufzubauen. Ohne Endpunkt wartet er darauf, das der/die konfigurierte(n) Peer(s) bei ihm anklopft/anklopfen. Ist der Tunnel einmal aufgebaut funktioniert der für Traffik in beide Richtungen. Zwei Peers können auch den jeweiligen Peer gleichzeitg aus Endpunkt konfiguriert haben...wer den Tunnel zuerst aufbaut gewinnt. (In Deinem Fall geht das aber nicht...Deine LTE Seite muss den Endpunkt konfigurieren und die Verbindung initieren). Jeder bestehende Tunnel bekommt eine eigene, eindeutge IP (dieses IP-Segment ist quasi das Transfer-Netz, zwischen dem Traffik der peers untereinander geroutet werden kann). Zu jedem Peer wird in der Access-List konfiguriert, welche IP-Segmente (IP-Nummern) in den Tunnel hinein dürfen...also welche IPs von Peers direkt (IPs aus dem Transfer Netz) und hinter dem Peer (zB 0.0.0.0 für alles/die Welt) erreicht werden können. 😅 ... Du schafft das schon, nur Mut. Was hast Du denn für einen Router? Kann der kein WG nativ?

...und dabei, eben bei den RCx-Versionen von unraid, Beobachtungen gemacht, was eben bei einer solchen "Migration" - die letztlich jeder User mal irgendwann machen muss - nicht funktioniert. Man kann in unraid als User nicht viel falsch machen...alles wird übers UI "gesteuert/gepflegt" und unraid läuft im RAM. Einziges Element, wo man selbst von Hand was verbocken könnte ist der GO-File auf dem Stick. Die verschiedenen Varianten einer Config, die durch Installation und Konfiguration von Plugins, Apps/Dockern und VMs entstehen, und dann auf einen neuen unraid Version (neue Versionen vom Kernel und notwendigen Tools und Programmen einer Distribution) noch funktionieren müssen, kann ein Developer nicht alle durchtesten Deine Beobachtung hilft den einzelnen Developern dabei, problematische Konfigurationen zu entdecken und zu analysieren, was da schief geht und auch bei anderen Usern schiefgehen kann/könnte - und Gegenmassnahmen zu ergreifen, die andere User vor dem selben Schicksal bewahren. Selbst wenn es ein "False Positive", aka User-Error ist, hilft das weiter. Community lebt vom mitmachen...Nehmen & Geben.

...würde ich mal machen...vorher den redis Docker stoppen und den zugehörigen appdata Ordner mal sichern/kopieren...just in Case...