mgutt

Ja das Wort Snapshot wird häufiger genutzt, aber ein Snapshot ist keine Parität. Und ein Snapshot von 3 vollen Disks würde 3 Paritätsdisks benötigen. Das ist bei SnapRAID aber nicht der Fall. Es muss sich also um eine Parität und um kein Snapshot handeln. Vom Prinzip ist die FAQ schon ein Widerspruch in sich: Erst steht da, dass ein Snapshot erstellt wird und dann, dass es eher einem RAID-Z ähnelt. Das sind aber zwei völlig unterschiedliche Dinge. Ein Snapshot arbeitet mit Inodes und Links auf bestehende Blöcke und ignoriert Blöcke, die sich danach ändern. Ein RAID erstellt dagegen XOR Paritäten, was mal wirklich gar nichts mit Snapshots zu tun hat. Der Autor scheint damit nur ausdrücken zu wollen, dass die Parität einen alten Zustand abbildet. Er nutzt ja sogar das Wort "Backup", was aber mal gar keinen Sinn macht. Genau da sehe ich eben das Problem. Eine Parität wird wie folgt berechnet: 1 + 1 + 1 = 3 = ungerade Zahl = Parität = 1 Geht nun Disk2 kaputt: 1 + 1 + Parität 1 = 3 = ungerade Zahl = Disk2 = 1 Bis hier hin funktioniert SnapRAID. Wenn ich aber nun nach der Erstellung der Parität das Bit von Datei0 ändere passiert das: 0 + 1 + 1 = 2 = gerade Zahl = Parität = 0 (nicht 1) Mir fehlt jetzt also die korrekte Parität um bei Ausfall von Disk2 die Daten wiederherstellen zu können: 0 + 1 + Parität 1 = 2 = gerade Zahl = Disk2 = 0 = Datei nicht wiederherstellbar Wenn ich also SnapRAID richtig verstehe, dann ist die Parität SOFORT kaputt, sobald ich eine Datei ändere, da eine Dateiänderung einem Diskausfall entspricht. Das betrifft dann zwar nur die Dateien der restlichen Platten, aus denen die Parität berechnet wurde, aber welchen Sinn hat denn eine Parität, wenn ich dieser nicht vertrauen kann? Ein einfaches Beispiel: Platte 1 enthält ein Word Dokument Platte 2 enthält eine MP3 Platte 3 einen Film Platte 4 die Parität, die aus diesen drei Dateien gebildet wurde Ändere ich nun nach Generierung der Parität das Word Dokument, dann gehen das Word-Dokument, die MP3 oder der Film nach einem Disk-Ausfall garantiert verloren, je nachdem welche der Platten 1 bis 3 ausfällt. Und keiner der SnapRAID nutzt, lässt die Parität im Minutentakt korrigieren. EDIT: Es ist leider genauso wie ich es verstanden habe: https://www.reddit.com/r/DataHoarder/comments/5ctif1/snapraid_question_about_small_and_frequently/d9zubvz/ Also SnapRAID macht nur in einem sehr begrenzten Bereich Sinn (zB Medien-Sammlungen, die sich selten ändern) und es ist verrückt SnapRAID per Cronjob auszuführen. Stattdessen bräuchte es eigentlich einen Daemon, der ständig Dateiänderungen überwacht. Ist das jedem bekannt? Weil das nutzen ja viele mit OMV und wehe man hat im SnapRAID Verbund nur eine Platte mit Dateien, die sich ständig ändern wie zB Containern oder VMs. Da zerlegt man sich ja die Parität im Sekundentakt. Jedenfalls weiß ich jetzt schon mal, dass SnapRAID keine Alternative zu einem RAID5 für den Unraid Cache ist. Also doch eher Lsyncd.

Ich denke nicht, aber es dürfte genauso sein als hättest du ständig eine zusätzliche SATA PCIe Karte installiert. Ich denke auch, dass du den Controller über das BIOS deaktivieren kannst. Was das schlussendlich ausmacht.. keine Ahnung. Muss man ausprobieren. Allerdings sollte man nicht unerwähnt lassen, dass der verbaute ASM1061 Controller SATA Port Multiplier unterstützt. Man könnte also aus den 2 Ports bis zu 10 machen, wobei von der Performance her nur 1 auf 2 oder höchstens 1 auf 3 zu empfehlen wäre (der Overhead bei Port Multipliern ist extrem, bei 1 auf 5 hat man nur noch 35 MB/s). Was mich aber persönlich an dem Board am meisten stört ist der gedrosselte M.2 Slot. x2 heißt ~2000 MB/s statt ~4000 MB/s. Vom Prinzip ist das nicht weiter tragisch bei einem NAS, aber wenn du mal eine NVMe zB als Bootlaufwerk einer VM verwenden möchtest, hast du eben nicht das Potential, was eigentlich möglich wäre. Und bei einem RAID1 ist der zweite M.2 Slot entsprechend auf die Geschwindigkeit des langsameren Slots reduziert. Und schlussendlich steht halt im Raum, dass man trotz der Größes des Boards gar nicht mehr PCIe Slots zur Verfügung hat. Hat ein bisschen was von einer Mogelpackung. Aber das ist nicht dem Board, sondern der PCIe Lanes der CPU / des Chipsets geschuldet. Asus hat keinen ASM1061 verbaut und dafür sind beide M.2 Slots x4. Wäre aus meiner Sicht der bessere Kauf, wobei das Asus Board teurer ist. Du wirst das Board jetzt also nicht an die Wand klatschen müssen, aber einen wirklichen Mehrwert hast du dadurch auch nicht. Rein finanziell ist die Frage ob das ATX Board 15 € Aufpreis gekostet hat. Das ist nämlich ungefähr das was eine 2 Port SATA Karte kostet.

SnapRAID soll ja wie Unraid einem RAID4 ähnlich sein (also ein separates Laufwerk als Parität): Der Unterschied zu Unraid ist, dass SnapRAID die Parität: - zeitversetzt erstellt - nicht sektor-basiert, sondern datei-basiert berechnet Wie die XOR-Paritätsberechnung funktioniert ist mir bekannt. Wem das nicht klar, kann zB das Video anschauen. Sagen wir, wir haben auf den oben genannten Disk0, Disk1 und Disk2 jeweils die Datei0, Datei1 und Datei2 und ich erstelle die SnapRAID Parität auf Disk3. Nun fällt Disk2 aus. Ich kann dank der Parität die Datei2 von Disk2 wiederherstellen. Soweit so klar. Doch was ist, wenn ich Datei1 zwischenzeitlich geändert habe? Da die XOR-Berechnung ja über alle Platten und Dateien hinweg erfolgt, ist dann nicht auch die Parität kaputt, wenn ich Datei1 ändere? Wenn ich zusätzlich Datei0 ändere, dürfte dann nicht sogar alles verloren sein?

Hast du das Full ATX Board gekauft und wenn ja warum? Gegenüber dem mATX (C246M) hat man meiner Ansicht nach eher Nachteile: - ein M.2 Slot nur x2 statt x4 - durchgehend mehr Stromverbrauch durch den zusätzlichen SATA Controller (und das nur wegen 2 zusätzlichen SATA Ports) Dazu deaktiviert der M.2 Slot einen PCIe Slot, so dass man schlussendlich nur 4 PCIe Slots wie das mATX hat. Zum Strom sparen das machen was ich bei den Messergebnissen gemacht habe: https://www.computerbase.de/forum/threads/selbstbau-nas-im-10-zoll-rack.1932675/page-6 Außerdem powertop nutzen: https://forums.unraid.net/topic/98070-reduce-power-consumption-with-powertop/

Dazu bietet sich das Unbalance Plugin an. Über "Gather" kannst du erst den Share und dann die Ziel-Disk auswählen.

Wenn du den Versand (2 € Warensendung) übernimmst, kann ich dir den zum Testen senden: https://www.amazon.de/gp/aw/d/B08GKB3ZK6/ref=yo_ii_img?ie=UTF8&psc=1 Bei mir ging der nicht.

JorgeB spricht dort von einer hohen "Write Amplification". Hier sagt er aber auch, dass das ein generelles Problem aller Copy on Write Dateisystem ist, also auch bei ZFS. Ein Zitat aus Wikipedia: Das heißt also, dass wenn in einer Datei Daten aktualisiert werden, dass die zugehörigen Blöcke vollständig an einer anderen Stelle neu erstellt werden. Zusätzlich wird das noch in separaten Meta-Blöcken "notiert". Wenn ich zB diese Frage/Antwort lese, werde ich direkt an unser Problem mit BTRFS erinnert, dabei geht es aber um ZFS. Hier gibt es eine Diskussion ob man SSDs mit ZFS nutzen sollte und das Argument vom dortigen cyberjock ist, dass sie ja "nur" 10-20% schneller kaputt gehen, aber das das keinen jucken würde, weil die SSD trotzdem lange genug hält und vorher ausgetauscht wird, weil sie zwischenzeitlich zu klein geworden sind. Mein Fazit ist daher, dass man mit diesem Nachteil bei COW Dateisystem einfach leben muss. Und wenn das nicht kann, dann muss man sich was anderes einfallen lassen. Vielleicht wäre ja lsyncd eine Idee (lsyncd Slackware Paket). Damit könnte man zwei SSDs live synchron halten. Also ein selbst gebautes RAID1 mit zwei XFS SSDs. Für ein RAID56 bräuchte es dann schon härtere Geschütze wie Snapraid mit dem man ja bekanntlich zeitversetzt Paritätslaufwerke erstellen kann (Snapraid Slackware Paket). Das wäre dann mein Favorit, da ich zeitversetzt eh bevorzuge. Das würde ich mir optional auch für Unraid wünschen.

Diskussion dazu hier: https://forums.unraid.net/topic/100695-mehr-schreibvorgänge-mit-btrfs/

Yes, this is was I meant: Thanks for the hint!

@ich777 ist einfach zu langsam 😋

Gerne.

Von hier: Das liegt nicht an BTRFS. BTRFS ist ein Dateisystem. Das macht nur das was man ihm sagt. Es kann aber gut sein, dass ZFS eine andere Blockgröße hat oder einfach anders mit dem überschreiben der Blocks umgeht. Jedenfalls ist die Ursache meiner Ansicht nach in dem Healthcheck der verschiedenen Docker Container zu suchen. Bisher sind hier Plex und PiHole aufgefallen: https://forums.unraid.net/bug-reports/stable-releases/683-unecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/ Die Lösung ist es bei jedem Container den Parameter --no-healthcheck bei den Extra Parameters zu übergeben: Welcher Healthcheck aktiv hat, sieht man in der Docker Übersicht mit aktivem Advanced View: Mit diesem Kommando kannst du übrigens die Schreibvorgänge des docker.img überwachen und in eine Log-Datei schreiben: inotifywait -e create,modify,attrib,moved_from,moved_to --timefmt %c --format '%T %_e %w %f' -mr /var/lib/docker > /mnt/user/system/docker/recent_modified_files_$(date +"%Y%m%d_%H%M%S").txt Auf die Art bin ich damals dahinter gekomme, steht aber auch in meinem Bug-Report. Mein Bug-Report bei Docker wurde leider ignoriert. Der Fehler liegt nämlich bei denen. Die überschreiben ständig unnötig JSON-Dateien und dadurch, dass bei Unraid ein docker.img und eine hohe Blockgröße existiert, resultiert daraus ein höherer Traffic auf den Laufwerken. Jedenfalls konnte ich das Problem damit lösen. @Squid hat übrigens irgendwo mal vorgeschlagen das docker.img aufzulösen und stattdessen einen realen Pfad zu nutzen, aber ich glaube das ging nur bei der aktuellen Beta und ich weiß auch leider nicht mehr wo er das geschrieben hat ^^

Wenn du einen Pfad in einem Docker Container verwenden möchtest, dann musst du diesen Pfad in den Container-Einstellungen hinterlegen. Der Container benötigt einen internen Pfad und den mit dem dieser lokal verknüpft ist. Beim Cloudcommander ist zB standardmäßig nur "/UNRAID" mit dem lokalen Pfad "/mnt/user" verknüpft. Du musst daher unten auf "add another path" klicken und einen weiteren Pfad hinzufügen. Als Name und Container Path wählst du zB "/disks" und als Host Path "/mnt/disks/". Sobald der Container neu gestartet wurde, ist dieser Pfad dann normalerweise auch aufzufinden.

Wie gesagt. Ich glaube, dass das alles Wechsler von FreeNAS sind. Aber klar. Ein neuer Wechsler, ist ein neuer zahlender Kunde ^^

@ich777 Es gibt sie, aber viele davon auch nur, weil sie von FreeNAS zu Unraid gewechselt haben und das RAID behalten haben und zusätzlich ein normales Array nutzen. Dass die meisten davon nur einen USB Stick als Array haben, kann ich mir kaum vorstellen. Die wechseln doch nicht nur wegen der bisschen besseren GUI. Wenn es nach mir ginge würde ich ZFS komplett ignorieren und nur noch BTRFS RAID1 und RAID10 bei für die Pools anbieten bzw RAID56, wenn der Nutzer eine USV angeschlossen hat (das würde ich tatsächlich so auch in der GUI voraussetzen). Meiner Ansicht nach gibt es wichtigere Punkte für die Entwickler als den ZFS Support. zB mehrere Unraid Arrays oder einen vollwertigen Datei-Explorer. Aber das muss natürlich Limetech entscheiden.

Dann ist Unraid nicht das Richtige für dich. Ich mein was hast du nun davon, dass du ZFS per Kommandozeile pflegst, nur um Unraid nutzen zu können. Bei FreeNAS hast du die passende GUI dafür. Bevor ich mit der Kommandozeile anfangen würde, würde ich eher FreeNAS als VM in Unraid laufen lassen. Dann hast du beides. Die Frage ist auch warum du unbedingt ZFS haben willst. Ist dir Selbstheilung wichtig? Dann kannst du in der stabilen Unraid Version den Cache mit HDDs im BTRFS RAID5/RAID6 betreiben. Dann hast du auch Selbstheilung. Synology macht nichts anderes. Wenn du die Unraid Beta version nimmst, kannst du sogar mehrere BTRFS RAID Pools anlegen. Hast du Angst vor dem theoretischen "Write Hole"? Dann nutze mehrere RAID1 Pools oder eine USV, wobei die meiner Ansicht nach eh zur Standardausrüstung gehören sollte. Im Kern ist Unraid nicht für RAIDs, sondern für das heiß/kalt Konzept gedacht. Heiße Daten kommen auf den SSD RAID Cache Pool und kalte Daten auf das Unraid HDD Array. Wer dann noch Angst vor Bitrot im Unraid HDD Array hat, der kann mit Dynamix File Integrity regelmäßig Hashes von den Dateien auf dem Array machen und falls sich eine Datei geändert haben sollte, diese aus einem Backup wiederherstellen. Denn Backups brauchst du immer. Auch bei ZFS. Denn was nützt dir das Self-Healing, wenn es fehlschlägt. Dann brauchst du auch ein Backup.

Ja, das geht problemlos. Es ist aber kein "bestehendes Volume". Das ist anders als bei Synology, wo das RAID durch ein Volume abgebildet wird. Bei Unraid ist jede HDD ganz normal formatiert. Hast du also 4 HDDs und 1 davon ist die Parität, so hast du 3 ganz normale Volumes. Fügst du eine weitere HDD hinzu, dann sind es 4. Und ja, alle werden durch die Parität geschützt. Das einzige was du dir merken musst, dass die Parität die größte HDD sein muss und jede neue HDD kann nicht größer sein als die HDD mit der Parität. Kleiner kann sie aber sein. Also ähnlich wie beim Syno SHR. Tatsächlich wird dadurch nicht mal die Parität neu berechnet, denn die neue Platte wird von Unraid komplett mit Nullen beschrieben, so dass die Parität unverändert bleiben kann. Weder BTRFS noch ZFS sind ohne RAID selbstheilend. @JorgeB hat hier einige Fragen beantwortet: https://forums.unraid.net/topic/99793-btrfs-vs-xfs-main-array-any-btrfs-experts/?tab=comments#comment-920561 Bei Fehlern müssen diese einzelnen Dateien also aus einem Backup wiederhergestellt werden. Da XFS aber robuster bei plötzlichem Ausfall des Servers ist (warum auch immer dieser ausfällt, zB weil du ihn nach Einfrieren selbst hart herunterfährst), empfehlen viele XFS in Kombination mit dem Dynamix File Integrity Plugin zu nutzen, welches von jeder Datei eine Hashdatei erstellt und diese regelmäßig auf Bitrot prüft. Aber auch hier muss die korrupte Datei aus einem Backup wiederhergestellt werden. Willst du dagegen ein selbstheilendes Dateisystem, dann musst du ZFS im RAID nutzen oder BTRFS im RAID1 (andere RAID-Stufen gelten ja immer noch als experimentell, wobei Syno es so einsetzt). Das geht, setzt aber voraus, dass alle deine Projekt-Dateien auf den NVMe SSDs liegen. Das HDD Array ist zu langsam dafür. Außerdem benötigst du eine potente CPU mit hoher Single Thread Leistung. Also einen i3 8100 oder 9100 oder 10100. Auch sollte man SMB Multichannel aktivieren und ich würde direkt auf die Cache Disk schreiben und nicht auf einen Unraid Share, um Unraids Overhead zum umgehen. Dazu kann ich dir dann später noch ein paar Tipps geben. Die 1175 MB/s über 10G sollte denke ich für den direkten Schnitt ausreichen, aber sie sind trotzdem nicht so schnell wie >3000 MB/s einer lokalen NVMe. Ist ja logisch. Die lokale NVMe kann auch viel besser mit parallelen Zugriffen umgehen als SMB. Müsste man einfach mal testen. Übrigens kann man auch sehr hohe Upload-Geschwindigkeiten erreichen, wenn man sehr viel RAM im Server verbaut. Bei zB 128GB RAM und 50% vm.dirty_ratio kannst du bis zu 64GB an Daten sogar auf das HDD Array mit 10G Geschwindigkeit hochladen. Linux RAM Caching macht das möglich. Allerdings ist dann eine USV absolut notwendig. Taugt nichts für dein Vorhaben. Egal welche CPU. Viel zu wenig Single Thread Leistung. Single Thread Leistung am unteren Limit für dein Vorhaben, aber mangels Kernen kein restliches Potential für weitere Spielereien. Der macht richtig Laune. Sehr hohe Single Thread Leistung und 6 Kerne. Für Plex optimal. Als Davinci Renderserver schwach, aber wenn du mal keinen Bock hast auf deinem Client zu rendern, könntest du es auf den Unraid-Server auslagern und holst das fertige Rendering zB am nächsten Tag ab. 128GB? ^^ ECC ist jetzt diese Frage, die du dir selbst stellen musst. Das ist genau das selbe wie mit dem selbstheilenden ZFS RAID. Glaubt man an Bitrot oder nicht Wenn es ein Thema für dich ist, dann wird es teuer, denn ein i5 unterstützt kein ECC. Du brauchst dann einen Xeon oder musst runter auf einen i3-9100 bis i3-9350K. Der i3-10100 unterstützt kein ECC mehr. Ab der 10ten Generation geht nur noch Xeon. Also mindestens 300 € nur die CPU oder man probiert es mit einem i3. Ich selbst habe 10G und einen i3-8100 und teste immer wieder was mit diversen Windows VMs. Mein aktuelles Lieblingsboard ist das Gigabyte C246M-WU4 (8x SATA, 2x M.2, 128GB ECC RAM). Denk dran, dass du mit zwei M.2 nur noch 4x SATA Ports nutzen kannst: Wie groß ist der SLC Cache? Du sprachst ja von großen Dateien. Die QLC SSDs sind ja bekannt massiv abzukacken, wenn der SLC Cache voll ist. Machen denke ich viele auf kurzen Strecken, weil es günstig ist. Ich denke nicht, dass etwas dagegen spricht. Preislich bin ich da nicht auf dem Laufenden, meine aber mal was von 30 € pro Karte gelesen zu haben. Wobei ich gerade nicht weiß ob da auch die Kabel dabei waren. Das musst du wissen. Hängt ja auch davon ab wie viele Platten schlussendlich eingesetzt werden sollen. In meinen Augen alles völlig egal. Vorzugsweise die Parität mit einer schnelleren Platte ausstatten, ansonsten kannst du jeden "Müll" verbauen. Die Platten werden wie du schon sagtest regelmäßig schlafen geschickt. Die werden also nicht mehr belastet als in einem Desktop PC. Anders als bei einem RAID ist es sogar egal ob du 5400 mit 7200 rpm Platten mischst. Gebrauchte Platten gehen genauso. Haben sie allerdings Fehler, solltest du sie logischerweise nicht mehr verwenden. Ne, da würde ich auch nur die alten Sachen für verwursten. Du kannst ja sogar einen zweiten Unraid Server damit basteln. 10G usw sehe ich keinen Sinn drin, weil du ja denke ich inkrementell sichern wirst. Mein Unraid Backup Server steht Remote bei einem Freund und hat nicht mal eine Parität.

Unraid ist wie der Name schon sagt kein RAID. Es gibt zwar wie bei einem RAID eine Parität und man kann eine Netzwerkfreigabe (Share) auf mehreren Platten verteilen, aber da endet auch schon die Ähnlichkeit. Um das Unraid Konzept zu verstehen, sollte man meiner Ansicht nach erstmal ein RAID verstehen. Bei einem RAID werden Dateien in ihre Bits zerlegt und auf den Platten verteilt. Sagen wir mal wir haben ein RAID5 mit 4 Platten und zwei Dateien mit jeweils 3 Bits. Das erste Bit landet auf Platte 1, das zweite Bit auf Platte 2 und das dritte auf Platte 3. Auf der 4. Platte landet die Parität aus diesen drei Bits. Die Bits der zweiten Datei werden ebenfalls verteilt, nur dass diesmal die Parität auf einer anderen Platte liegt. Bei der Parität handelt es sich um das Rechenergebnis einer XOR Berechnung. Stell dir der Einfachheit halber eine Quersumme vor. Geht nun eine der Platten kaputt, kann man mit den anderen drei die fehlende Information, entweder die Parität oder das Bit der Dateien errechnen. Gehen zwei Platten kaputt, dann ist das nicht mehr möglich und alle Daten sind verloren. Nun stellen wir das Unraid Konzept gegenüber. Erneut 4 Platten, wovon eine die Parität darstellt. Nun werden die Dateien aber nicht auf die Platten zerlegt, sondern jeweils vollständig auf Platte 1 und Platte 2 abgelegt. Platte 3 bleibt leer. Die "Quersumme" wird nun wieder berechnet und landet auf Platte 4. Im Gegensatz zum RAID5 landet sie übrigens immer auf Platte 4. Auch hier kann eine Platte problemlos ausfallen und das fehlende Bit würde errechnet. Was ist nun der Unterschied: - bei einem RAID5 kann man eine Datei von 3 Platten gleichzeitig lesen. Man hat also eine 3-fach höhere Lesegeschwindigkeit (selbes gilt beim Schreiben). - bei Unraid muss nur die eine Platte laufen, auf der die Datei liegt, die du abrufen möchtest, was außerordentlich stromsparend ist - bei Unraid könnte Platte 2, 3 und 4 kaputt gehen und die Datei auf Platte 1 wäre immer noch da. Ein Totalverlust ist also erst möglich, wenn wirklich alle Platten kaputt gehen (wenn man viele Platten hat, ist das ein nennenswerter Bonus) - bei Unraid kannst du eine Platte ausbauen und über einen PC auslesen - bei Unraid ist die Lesegeschwindigkeit auf das Maximum einer Platte limitiert - bei Unraid ist die Schreibgeschwindigkeit auf ca 70 MB/s limitiert (mit aktivierter Turbowrite-Option auf das Maximum der langsamsten Platte des Arrays) Aber auch Unraids SSD Cache ist anders: - Syno, QNAP, FreeNAS, etc nutzen die SSDs zu 100% als Zwischenschicht auf der permanent alle aktuellen Dateien als Kopie vorgehalten werden, wobei Uploads die jeweils ältesten Dateien überschreiben. Die SSDs werden also ständig neu beschrieben und sie funktionieren nicht ohne das HDD RAID dahinter, da sie damit live synchron gehalten werden. - SSDs nutzen sich bei anderen NAS Betriebssystemen entsprechend schnell ab - Unraid nutzt die SSDs dagegen als normales Laufwerk, wobei Uploads erstmal auf den SSDs landen und nach x Stunden durch den so genannten Mover auf die HDDs verschoben werden. Der SSD Cache verhindert also vollständig, dass die HDDs überhaupt anlaufen. Dadurch sind Uploads nicht mehr auf die 70 MB/s limitiert, sondern auf die Geschwindigkeit der SSD, die bekanntlich viel schneller sind - zusätzlich hat der Nutzer die Wahl, ob er bestimmte Dateien permanent auf den SSDs belässt. So kann man zb virtuelle Maschinen oder Docker Container durchgehend ohne HDDs betreiben Unraid ist also mit der richtigen Hardware besonders stromsparend und leise. Außerdem bietet es eine besonders hohe Ausfallsicherheit und die vermutlich beste Oberfläche für VMs und Container. Der Nachteil ist, dass nicht alle Daten ständig mit RAID-Geschwindigkeit abgerufen werden können (sofern dies nicht eh durch 1G LAN begrenzt ist). Aber und das sollte man auch nicht unerwähnt lassen, kann man in Unraid in Zukunft auch mehrere RAIDs konfigurieren. In der neuesten Beta mit BTRFS, aber ZFS steht auch auf der Agenda (bzw es gibt auch schon ein Plugin dafür). Ich bevorzuge aber das ursprüngliche Unraid Konzept und verzichte bewusst auf RAIDs.

Dazu sei noch angemerkt, dass es nicht zu empfehlen ist nur eine SSD als Cache zu verwenden. Alle Daten, die auf der SSD liegen, also noch nicht vom Mover auf das Array verschoben wurden, gehen bei Defekt der SSD verloren. Empfehlenswert sind daher zwei SSDs im RAID1. Das gilt insbesondere für Daten, die man permanent auf der SSD belässt wie zB Docker Container oder VMs, wobei man für solche Daten natürlich auch Backup-Strategien anwenden kann. Meine Empfehlung, sofern das mit der SSD gar nicht klappt: Installiere 64GB RAM und erhöhe vm.dirty_ratio auf 50% (Tipps und Tweaks Plugin). Ist allerdings nur mit einer USV empfohlen. Der RAM fungiert dann als Cache.

Das ist auch die Grundvoraussetzung bei Unraid. Die Lizenz wird an einen USB Stick mit Seriennummer gebunden (bei Defekt kann man die Lizenz natürlich auf einen anderen Stick übertragen). Auf die Art stellt Unraid sicher, dass jede Lizenz nur 1x pro Server verwendet werden kann. Das dachte ich mir schon. Wie gesagt gingen auch Port Multiplier bei diesem Board. Die kosten das Stück <15 €. Damit kann man problemlos aus einem Port zwei machen. Eigentlich macht der Multiplier sogar 5 Ports draus, aber mehr als 2 sind wegen der Performance nicht zu empehlen (Bandbreite wird aufgeteilt). Alternativ ginge evtl auch dieser Adapter: http://www.iocrest.com/index.php?id=2248 Allerdings ist der gerade nicht lieferbar: https://de.aliexpress.com/item/32858547315.html Eventuell von einem anderen Hersteller ausprobieren. Die von Inline ist gerade überteuert: https://geizhals.de/inline-66910-a1541515.html Vielleicht leiht dir ja @Alphavil seinen. Bei ihm hat er nicht funktioniert: https://forums.unraid.net/topic/100306-cache-austauschen-vorgehensweise/?tab=comments#comment-928275 Schon klar. Aber für die Funktion ist das irrelevant. Wenn die M.2 in der Buchse steckt, dann geht sie (normalerweise) auch. Also auch wenn sie im 45 Grad Winkel in der Luft steht. Sieht nur halt doof aus. ^^ Oder passt sie schon nicht von den Kerben her? Eventuell ginge es dann mit so einem Adapter: https://www.amazon.de/Sintech-NGFF-NVME-WiFi-Kabel/dp/B07DZF1W55 Solche Adapter habe ich glaube sogar hier rumfliegen, aber nie getestet.

Hast du das Video ab 21:13 angeschaut?

Das geht übrigens sehr einfach mit der App "Config Editor". Alternativ kann man auch "User Scripts" installieren und ein Bash Script anlegen, das beim Starten des Arrays ausgeführt wird. Ich vermute, dass das nicht lösbar ist, denn das deutet darauf hin, dass der Bridge Controller des M.2 USB Adapters zu langsam aufwacht oder schlicht einen Bug hat. Diese Controller sind eh so eine Sache, da sie nicht alle Befehle durchlassen und zb auch kein Standby unterstützen. Deswegen werden die M.2 mega heiß in den Adaptern. Ich habe selbst so einen Zuhause (und insgesamt drei verschiedene getestet). Du verballert also alleine mit so einem Adapter locker 5W und mehr. Steckt die M.2 mal in den WiFi Slot. Du kannst sie zwar nicht festschrauben, aber gehen könnte sie trotzdem. Wenn nein bzw dir das zu doof ist, bleibt nur eine SATA SSD oder ein SLC USB Stick. Das Asrock J5005 unterstützt übrigens günstige SATA Port Multiplier (sofern die die Ports nicht reichen). Siehst du in meinem Video: https://forums.unraid.net/topic/97477-jäger-der-verlorenen-festplatte/

Nein. Die werden per Mover bewegt. Ich sichere per RSYNC die Daten, die permanent auf der SSD verbleiben. Dazu gehört bei mir appdata, domains und system. Also alles was die VMs und Docker betrifft. Außerdem liegt meine Musik-Sammlung permanent auf der SSD, damit diese latenzfrei abgespielt werden kann (und keine HDD deswegen laufen muss = stromsparend). Diese Daten sichere ich zeitgesteuert und inkrementell mit diesem RSYNC Skript. Wenn sie per USB verbunden ist, kann sie nach dem Backup per Skript getrennt werden: https://unix.stackexchange.com/a/83587/101920 Man muss sie also von Hand wieder per USB verbinden, damit sie wieder verfügbar ist. Eine Alternative wäre die USB Platte zu verschlüsseln. Ich habe das Video noch nicht angeschaut, aber das scheint es zu erklären: https://www.youtube.com/watch?v=tGmIzX3Fncs Ich für meinen Teil habe die Disk ständig verbunden. Der Share heißt "Backup" und kein User wurde diesem Share zugewiesen. Es kann also nur der Root-User über die WebGUI auf diese Platte zugreifen. Das ist so lange gegen Ransomware sicher, solange Unraid keine Sicherheitslücke besitzt. Darauf vertraue ich und es ist mir so gesehen auch "egal", da ich alle Daten auf einen zweiten Unraid Server an einem anderen Standort sichere. Von Hand. Also Ordner auf der SSD löschen und vom Backup zurückkopieren. Ich nutze dann einfach das Terminal und das "cp" Kommando. Man könnte aber auch einen Dateiexplorer per Container nutzen. Ja, das ist besser, weil man auch einen permanenten Ausfallschutz hat. Ich kann aber damit leben, dass die Daten der letzten 8 Stunden verloren gehen (als der Mover noch nicht aktiv war), weil ich in der Regel keine Dateien vom Client auf das NAS verschiebe, sondern nur kopiere. Ich habe zwar eben noch eine Blu-Ray direkt aufs NAS gerippt und es dauert bis zu 8 Stunden bis die im Array liegen, aber die Blu-Ray habe ich ja noch. Dann muss ich sie eben neu rippen. Aber klar, optimal ist natürlich ein RAID1/5 als SSD Cache.

Dann hast du dich aber nicht an meine Anleitung gehalten. Ich hatte extra geschrieben: Schäm dich 😘 Ich würde sagen, dass man quasi alles nehmen kann, das kein QLC verwendet. Also die Intel 660p, Crucial P1/P2 oder Samsung 870 QVO würde ich zB nicht nehmen. Ansonsten sollten alle auch beim Hochladen großer Datenmengen deutlich über 1G LAN liegen. Bei der Haltbarkeit kommt es auf die TBW an. Also das was der Hersteller im Zeitraum X an Traffic garantiert. Bei der 870 QVO sind es zB 360 TBW in 3 Jahren und bei der 970 Evo 600 TBW in 5 Jahren. Längere Garantie gepaart mit hoher TBW machen schon Sinn für einen Schreibcache. Die 970 Pro hat sogar 1200 TBW, aber die macht meiner Ansicht nach keinen Sinn, weil sie exakt das Doppelte der Evo kostet (wenn nicht sogar mehr). Also sollte die Evo irgendwann kaputt gehen, sind die SSDs wieder im Preis gefallen und man holt sich eine neue mit ebenfalls 600 TBW und hat den besseren Deal gemacht. Stell dir einfach einen Deal-Alarm bei MyDealz ein und lese den einen oder anderen Kommentar. Dann weißt du auch direkt ob die gerade angebotene SSD was taugt: https://www.mydealz.de/search?q=1tb%2Bnvme

Habe ich gerade getestet. Ist nerviger, weil man mehr rumklicken muss und man muss auch drei Sicherheitsfragen hinterlegen. Aber es stimmt, der wird dann auch mit der Option "Kennwort läuft nie ab" angelegt. Ich mache es über rechte Maustaste -> Windows Logo -> Computerverwaltung, also das was du mit MSC meinst. Man muss nur eben an die Optionen denken.