- Das klassische Unraid-Array speichert jede Datei komplett auf einer einzelnen Festplatte und erlaubt dadurch, Platten unterschiedlicher Größe zu mischen und später einzeln zu erweitern.
- Ein ZFS-Pool prüft jeden gespeicherten Datenblock mit einer Prüfsumme und kann beschädigte Daten bei vorhandener Redundanz selbst reparieren – dafür sind die Anforderungen an die Festplatten strenger.
- Seit Unraid OS 7.2 lässt sich ein ZFS-Pool per Weboberfläche nachträglich um eine Platte erweitern, ohne alles neu aufzusetzen – ein früherer Hauptkritikpunkt an ZFS ist damit entschärft, wenn auch nicht komplett verschwunden.
- Die Entscheidung hängt vor allem davon ab, wie du Festplatten kaufst: nach und nach einzeln, oder gleich als kompletten Satz gleich großer Platten.
Wer sich einen eigenen Netzwerkspeicher baut – ein NAS (Network Attached Storage, also ein Speicher, der am Netzwerk hängt) – landet bei Unraid früher oder später vor derselben Frage: Bleibe ich beim klassischen Unraid-Array, oder nehme ich gleich einen ZFS-Pool? Seit Unraid OS 7.0 ist ZFS als vollwertiges Dateisystem eingebaut, nicht mehr nur über Zusatz-Plugins nachgerüstet. Damit ist die Frage plötzlich für viel mehr Leute relevant, nicht nur für Nutzer von TrueNAS SCALE, wo ZFS schon lange Standard ist.
Ein Beispiel, an dem sich die Entscheidung festmacht
Stell dir zwei Leute vor, die beide einen Server für Fotos, Backups und ein bisschen Medienbibliothek bauen wollen.
Person A hat schon eine 4-TB-Platte aus dem alten PC übrig und kauft sich nach und nach weitere Platten dazu, wenn Geld und Platz im Gehäuse es hergeben – mal eine große, mal eine kleinere im Angebot. Person B will von Anfang an einen sauberen, redundanten Verbund aufbauen und kauft direkt vier gleich große Festplatten.
Für Person A ist das Unraid-Array fast automatisch die bessere Wahl: Beim Array liegt jede Datei komplett auf einer einzelnen Platte, es gibt kein Striping (das Verteilen einer Datei über mehrere Platten gleichzeitig). Dadurch dürfen die Datenplatten unterschiedlich groß sein – nur die Paritätsplatte, die im Fehlerfall die Wiederherstellung ermöglicht, muss mindestens so groß sein wie die größte Datenplatte. Fällt eine einzelne Datenplatte aus, sind auch nur die Dateien betroffen, die genau auf dieser Platte lagen – der Rest des Arrays bleibt unangetastet.
Für Person B spricht mehr für einen ZFS-Pool. ZFS bringt eigene RAID-Level mit – RAIDZ1, RAIDZ2, RAIDZ3 sowie gespiegelte Verbünde (Mirror) – und rechnet für jeden einzelnen Datenblock eine Prüfsumme aus. Bei einer Abweichung und vorhandener Redundanz repariert sich der Pool selbst („Self-Healing“), zusätzlich bringt ZFS Snapshots (Zeitpunkt-Sicherungen des Dateisystems) und Kompression gleich mit.
Der Praxis-Haken: Marktlage 2026
Genau die „kaufe einfach eine weitere Einzelplatte nach“-Strategie von Person A ist 2026 schwerer geworden als noch vor zwei Jahren. Die Nachfrage aus KI- und Rechenzentren hat die Preise für Festplatten spürbar nach oben getrieben, bei gängigen Modellen je nach Quelle zwischen 23 und 66 Prozent. Western Digital meldet die HDD-Produktion für 2026 praktisch als ausverkauft, große Cloud-Anbieter haben sich Kapazitäten teils bis 2028 gesichert. Hersteller setzen eher auf höhere Kapazität pro Laufwerk als auf mehr Stückzahl – für Homelab-Käufer heißt das: einzelne, günstige Platten sind knapper geworden. Das Array-Argument „einfach nachkaufen“ bleibt technisch richtig, ist aber finanziell und planerisch nicht mehr ganz so bequem wie früher.
Was RAIDZ-Expansion am alten ZFS-Nachteil ändert
Lange war der größte Kritikpunkt an ZFS: Ein bestehender RAIDZ-Verbund ließ sich nicht einfach um eine Platte erweitern, nur durch komplettes Neuanlegen und Zurückkopieren aller Daten. Mit der RAIDZ-Erweiterung aus OpenZFS 2.3 – dem quelloffenen Projekt hinter ZFS, openzfs.org – lässt sich inzwischen einfach eine weitere Platte zu einem bestehenden RAIDZ1/2/3-Verbund hinzufügen. In Unraid ist das seit der Beta von 7.2.0 nutzbar und seit dem stabilen Release im Oktober 2025 fest im WebGUI verankert.
Ein wichtiges Detail dabei: Alte, bereits gespeicherte Daten werden bei so einer Erweiterung nicht neu verteilt. Ein vierfacher RAIDZ1-Verbund, der um zwei Platten auf sechs erweitert wird, behält für die alten Daten weiter das ursprüngliche Verhältnis von Nutzdaten zu Paritätsdaten. Den vollen Kapazitätsgewinn bekommst du erst, wenn diese Daten neu geschrieben werden – etwa durch Kopieren mit den ZFS-Bordmitteln oder einfach durch normale Datenrotation über die Zeit. Laut einem der OpenZFS-Entwickler wäre ein nachträgliches komplettes Neuverteilen („Restriping“) ähnlich aufwendig wie die Erweiterungsfunktion selbst – deshalb gibt es diese Einschränkung bewusst.
Array und Pool im direkten Vergleich
| Kriterium | Unraid-Array | ZFS-Pool |
|---|---|---|
| Plattengrößen mischen | Ja, beliebig – Parität muss nur ≥ größte Datenplatte sein | Eingeschränkt durch die Vdev-Struktur |
| Erweiterung um eine Platte | Jederzeit, einzelne Platte hinzufügen | Seit Unraid 7.2 per RAIDZ-Expansion möglich, Altdaten profitieren erst nach Neuschreiben voll |
| Schutz vor stiller Datenkorruption (Bitrot) | Nein – Standard-XFS auf den Datenplatten prüft keine Blockchecksummen | Ja – Prüfsumme pro Block, Self-Healing bei Redundanz |
| Ausfall einer Platte | Betrifft nur die Dateien auf genau dieser Platte | Abhängig vom gewählten RAID-Level und der vorhandenen Redundanz |
| Spindown im Leerlauf | Funktioniert zuverlässig, einzelne Platten können separat schlafen | Funktioniert bisher kaum – Platten laufen meist gemeinsam |
| Minimale Konfiguration | Grundsätzlich auch eine einzelne Platte ohne Parität möglich (ohne Redundanz), ob das uneingeschränkt auch für aktuelle Versionen gilt, ist nicht abschließend bestätigt | Für Redundanz mindestens 2 Platten im Mirror nötig |
Der Bitrot-Punkt, den viele unterschätzen
Ein Missverständnis hält sich hartnäckig: dass die wöchentliche Parity-Check-Routine des Unraid-Arrays ähnlich schützt wie die ZFS-Checksummen. Das stimmt nicht. Der Parity-Check erkennt, ob Daten- und Paritätsplatte noch zueinander passen – also vor allem Komplettausfälle oder Inkonsistenzen. Eine stille Beschädigung einzelner Blöcke innerhalb einer einzelnen, technisch einwandfrei laufenden Platte – umgangssprachlich Bitrot genannt – bemerkt das Standard-Array mit XFS dagegen nicht. Genau das ist die Domäne von ZFS. Mit Unraid OS 7.3.0 zeigt die Weboberfläche beschädigte Dateien und Checksummen-Fehler in ZFS-Pools inzwischen sogar direkt an, ohne dass vorher manuell ein Scrub (eine vollständige Prüfung aller Daten) gelaufen sein muss.
Wer eine einzelne ZFS-formatierte Platte direkt im Unraid-Array betreibt, bekommt übrigens nicht automatisch alle ZFS-Vorteile: Ohne echten Pool-Verbund aus mehreren Platten gibt es weder gemeinsame Redundanz noch Self-Healing über mehrere Platten hinweg – die einzelne Platte wird dann einfach separat verwaltet.
ECC-RAM und andere Mythen
Ein weiterer verbreiteter Irrtum: ZFS brauche unbedingt ECC-RAM (Arbeitsspeicher mit eingebauter Fehlerkorrektur), sonst drohten Totalschäden am Datenbestand. Das OpenZFS-Projekt selbst weist das als Mythos zurück – ZFS ist auf ECC-RAM nicht stärker angewiesen als jedes andere Dateisystem auch. Wer sich um Datensicherheit sorgt, sollte nach Priorität eher in dieser Reihenfolge investieren: zuerst ein echtes Backup, dann ein Dateisystem mit Prüfsummen wie ZFS, dann eine USV (unterbrechungsfreie Stromversorgung) gegen Stromausfälle, erst danach ECC-RAM.
WD Red Plus 8 TB NAS Interne Festplatte
Für einen ZFS-Pool im Mirror-Verbund brauchst du mindestens zwei gleich große Platten – eine NAS-Festplatte wie diese eignet sich als Baustein für einen sauber geplanten Pool.
Lizenzkosten mitdenken
ZFS-Unterstützung ist inzwischen fest in Unraid eingebaut, kostet also keinen Aufpreis mehr – die Lizenz selbst richtet sich nach der Zahl der angeschlossenen Geräte. Unraid bietet aktuell die Tiers „Starter“ (49 US-Dollar, bis 6 Geräte), „Unleashed“ (109 US-Dollar, unbegrenzte Geräte) und „Lifetime“ (249 US-Dollar, unbegrenzte Geräte, lebenslange Updates ohne Verlängerungsgebühr) an, jeweils mit einem Jahr Updates inklusive bei den ersten beiden Stufen. Konkrete Euro-Preise oder aktuelle Rabattaktionen sind hier nicht verifiziert – die genannten Beträge sind US-Dollar-Listenpreise.
Fazit: Wonach du wirklich entscheiden solltest
Zurück zum Beispiel vom Anfang: Person A, die Platten nach und nach und in unterschiedlichen Größen kauft, fährt mit dem klassischen Unraid-Array besser – flexibel, einfach erweiterbar, mit der Einschränkung, dass stille Datenkorruption unbemerkt bleiben kann. Person B, die von Anfang an einen sauberen, redundanten Verbund aus möglichst gleich großen Platten aufbaut und Wert auf Selbstheilung und Snapshots legt, ist mit einem ZFS-Pool besser bedient – muss dafür aber akzeptieren, dass die Platten im Pool meist gemeinsam laufen müssen und Spindown im Leerlauf bisher kaum zuverlässig funktioniert. Wer beides will, kann in Unraid auch beides parallel betreiben: das Array für flexible Einzelplatten, einen zusätzlichen ZFS-Pool für die Daten, bei denen Checksummen und Self-Healing wirklich zählen.