Eigenbau-NAS: Mein Unraid-Setup für maximale Übersicht und Performance

Richie Müller

24.7.2025

Bilder: David Lee

Mein Unraid-Server ist installiert. Doch bevor Docker-Container oder Apps Einzug halten, braucht mein NAS Struktur. In diesem Teil erkläre ich, wie ich die Cache-Pools aufteile, das Array starte und die Datenablage sauber organisiere. Und weshalb dabei auch Strategie gefragt ist.

Im letzten Blog-Beitrag habe ich das Unraid-Betriebssystem auf einem USB-Stick installiert, der dauerhaft in meinem NAS stecken bleibt.

Jetzt geht es an die Feinabstimmung. Denn «TomBombadil», so heisst mein Unraid-Server, soll als künftiges Forschungslabor dienen. In diesem Artikel erfährst du, welche Überlegungen und Gedanken dabei eine Rolle gespielt haben. Eine Schritt-für-Schritt-Anleitung findest du hier nicht. Davon gibt es bereits mehr als genug auf YouTube.

Ich logge mich zum ersten Mal ein und lande auf der Unraid-Benutzeroberfläche. Um etwaige Probleme später zu vermeiden, habe ich es mir zur Angewohnheit gemacht und handhabe es auch hier so: Ich aktualisiere als Erstes das Betriebssystem auf die neueste Version und stelle die korrekte Zeitzone ein.

Zwei Cache-Pools: Trennen, was unterschiedliche Aufgaben hat

Bevor ich Freigaben (Shares) anlege, nehme ich mir einen Moment Zeit. Denn die Datenstruktur entscheidet nicht nur über Übersichtlichkeit, sondern auch über Leistung und Zuverlässigkeit des Systems. Meine Entscheidung hat zudem einen Einfluss auf Redundanz und die langfristige Wartbarkeit des Servers.

Ich habe insgesamt vier Solid State Drives (SSD) eingebaut: Zwei à zwei Terabyte (TB) und je zwei à 500 Gigabyte (GB). Im ersten Moment bin ich versucht, alle in einen einzigen Cache-Pool zu schmeissen. Doch bei unterschiedlichen Grössen der SSDs verschenke ich mit RAID 1 (Festplattenverbund mit Ausfallsicherheit) schnell unnötig Kapazität – im schlimmsten Fall mehr als die Hälfte des Platzes.

Denn der RAID-1 spiegelt die Daten immer paarweise zwischen zwei Laufwerken. Dabei nutzt es nur so viel Kapazität, wie auf beiden beteiligten SSDs zur Verfügung steht. Ist nun eines der Laufwerke kleiner, wird der überschüssige Speicherplatz der grösseren SSD ignoriert.

Ich setze deshalb auf zwei getrennte Pools mit gleich grossen SSDs, jeweils im BTRFS-RAID 1. Ich nutze B-Tree File System (BTRFS), weil es in Unraid die beste Option für redundante SSD-Pools ist, mit Fehlererkennung und flexibler Verwaltung:

• SSD-Cache-Pool 1 (cache): 2 × 2 TB NvmE-SSDs im RAID 1: Dies ist ideal für die Datenzwischenspeicherung von Docker-Container, AppData, Virtuelle Maschinen – also alles, was ständig aktiv ist und schnelle Zugriffe benötigt.

• SSD-Cache-Pool 2 (cache_fast): 2 × 500 GB SATA-SSDs im RAID 1: Für temporäre Daten wie Downloads, «Durchlauferhitzer»-Daten wie Inboxen von Paperless ngx oder Backup-Zwischenablagen.

ZFS oder BTRFS? Die Frage nach dem passenden Dateisystem

Dateisysteme wie ZFS oder BTRFS regeln, wie Daten auf einem Laufwerk gespeichert, organisiert und gesichert werden. Sie übernehmen eine ähnliche Rolle wie FAT32 oder NTFS unter Windows. Sie bieten jedoch zusätzliche Funktionen wie Prüfsummen, Snapshots und native RAID-Unterstützung. Diese sind vor allem für Server und NAS-Systeme relevant.

Ich habe mich bewusst gegen ZFS (ursprünglich Zettabyte File System) entschieden, obwohl es technisch vieles richtig macht. Und gegen ext4 (fourth extended file system), da es keine erweiterten Funktionen bietet. Bei Cache-Pools will ich flexibel bleiben. Ein ZFS-Pool lässt sich nicht so leicht erweitern. Ist er beispielsweise als Mirror (RAID 1) angelegt, kann ich später nicht einfach eine einzelne SSD hinzufügen.

Stattdessen müsste ich wieder zwei gleich grosse SSDs einbauen. Bei RAID-Z, einer RAID-Variante, die es ausschliesslich für ZFS gibt, wird es sogar noch starrer: Die ursprüngliche Struktur ist fix. Mehr Speicher gibt es nur, wenn ich mehrere neue Festplatten gleichzeitig einbaue.

Auch bei unterschiedlich grossen SSDs ist ZFS sperrig: Es nutzt nur so viel Speicher, wie die kleinste Festplatte Platz bietet. Der Rest bleibt ungenutzt. Gerade bei Cache-Pools ist das verschenktes Potenzial.

BTRFS ist da deutlich entspannter: Ich kann SSDs einfacher austauschen oder ergänzen. Das geht zudem mit verschiedenen Kapazitätsgrössen. Das grosse Plus: Die Redundanz bleibt erhalten und ich habe weiterhin eine gute Übersicht. Unraid bringt BTRFS nativ mit, kein Plugin, kein Zusatzaufwand. Für mein Setup, das sich mit der Zeit weiterentwickeln soll, genau die richtige Wahl.

Die klare Trennung bringt Struktur und Ordnung, aber auch Sicherheit, verhindert Engpässe bei gleichzeitigen Zugriffen. Hinzu kommt, dass ich bei Bedarf problemlos weitere Freigaben in die bestehende Struktur einbinden kann.

Das Array: 4 × 6 TB und 2 × Parity = 24 TB netto und ruhiger Schlaf

Meine sechs Festplatten à 6 TB teile ich klassisch auf: zwei Festplatten als Parity (Redundanzdatenlaufwerk), vier als Daten-Laufwerke. Damit stehen mir netto 24 TB Speicherkapazität zur Verfügung. Zudem bin ich gegen den Ausfall von bis zu zwei Disks abgesichert. Alle vier Datenplatten laufen mit eXtents File System (XFS). Das ist in Unraid Standard. Dieses Dateisystem ist stabil, bewährt und besonders effizient bei grossen Dateien wie Medien oder Backups.

Unraid verfolgt dabei ein eigenes Konzept: Anders als bei RAID oder klassischen «Just a Bunch of Disks» (JBOD) bleibt jede Datenplatte einzeln lesbar. Das Ganze ist durch ein Parity Verfahren abgesichert. Dieses kann den Ausfall von bis zu zwei Laufwerken abfedern. Zusätzlich kann ich Backups auf einer externen Festplatte ablegen.

Shares mit Struktur

Ich will von Anfang an wissen, wo was liegt – und vor allem warum. Folglich bekommen meine wichtigsten Verzeichnisse klare Regeln:

Die Cache-Modi lassen sich für jede Freigabe individuell festlegen. Unraid erlaubt es bei jedem Share, genau zu definieren, ob und wie der Cache genutzt wird. Dabei stehen dir vier Optionen zur Wahl:

• only: Der Share liegt ausschliesslich auf dem Cache-Pool (z. B. für Docker oder VMs).
• prefer: Der Share wird bevorzugt auf dem Cache gespeichert, weicht bei Platzmangel aber ins Array aus.
• yes: Neue Daten landen zuerst auf dem Cache und werden später automatisch ins Array verschoben.
• no: Der Cache wird ignoriert – alle Daten landen direkt im Array. Der sogenannte «Mover» sorgt im Hintergrund dafür, dass Daten wie geplant verschoben werden – bei mir passiert das im Abstand von jeweils 6 Stunden.

Temporäre Daten landen also zuerst auf den SSDs und werden später automatisch ins Array verschoben. Container- oder VM-Daten bleiben hingegen fest in den Cache-Pools. Dort bekommen sie die Leistung, die sie brauchen.

Für weitere Performance-Steigerung sorgt der Arbeitsspeicher: Unraid verwendet freien RAM automatisch als Lese- und Schreib-Cache («Buffer Cache»), um häufig genutzte Daten noch schneller bereitzustellen und die SSDs zu entlasten.

In meinem Eigenbau-NAS sind insgesamt 128 GB RAM verbaut. In den Unraid-Einstellungen habe ich festgelegt, dass maximal 75 Prozent des verfügbaren Speichers für die Caches verwendet werden dürfen. Das sind also maximal 96 GB RAM. Das geschieht über die Einstellung vm.dirty_ratio, die ich in der Konsole wie folgt angepasst habe:

sysctl -w vm.dirty_ratio=75

So bleibt genug Puffer für Docker, VMs und andere Prozesse. Gleichzeitig profitieren datenintensive Dienste wie beispielsweise Paperless NGX oder Nextcloud spürbar von kürzeren Zugriffszeiten.

Würde dieser RAM-Cache nicht genutzt werden, müssten alle Lese- und Schreibzugriffe direkt über die SSDs abgewickelt werden. Dies ist zwar auch noch schnell genug, aber auf Dauer weniger effizient und kann zu höherem Verschleiss der SSDs führen.

Unraid gibt den Speicher automatisch wieder frei, sobald er aktiv von anderen Prozessen benötigt wird. Der Cache nutzt also nur den Arbeitsspeicher, der gerade nicht anderweitig gebraucht wird. Hier findest du ein YouTube-Video, das die Konfiguration von «Buffer Cache» erklärt:

Das Array starten – der Moment der Wahrheit

Nachdem ich die Datenstruktur festgelegt und die Cache-Pools eingerichtet habe, weise ich die Laufwerke im Unraid-Webinterface zu: zwei Parity-Disks, vier Datendisks und die SSDs den jeweiligen Cache-Pools. Unraid zeigt danach mit einem grünem Bullet Point an, dass der Status OK ist.

Nach dem Klick auf «Start» initialisiert Unraid das Array, überprüft die Zuweisungen und bereitet das Dateisystem vor. Auf den ersten Blick passiert nicht viel – ausser, dass sich der Status ändert und eine Formatierungsoption erscheint.

Für alle Datenlaufwerke wähle ich XFS als Dateisystem, für die Cache-Pools BTRFS. Ich bestätige die Formatierung der Datenträger – dann heisst es: warten.

Gerade wenn zwei Parity-Disks eingerichtet werden, dauert die Berechnung. Je nach Grösse der Festplatten kann das mehrere Stunden bis Tage in Anspruch nehmen. Das System ist während dieser Zeit voll bedienbar, aber die Performance ist eingeschränkt. Ich habe den Prozess über Nacht laufen lassen.

Tipp: Wenn du neugierig bist, kannst du den Fortschritt in Echtzeit im Webinterface beobachten. Unraid zeigt sehr transparent, was gerade geschieht – inklusive Geschwindigkeit und voraussichtlicher Restdauer.

Am nächsten Morgen war es dann so weit: Das Array ist bereit – und damit ist mein NAS offiziell im Einsatz.

Zwei SSD-Pools, ein stabiles Array und eine bewusst gewählte Datenstruktur – mein Eigenbau-NAS hat jetzt nicht nur Leistung, sondern auch einen klaren Plan.

Backup nicht vergessen: USB-Stick als zentrale Lebensversicherung

Nach dem ersten erfolgreichen Start des Arrays und der Cache-Pools habe ich etwas getan, das man leicht übersieht – aber dringend tun sollte: Ich habe ein erstes Backup des USB-Sticks erstellt.

Bekanntlich speichert Unraid alle wichtigen Konfigurationen auf dem USB-Stick, auf dem sich auch das Betriebssystem befindet. Fällt dieser aus, ist das System zwar nicht verloren, aber die Wiederherstellung kostet Nerven. Zeit? Eher nicht. Die Konfiguration lässt sich rasch auf einen neuen USB-Stick kopieren, Backup sei Dank.

Ich habe das Backup auf meiner Synology gesichert. Weiter kann ich mein Key File in meinem Unraid-Benutzerkonto bei Bedarf herunterladen. Ein komplettes Backup ist mit einem speziellen Plugin auch möglich. Mit welchem, verrate ich dir im nächsten Artikel.

Mein Eigenbau-Server ist jetzt nicht nur funktionstüchtig, sondern auch bereit für Erweiterungen. Docker, VMS, Community-Apps und Plugins stehen schon in den Startlöchern. Darum geht es im nächsten Teil der Serie.

Richie Müller

Teamleader Editorial

Richard.Mueller@digitecgalaxus.ch

Journalist mit mehr als 20 Jahren Erfahrung – mehrheitlich im Online-Journalismus in verschiedenen Positionen. Mein Hauptarbeitsinstrument? Ein Notebook – am besten mit Internetverbindung. Diese Geräte haben es mir so sehr angetan, dass ich Notebooks und Computer immer wieder auch gerne auseinanderschraube, repariere und neu aufsetze. Warum? Weil es Spass macht! mehr

Folgen

---

Computing

Folge Themen und erhalte Updates zu deinen Interessen

Thema folgen

---

Netzwerk

Folge Themen und erhalte Updates zu deinen Interessen

Thema folgen

Diese Beiträge könnten dich auch interessieren