ZFS Hardware-Anforderungen 2026: RAM, ECC, HBA, SLOG
· Zuletzt geprüft Juli 2026
ZFS hat den Ruf, Server-Eisen zu fressen, und dieser Ruf ist zur Hälfte wahr und zur Hälfte Folklore, die in fünfzehn Jahren Forenthreads erhärtet ist. Der wahre Teil ist real: ZFS macht mit Speicher und Platten bestimmte Dinge, die gewöhnliche Dateisysteme nicht tun, weshalb ein paar Hardware-Entscheidungen weit mehr wiegen als auf einer ext4-Kiste. Der Folklore-Teil ist genau das, was Erstbauer zum Überkaufen treibt, etwa der Glaube, ZFS brauche 1 GB RAM pro TB, oder ein Scrub zerstöre ohne ECC den Pool. Dieser Artikel trennt beides, geht jede Komponente durch, die ZFS wirklich interessiert, und endet mit konkreten Empfehlungen für drei typische Workloads. Wenn du das größere Bild suchst, wie ZFS gegen Unraid oder eine Synology-Appliance steht, steht das im NAS-Hardware Ratgeber; hier gehen wir eine Ebene tiefer in die ZFS-Kiste selbst.
Wie ZFS RAM nutzt: der ARC und der "1 GB pro TB"-Mythos
Das Erste, was du verstehen musst: ZFS behandelt freien Speicher als Lese-Cache, nicht als Reserve, die du leer halten sollst. Dieser Cache ist der Adaptive Replacement Cache, kurz ARC, und er ist klüger als ein einfacher Most-Recently-Used-Cache, weil er kürzlich genutzte gegen häufig genutzte Daten abwägt, weshalb sich ein warmer ZFS-Pool selbst auf drehenden Platten flott anfühlt. Wenn eine ZFS-Kiste fast ihr ganzes RAM "belegt", ist das der ARC bei der Arbeit, und der Speicher geht sofort zurück, sobald eine Anwendung ihn braucht. Mehr RAM kauft also vor allem schnellere Reads, keine größere Sicherheitsreserve, weshalb die Frage nie lautet "wie wenig geht", sondern "wie viel Cache ist mir der Preis wert".
Diese Sicht räumt mit dem meistwiederholten Mythos der ZFS-Welt auf, der Idee, du müsstest 1 GB RAM je TB Pool vorhalten. Das war nie eine harte Regel, und die Zahl, die tatsächlich mit der Kapazität skaliert, ist Deduplizierung, die der TrueNAS-Hardware-Guide auf rund 5 GB RAM je TB dedupliziertem Datenbestand beziffert. Für einen normalen Pool ohne Dedup behandelt derselbe Guide 8 GB als Arbeitsuntergrenze und weist die meisten Builds Richtung 16 GB, weshalb ein 40-TB-Heim-Media-Pool bestens mit 16 oder 32 GB läuft statt mit den 40 GB, die die Faustregel fordern würde. Wenn du dich je gefragt hast, wie ZFS bei genau dieser Frage gegen ext4 und Btrfs steht, legt unser Vergleich ZFS vs ext4 vs Btrfs offen, was der RAM-Hunger dir tatsächlich bringt.
Wo mehr RAM wirklich zahlt, ist enger als viele denken: Dedup wie oben, metadatenlastige Pools mit Millionen kleiner Dateien, wo der ARC sein Budget in Verzeichnisstruktur statt in Daten steckt, und Mehrbenutzer- oder Virtualisierungs-Workloads, bei denen viele Clients gleichzeitig auf den Pool gehen und ein größerer Cache die Trefferquote hebt. Für eine Single-User-Plex-Bibliothek oder ein Foto-Archiv sind 16 GB reichlich und 32 GB bequeme Absicherung; darüber hinaus fährst du meist besser, wenn du in Platten statt in weitere DIMMs investierst. Kurz gesagt: Starte bei 16 GB für einen Heim-Pool, geh auf 32 GB bei vielen Nutzern oder VMs, und jage einer Pro-TB-Zahl nur nach, wenn du Dedup bewusst einschaltest.
ECC-RAM: die ehrliche Fassung einer lauten Debatte
Kein ZFS-Thema erzeugt mehr Hitze als ECC-Speicher, also hier die ruhige Version. ECC-Speicher korrigiert lautlos die Single-Bit-Fehler, die Hintergrundstrahlung und schwache Chips gelegentlich verursachen, und zwar bevor das falsche Bit deine Daten je erreicht. Für ZFS zählt das, weil seine berühmten Checksummen Daten auf dem Weg zur und von der Platte schützen, aber einen Wert nicht schützen können, während er im RAM auf das Schreiben wartet; kippt dort ein Bit, berechnet ZFS brav eine korrekte Checksumme für die nun beschädigten Daten und speichert beides. ECC schließt genau diese Lücke, weshalb es das eine Speicher-Upgrade ist, das auf einem integritätsorientierten Build ernst zu nehmen ist.
Was ECC nicht ist, ist eine harte Pflicht. OpenZFS selbst beschreibt ECC als hoch empfohlen, und seine FAQ beantwortet die Frage "muss ich ECC nutzen" mit einem klaren Nein und ergänzt, dass ZFS auf Nicht-ECC-Speicher nicht gefährlicher ist als jedes andere Dateisystem auf Nicht-ECC-Speicher. Der oft zitierte "Scrub of Death", die Behauptung, ein einzelnes defektes DIMM plus ein Scrub kaskadiere in totalen Poolverlust, ist ein Mythos: Ein Scrub schreibt nur Blöcke neu, deren On-Disk-Checksumme wirklich versagt, und er verifiziert seine eigenen Reparaturen erneut. ECC lohnt sich also auf einem Build, dessen ganzer Zweck Daten sind, die du nicht neu herunterladen kannst, und ist auf einer Media-Kiste, deren Pool ohnehin nur eine Kopie ist, gut verzichtbar. Welche Plattformen es unterstützen und wo es in deiner Prioritätenliste steht, behandeln wir ausführlich in ECC-RAM für NAS und ZFS. Kurz gesagt: Kauf ECC, wenn die Daten unersetzlich sind und das Board es kann, aber lass dich vom Fehlen von ECC nicht vom ZFS-Einsatz abhalten, denn ZFS mit Checksummen und Backup schlägt ein schlichtes Dateisystem ohne beides.
Gib ZFS die Platten direkt: ein HBA, kein Hardware-RAID
ZFS verwaltet Redundanz, Checksummen und Reparatur selbst, was bedeutet, dass es jede Platte als rohes Gerät sehen muss statt durch einen Controller, der schon Entscheidungen für es getroffen hat. Bei diesem Punkt ist OpenZFS am deutlichsten: Seine Hardware-Notizen sagen klar, dass Hardware-RAID-Controller nicht mit ZFS verwendet werden sollten und ein HBA für Performance wie Zuverlässigkeit die bessere Wahl ist. Eine Hardware-RAID-Karte versteckt die einzelnen Platten hinter eigener Logik und eigenem Cache, sodass ZFS die direkten SMART-Daten, die Timing-Kontrolle und die ehrliche Fehlermeldung verliert, auf die es für seine Arbeit angewiesen ist.
In der Praxis heißt das ein Host-Bus-Adapter, eine Karte, deren einzige Aufgabe es ist, Platten-Ports zu ergänzen und jede Platte unverändert durchzureichen. Der Homelab-Standard ist eine LSI/Broadcom-SAS-Karte wie der Broadcom 9300-8i, ein PCIe-x8-Adapter für acht Platten. Beim Gebrauchtkauf zählt vor allem die Firmware: Viele dieser Karten kommen im IR-Mode (Integrated RAID) und müssen auf IT-Mode (Initiator Target) geflasht werden, was die RAID-Logik entfernt und die Karte zum reinen Pass-through-Controller macht. Eine bereits auf IT-Mode geflashte Karte spart dir das Flashen, und unser Vergleich Hardware-RAID vs Software-RAID erklärt, warum der Pass-through-Ansatz der ist, den jeder moderne ZFS-Build will.
Zwei billigere Abkürzungen solltest du aus demselben Grund meiden. Onboard-"RAID", also der Intel-RST- oder AMD-RAIDXpert-Modus im BIOS, ist Fake-RAID, das Platten hinter einem Treiber versteckt, also lass den SATA-Controller im schlichten AHCI und lass ZFS die Platten besitzen. Die Port-Splitter-Boards, die acht Platten aus zwei SATA-Ports versprechen, stützen sich auf SATA Port Multiplier, und OpenZFS warnt, dass deren Unterstützung inkonsistent ist und SATA-Platten nie ohne SAS-Interposer in einen SAS-Expander gehören. Kurz gesagt: Sobald du die vier bis sechs SATA-Ports des Boards überschreitest, kommt ein echter HBA im IT-Mode statt Fake-RAID oder Port Multiplier, und ZFS spricht mit dem blanken Blech.
SLOG: ein separates ZIL, für das dir nur Sync-Writes danken
Das SLOG ist das meistmissverstandene ZFS-Zubehör, also hilft es, mit dem zu beginnen, was es nicht ist. Jeder ZFS-Pool hat bereits ein ZIL, das ZFS Intent Log, in dem der Pool Writes vermerkt, die eine Anwendung sofort dauerhaft haben will, bevor er sie bestätigt. Ein SLOG (Separate Log) verschiebt dieses Log nur von den Hauptplatten auf ein schnelles, dediziertes Gerät, und hier ist der Haken, über den viele stolpern: Es hilft nur synchronen Writes. Die TrueNAS-SLOG-Referenz ist eindeutig, dass das ZIL asynchrone Writes standardmäßig nicht behandelt, weshalb genau die Workloads profitieren, die auf jeder Operation Dauerhaftigkeit verlangen, nämlich NFS-Datastores, VM- und iSCSI-Storage sowie Datenbanken.
Zwei Eigenschaften zählen, wenn du wirklich eines brauchst. Erstens muss das Gerät Power-Loss-Protection haben, weil der ganze Sinn eines SLOG ist, als dauerhaft zugesagte Writes bei einem Stromausfall mitten in der Transaktion nachzuspielen; das sind die Onboard-Kondensatoren, mit denen eine Enterprise-SSD ihre laufenden Writes nach einem Stromabriss noch fertigschreibt, und eine billige Consumer-SSD ohne sie macht den ganzen Zweck zunichte. Zweitens darf es klein sein, weil es nur ein paar Sekunden Writes hält: TrueNAS empfiehlt ein 16-GB-Gerät, idealerweise überprovisioniert aus einer größeren High-Endurance-SSD, um den Verschleiß zu verteilen. Was du nicht brauchst, ist ein SLOG für ein Heim-NAS, das SMB-Freigaben und Media bedient, denn diese Writes sind asynchron und berühren das ZIL nie, weshalb das Geld weit besser in RAM oder Platten steckt. Kurz gesagt: Ein SLOG mit Power-Loss-Protection nur, wenn du NFS, VMs oder Datenbanken mit Sync-Writes fährst, sonst bleibt der Slot leer.
L2ARC und das Special-vdev: Cache, der dich RAM kostet
L2ARC ist das Lese-Cache-Gegenstück zum SLOG, ein Second-Level-Cache auf einer SSD, der aus dem RAM-basierten ARC verdrängte Blöcke auffängt, und er kommt mit einem widersinnigen Preis. Jeder in L2ARC geparkte Datensatz braucht einen kleinen Header, der im RAM geführt wird, den der TrueNAS-Hardware-Guide auf rund 1 GB RAM je 50 GB L2ARC beziffert. Das ist die Falle: Schraub eine 500-GB-Cache-SSD an eine 16-GB-Kiste, und du hast still 10 GB deines kostbaren ARC für Index-Header verbraucht, sodass der Cache deine Trefferquote eher senkt als hebt. Die Regel daraus ist simpel: RAM vor L2ARC, denn RAM ist schnellerer ARC und besteuert sich nicht selbst.
L2ARC verdient seinen Slot im engeren Fall, wenn dein Working Set das physisch verbaubare RAM wirklich übersteigt und die Reads zufällig genug sind, dass ein schneller SSD-Cache den Gang zum Pool schlägt. TrueNAS merkt an, dass ein L2ARC-Gerät nur lohnt, wenn seine Random-Read-IOPS den Primärspeicher klar übertreffen, sodass eine langsame SATA-SSD vor einem breiten Plattenverbund sinnlos sein kann. Für die meisten Heim-Pools kommst du weiter, wenn du die DIMM-Slots ausreizt und L2ARC dem Tag überlässt, an dem die Kiste wirklich RAM-limitiert ist.
Für die technischere Fraktion: Es gibt noch ein drittes Spezial-vdev, das Special-vdev, eine dedizierte Allocation-Class, die Pool-Metadaten (und, wenn du willst, kleine Blöcke unter einer von dir gesetzten Größe) auf schnellen SSDs statt auf dem drehenden Pool ablegt. Auf einem metadatenlastigen Pool mit Millionen Dateien kann es verwandeln, wie flott sich Verzeichnislisten und Scrubs anfühlen, weil die Metadaten nicht mehr mit den Daten um die langsamen Platten konkurrieren. Die scharfe Kante ist Redundanz: Ein Special-vdev hält Daten, die der Pool nicht rekonstruieren kann, muss also mindestens auf das Redundanzniveau des Pools gespiegelt werden, und der Verlust eines ungespiegelten Special-vdev bedeutet den Verlust des ganzen Pools. Es ist ein echter Tuning-Gewinn für den richtigen Workload, aber ein Fortgeschrittenen-Schritt, den man bei der Pool-Erstellung plant, kein Teil zum beiläufigen Nachrüsten.
PCIe-Lanes budgetieren: ein durchgerechnetes Beispiel, wo sie ausgehen
Hier ist die Beschränkung, vor der niemand ZFS-Erstbauer warnt, und die ehrgeizige Teilelisten still ruiniert: PCIe-Lanes. Eine Lane ist eine der begrenzten Highspeed-Verbindungen der CPU zu allem, was nicht Speicher ist, und wie die PCI-Express-Übersicht erklärt, bricht eine gängige Desktop-CPU nur rund 20 bis 24 nutzbare Lanes heraus. Der Board-Chipsatz ergänzt weitere, aber er führt sie alle über einen einzigen geteilten Uplink zur CPU zurück, sodass diese Chipsatz-Lanes geteilte Bandbreite sind, keine freie Kapazität. Ein ZFS-Build ist ungewöhnlich, weil er Lanes aus mehreren Richtungen zugleich will, und genau da läuft ein billiges Board trocken.
Geh eine realistische Wunschliste durch und zähl mit. Ein Acht-Port-HBA will einen vollen x8-Slot. Eine 10GbE-Netzwerkkarte will je nach Modell weitere x4 bis x8. Eine Boot-SSD nimmt x4, und wenn du zusätzlich ein NVMe-SLOG und ein NVMe-L2ARC geplant hast, sind das nochmal je x4. Zähl das zusammen, und allein die Steckkarten verlangen so etwas wie x8 plus x8 plus drei x4, also rund 28 Lanes, bevor die CPU irgendetwas für Grafik ausgegeben hat. Auf einer Consumer-Plattform mit etwa 20 bis 24 CPU-Lanes passt das nicht: Steck den HBA in den ersten x16-Slot, und der zweite Slot fällt typisch von x16 auf x8, und ein M.2-Laufwerk deaktiviert oft ein Paar SATA-Ports auf demselben Board. Du landest bei der Wahl zwischen HBA und 10GbE-Karte, oder du drängst die NVMe-Geräte auf den geteilten Chipsatz-Uplink, wo sie miteinander konkurrieren.
Das ist der eigentliche Grund, warum ernste ZFS-Builds Richtung Workstation- und Server-Plattformen driften statt Gaming-Boards. Ein Intel Xeon E oder ein W-Serie-Chip, oder ein AMD Ryzen auf einem Workstation-Chipsatz, bietet schlicht mehr CPU-Lanes plus Server-Board-Features wie IPMI für Fernwartung, sodass ein HBA, eine schnelle NIC und ein paar NVMe-Geräte koexistieren können, ohne um dieselbe Handvoll Lanes zu kämpfen. Die Lehre ist eine Gewohnheit, kein Teil: Wenn deine Wunschliste HBA plus 10GbE plus irgendein NVMe enthält, zähl die Lanes vorher auf dem Papier und steig auf eine Plattform um, die sie hat, statt den Engpass nach der Paketlieferung zu entdecken. Wenn die Plattform steht, gleich Plattenkapazitäten und RAID-Level gegen echte Modelle in unserer NAS-Festplatten-Datenbank ab.
Die Teile, auf die sich ein ZFS-Build meist stützt
Welchen HBA und welche ECC-Module du wählst, hängt von der Plattform ab, deshalb stehen die in den oben verlinkten Guides und nicht als Einheitskarten hier. Was fast jeden ZFS-Build begleitet, ist die Nebenbesetzung unten, also nimm diese als Ankerpunkte und preise Platten und Speicher rund um deine Pool-Größe.
Empfehlung
Für einen Heim-Media- und Backup-Pool (Plex, Fotos, Freigaben über SMB) halt es schlank: 16 GB RAM, ein sparsames Low-Power-Board, CMR-Platten in RAIDZ2 ab vier Platten, eine USV, und weder SLOG noch L2ARC, weil asynchrone Writes keines nutzen und dein Geld stattdessen mehr Kapazität kauft. Für eine Virtualisierungs- oder NFS-Kiste (Proxmox, ESXi-Datastores, Datenbanken) dreht sich das Sync-Write-Bild: Plan 32 GB RAM oder mehr, ergänze ein SLOG mit Power-Loss-Protection und wähl eine Plattform mit genug PCIe-Lanes, damit 10GbE-NIC und HBA nicht kämpfen. Für einen großen oder metadatenlastigen Pool (Millionen Dateien oder bewusstes Dedup) führ mit RAM (Dedup will rund 5 GB pro TB), erwäg ein gespiegeltes Special-vdev für Metadaten, wenn Verzeichnis-Performance dein Engpass ist, und greif erst zu L2ARC, wenn die DIMM-Slots voll sind. Über alle drei hinweg ist ECC das Upgrade, das du priorisierst, wenn die Daten unersetzlich sind und das Board es kann, und alles oben setzt weiter die goldene Regel aus Bitrot und ZFS-Scrubbing voraus: ZFS plus echtes Backup, nie ZFS statt Backup.
Verwandte Artikel
NAS-Hardware Ratgeber 2026: Worauf du wirklich achten musst
NAS-Mainboard: SATA-Ports und PCIe-Lanes richtig lesen
ECC-RAM für NAS und ZFS: Pflicht oder Mythos?
ZFS vs ext4 vs Btrfs: Welches Dateisystem für dein NAS?
Bitrot und ZFS-Scrubbing: Wenn Daten leise verrotten
Hardware-RAID vs Software-RAID: Was gewinnt 2026?