Die Frage “RAID vs ZFS 2026” wirkt auf den ersten Blick wie ein Kampf aus einer anderen Zeit. Softraid gegen Hardware-Controller, Copy-on-Write gegen Parity-Cache, ein Dateisystem gegen einen Block-Layer. Und trotzdem taucht sie in jedem zweiten neuen Server-Projekt wieder auf: “Reicht nicht ein guenstiger Hardware-RAID-Controller?” — “Wir haben doch schon immer RAID gemacht.” — “ZFS ist kompliziert, oder?”

Die ehrliche Antwort im Jahr 2026 lautet: Fuer neue Storage-Server im Mittelstand ist ZFS in fast allen Faellen die richtige Wahl. Nicht aus Ideologie, sondern weil die Groesse moderner Platten, die Realitaet von Silent Corruption und die Rebuild-Zeiten klassischer RAID-Level das Risiko klassischen Hardware-RAIDs deutlich erhoeht haben. Und trotzdem gibt es Nischen, in denen Hardware-RAID weiterlebt — Boot-Volumes, bestimmte HBA-Konstellationen, Legacy-Support. Genau darum geht es in diesem Vergleich.

RAID vs ZFS 2026: zwei Ebenen, ein Ziel

Bevor man vergleicht, muss man die Konzepte trennen. Klassisches RAID ist ein Block-Layer-Feature — entweder in Hardware (dedizierter Controller mit Cache und BBU) oder in Software (mdadm unter Linux). Es kennt keine Dateien, nur Blocks. Es weiss nichts ueber Snapshots, Kompression oder Pruefsummen der Nutzdaten. Der Controller sieht: “Block X wurde geschrieben.” Ob das der richtige Block war — keine Ahnung.

ZFS ist ein integrierter Stack aus Volume-Manager, Dateisystem und Pruefsummen-Engine. Der Pool weiss, welche Datei zu welchem Block gehoert, welche Pruefsumme dazu gespeichert ist und ob beim Lesen ein Bit gekippt ist. Redundanz laeuft ueber Mirror, RAIDZ1/2/3 oder dRAID — aber die Redundanz ist Mittel zum Zweck, nicht das Ziel selbst.

Der Unterschied klingt akademisch. In der Praxis entscheidet er darueber, ob eine schleichende Datenkorruption Jahre spaeter auffliegt oder rechtzeitig repariert wird.

Silent Corruption: der Punkt, an dem RAID stumm verliert

Der wichtigste Grund fuer den Erfolg von ZFS heisst Silent Corruption — unbemerktes Umkippen von Bits auf dem Weg zwischen CPU und Platte. Ursachen sind vielfaeltig: fehlerhafte SATA-Kabel, RAM ohne ECC, defekte Controller-Firmware, kosmische Strahlung, langsam sterbende Sektoren, Bugs in Enterprise-SSD-Firmware. Studien von Google, CERN und Backblaze zeigen seit ueber einem Jahrzehnt uebereinstimmend, dass solche Fehler nicht theoretisch sind, sondern in jeder groesseren Storage-Umgebung real vorkommen.

Klassisches Hardware-RAID kann Silent Corruption nicht erkennen. Der Controller berechnet eine Parity ueber die Blocks — wenn beim Lesen ein Bit umgekippt ist, weiss er nicht, welcher Block “richtig” ist. Bei RAID6 mit doppelter Parity haette er zwar mathematisch die Chance, den Fehler zu identifizieren, aber die klassischen Controller lesen die Parity im Normalbetrieb gar nicht mit. Sie verlassen sich auf die interne CRC der Platte, und die schuetzt nur bis zum Controller, nicht bis zur Applikation.

ZFS verwendet End-to-End-Checksums — SHA-256, Fletcher4 oder BLAKE3 pro Block. Beim Lesen wird die Pruefsumme neu berechnet und mit der gespeicherten verglichen. Passt sie nicht, holt ZFS eine gueltige Kopie aus einem Mirror-Vdev oder rekonstruiert aus der Parity und repariert die kaputte Kopie im laufenden Betrieb. Diese Selbstheilung ist der zentrale Grund, warum wir bei DATAZONE seit Jahren neue Storage-Systeme fast ausschliesslich auf ZFS aufbauen.

Wer tiefer einsteigen will, findet in unserem Artikel zu ZFS-Scrub, SMART und Datenintegritaet die Praxis-Kommandos und Monitoring-Ansaetze fuer den Alltag.

Rebuild-Risiko: warum RAID5 bei 20-TB-Platten kein Backup ist

Der zweite Punkt betrifft die Rebuild-Zeit nach einem Plattenausfall. Vor 15 Jahren waren SATA-Platten 500 GB gross und ein RAID5-Rebuild dauerte wenige Stunden. Heute reden wir ueber 20, 22 oder 24 TB pro Spindel — ein Rebuild kann je nach Controller-Auslastung und paralleler Workload zwischen 20 und 60 Stunden dauern.

Waehrend dieser Zeit laeuft der Pool degradiert. Wenn in diesen Stunden eine zweite Platte ausfaellt — oder auch nur ein einzelner unlesbarer Sektor auf einer anderen Platte auftaucht — ist das RAID5-Array verloren. Bei 8 Platten a 20 TB ist die statistische Wahrscheinlichkeit dafuer nicht mehr vernachlaessigbar. Das ist keine Panikmache, sondern Konsequenz aus dokumentierten Bit Error Rates von 10 hoch -14 oder -15 bei Consumer- bzw. Enterprise-HDDs.

RAID6 mit zweifacher Parity mildert das Problem, aber auch dort steigt die Rebuild-Zeit mit Plattengroesse linear. ZFS RAIDZ2 hat konzeptionell dieselbe Redundanz, hat aber zwei Vorteile:

ZFS liest nur echte Nutzdaten beim Resilver, nicht die kompletten Plattenoberflaechen. Leere Bloecke werden uebersprungen. Ein halb gefuellter Pool resilvered rund doppelt so schnell.
ZFS erkennt beim Resilver Silent Corruption und markiert betroffene Dateien im zpool status. Klassisches RAID6 baut stumm die falsche Parity ein.

Wer die verschiedenen RAIDZ-Level abwaegen will, findet in unserem Referenzartikel ZFS RAID-Level erklaert eine pragmatische Uebersicht mit Trade-offs.

Write-Hole: das alte Gespenst und wie es geloest wurde

Klassisches RAID5/6 hat ein architektonisches Problem: die Write-Hole. Wenn waehrend eines Parity-Updates der Strom ausfaellt oder der Controller haengt, koennen Datenblock und Parity in einem inkonsistenten Zustand landen. Beim naechsten Rebuild rekonstruiert der Controller aus einer Parity, die nicht mehr zu den Daten passt — und schreibt stillen Muell in die “reparierten” Sektoren.

Genau hier setzt die Battery-Backed-Cache-Unit (BBU) am Hardware-RAID-Controller an. Sie soll sicherstellen, dass ein laufender Schreibvorgang auch nach einem Stromausfall komplett wird. In der Praxis wird die Battery zunehmend durch Flash-Backed Write Cache (FBWC) mit Supercap ersetzt — der klassische Akku hatte eine Lebensdauer von zwei bis drei Jahren und war eine haeufige Fehlerquelle.

ZFS umgeht die Write-Hole architektonisch durch Copy-on-Write. Bloecke werden nie ueberschrieben — neue Version wird in freien Speicher geschrieben, dann atomar der Metadaten-Baum umgehaengt. Faellt der Strom mittendrin, existiert schlicht die alte Version noch. Kein inkonsistenter Zwischenzustand, keine Notwendigkeit fuer BBU auf Ebene des Storage-Pools.

Fuer synchrone Schreiblasten (Datenbank-Commit, NFS-Sync, ESXi) nutzt ZFS ein ZIL/SLOG — ein separates NVMe-Device fuer das Transaktions-Log. Details dazu in unserem Artikel zu SLOG, Special-Vdev und Write-Cache.

Wo Hardware-RAID trotzdem noch lebt

Nach all den Argumenten koennte man meinen, Hardware-RAID sei tot. Ist es nicht — es hat nur seinen Einsatzbereich verkleinert. Ehrlich betrachtet bleibt es 2026 in diesen Faellen relevant:

Boot-Volumes. Viele Server-Hersteller liefern einen kleinen SATA/M.2-RAID-Controller (oft “SATA DOM” oder “M.2 Boot RAID”) fuer das Boot-Device. Ein simpler Mirror aus zwei M.2-SSDs, damit das System nach einem SSD-Ausfall bootbar bleibt. ZFS auf dem Boot-Device geht auch, ist aber unter Proxmox und einigen Enterprise-Distros noch etwas fummelig — unser Erfahrungsartikel Linux-ZFS-Boot-Mirror rescue zeigt die typischen Fallstricke.

Reine HBA-fehlende Alt-Systeme. Wenn Sie einen bestehenden Server mit RAID-Controller haben und das System weiterbetreiben, macht es selten Sinn, den Controller gegen einen HBA zu tauschen — der Controller kann fast immer in einen HBA-/JBOD-Modus (“IT-Mode”, “Passthrough”) umgeflasht werden. Das ist Zwischenloesung und aufwendig, aber machbar. Neuer Server -> HBA von Anfang an.

Applikationen mit expliziten RAID-Anforderungen. Manche Legacy-Backup-Software oder ERP-Suiten pruefen im Setup auf “hardware RAID present” und weigern sich, auf einer ZFS-Volume-Datei zu installieren. Selten geworden, existiert aber noch in bestimmten Branchen.

Kaskadierte JBODs mit Expander-Hardware, in denen ein Storage-Provider historisch auf Hardware-RAID setzt und der Kunde eine bestehende Konfiguration weiterfaehrt. Auch hier: Neuinstallation? ZFS.

Fuer alle anderen Faelle — neuer Fileserver, neuer Backup-Target, neues Virtualisierungs-Storage — gibt es 2026 keinen sachlichen Grund mehr fuer klassisches Hardware-RAID.

Der Sonderfall Battery-Backed-Cache

Ein haeufiges Verkaufsargument fuer Hardware-RAID ist der Schreib-Cache mit BBU/FBWC: kleine, zufaellige Schreibvorgaenge werden im Controller-DRAM gepuffert und asynchron auf die Platten geschrieben. Das gibt in synchronen Workloads spuerbar bessere Latenzen als reine HDD-Pools ohne Cache.

ZFS beantwortet diesen Punkt mit SLOG auf Enterprise-NVMe (Power-Loss-Protected, hoher Endurance-Wert) plus ARC/L2ARC im DRAM. Das Ergebnis ist in synchronen Workloads meist besser als der klassische BBU-Cache, weil moderne NVMe-Devices deutlich hoehere IOPS als Controller-DRAM haben. In All-Flash-Pools ist SLOG oft ueberfluessig, weil die Pool-Devices selbst schnell genug sind.

Unser Detailartikel zu ARC und L2ARC Tuning zeigt konkrete Werte fuer Proxmox-Hosts.

RAID vs ZFS 2026: die pragmatische Entscheidungsmatrix

Ihre Situation	Empfehlung
Neuer Fileserver, neuer NAS	ZFS (TrueNAS oder Linux)
Neuer Proxmox-Host mit lokalem Storage	ZFS
Backup-Target fuer PBS/Veeam	ZFS (RAIDZ2 oder Mirror-VDEVs)
Bestehender Server mit Hardware-RAID, Umbau geplant	Controller in HBA/IT-Mode, dann ZFS
Boot-Device (2x M.2)	Onboard-RAID oder ZFS-Root, beides ok
Legacy-Applikation verlangt “Hardware-RAID”	Hardware-RAID (dokumentierte Ausnahme)
Sehr enges Budget, ein Server, wenig Wachstum	ZFS mit Software-RAID; Hardware-RAID lohnt sich preislich nicht
Managed Storage-Appliance	ZFS-basiert (TrueNAS)

Wer neu baut, sollte die Frage nicht mehr “welchen RAID-Controller kaufe ich?” stellen, sondern “welchen HBA im IT-Mode und wieviel RAM fuer ZFS?”. Fuer die Modellauswahl empfiehlt sich der TrueNAS-Konfigurator, der Workload und Kapazitaet zu konkreten Serien und Ausbauten aufloest.

Was heisst das fuer Ihren naechsten Server?

Wenn Sie in den naechsten Monaten einen Fileserver, NAS oder Virtualisierungs-Host planen, gibt es aus unserer Sicht drei nuechterne Empfehlungen:

Kein neuer Hardware-RAID-Controller mehr. Wenn der Server ohne Controller nicht bootet, klaeren Sie mit dem Hersteller, ob er im HBA-/IT-Mode betrieben werden kann. Fast alle aktuellen Broadcom/LSI-basierten Systeme koennen das.
ECC-RAM ist Pflicht. ZFS ist nicht “empfindlicher” gegen RAM-Fehler als andere Dateisysteme — aber ohne ECC vergeuden Sie den Aufwand der End-to-End-Pruefsummen.
Boot-Device separat vom Datenpool. Zwei kleine NVMe oder SATA-SSDs im Mirror fuer Betriebssystem, alle Datenplatten am HBA.

Fuer Kunden, die den Weg zu ZFS als Managed-Loesung gehen wollen, bauen wir TrueNAS-Systeme in allen Groessen — von der Mini-Serie fuer kleine Standorte bis zu Rechenzentrums-Setups. Details zur Serienauswahl in unserem TrueNAS-Ratgeber oder direkt ueber den Konfigurator. Fuer den laufenden Betrieb — Monitoring, Patch-Management, Kapazitaetsplanung — gibt es passende IT-Services.

FAQ zu RAID vs ZFS 2026

Ist ZFS langsamer als Hardware-RAID?

Nein, in der Regel schneller — vorausgesetzt genug RAM (ARC) und passende Pool-Topologie. Nur in synchronen Small-Write-Szenarien ohne SLOG kann ein Hardware-Controller mit BBU-Cache kurzfristig vorne liegen. Sobald SLOG oder All-Flash im Pool ist, kippt der Vorteil zu ZFS.

Brauche ich zwingend ECC-RAM fuer ZFS?

Nicht zwingend, aber dringend empfohlen. Ohne ECC koennen Bitfehler im RAM in die Pruefsummen einfliessen — ZFS repariert dann korrekt gegen einen falschen Referenzwert. Fuer produktive Systeme ist ECC Standard.

Was ist mit Software-RAID unter Linux (mdadm)?

mdadm ist stabil und bewaehrt, adressiert aber die Silent-Corruption-Problematik nicht. Fuer neue Storage-Server ist ZFS die konsequentere Loesung. mdadm bleibt sinnvoll als Boot-Mirror, wenn ZFS-Root nicht gewuenscht ist.

Wie sicher ist Copy-on-Write bei Stromausfall?

Sehr sicher. ZFS commits sind atomar — entweder ist der Transaktions-Baum komplett auf Platte oder nicht. Nach einem Crash haben Sie im schlimmsten Fall die letzten wenigen Sekunden verloren, aber keinen inkonsistenten Pool.

Kann ich ein bestehendes Hardware-RAID zu ZFS migrieren?

Ja. Zwei Wege: entweder Controller in HBA-Mode umflashen und Platten sauber neu als ZFS-Pool aufsetzen, oder neue Platten am HBA neben dem bestehenden RAID einbauen und die Daten via zfs send/receive, rsync oder robocopy uebertragen. Wir haben das Verfahren fuer typische Umgebungen dokumentiert und begleiten Migrationen praktisch.

Lohnt sich Hardware-RAID fuer sehr grosse Pools (mehrere PB)?

Nein, im Gegenteil. Sehr grosse Pools profitieren am staerksten von ZFS: dRAID, Silent-Corruption-Erkennung, schnellere Resilvers durch skip von leerem Speicher, saubere Snapshot-Replikation. Klassisches Hardware-RAID skaliert in dieser Groesse schlicht nicht mehr wirtschaftlich.

Storage-Entscheidungen sind Langfrist-Entscheidungen. Wenn Sie unsicher sind, ob Sie 2026 in einen neuen Hardware-RAID-Controller investieren sollen oder besser gleich auf ZFS umsteigen, sprechen Sie mit uns: /kontakt/. Wir bauen seit Jahren beide Welten in Bayern und im deutschsprachigen Raum — und sagen ehrlich, wo sich der Aufwand lohnt und wo nicht.

RAID vs ZFS 2026: warum klassisches Hardware-RAID noch existiert