RAID-Level im Detail: RAID 0/1/5/6/10 und Nested RAID richtig waehlen

Warum RAID immer noch (falsch) verstanden wird

RAID ist eines der Konzepte, die jeder “irgendwie kennt”, aber selten bis zum Ende durchdacht hat. Das raecht sich genau dann, wenn es teuer wird: mitten in einem Rebuild, wenn die dritte Platte in einem RAID-5-Array anfaengt, Lesefehler zu werfen, und der Chef fragt, warum das Backup vom letzten Wochenende jetzt die einzige Rettung ist.

Dieser Artikel geht bewusst tiefer als “RAID 5 = Parität, RAID 10 = gespiegelt und gestriped”. Du bekommst die Mechanik hinter jedem Level, die zwei grossen Risiken, die viele KMU-Admins nicht auf dem Radar haben (Write-Hole und URE-Rebuild-Falle), und eine belastbare Entscheidungsgrundlage fuer Hardware-RAID, Software-RAID, ZFS und Storage Spaces.

Die Grundlagen kurz und praezise

RAID 0 - Striping ohne Redundanz

Daten werden in Bloecken (Stripes) auf alle Platten verteilt, es gibt keinerlei Redundanz. Faellt eine Platte aus, sind alle Daten des Arrays weg - nicht nur die Haelfte.

• Nutzkapazitaet: 100 % (n × Plattengroesse)
• Performance: Lese- und Schreibgeschwindigkeit skaliert nahezu linear mit der Anzahl Platten
• Einsatz im KMU: Scratch-Volumes fuer Video-Rendering, temporaere CAD-Caches, nie fuer Produktivdaten

RAID 1 - Mirroring

Jeder Block wird identisch auf zwei (oder mehr) Platten geschrieben. Eine Platte kann ausfallen, ohne dass Daten verloren gehen.

• Nutzkapazitaet: 50 % bei zwei Platten
• Performance: Schreiben wie eine Platte, Lesen oft schneller (Load-Balancing über beide Kopien)
• Einsatz im KMU: Boot-Volumes von Servern, kleine Fileserver, Hypervisor-Datastores mit geringem Kapazitaetsbedarf

RAID 5 - Striping mit verteilter Parität

Daten und eine Paritaetsinformation werden ueber alle Platten verteilt. Bei n Platten steht die Kapazitaet von n-1 Platten zur Verfuegung, eine Platte darf ausfallen.

• Nutzkapazitaet: (n-1) × Plattengroesse
• Performance: Guter sequenzieller Durchsatz, aber der sogenannte Write-Penalty (siehe unten) bremst zufaellige Schreibzugriffe
• Einsatz im KMU: Historisch der Standard fuer Fileserver, heute mit grossen Platten zunehmend riskant (siehe URE-Kapitel)

RAID 6 - Striping mit doppelter Parität

Wie RAID 5, aber mit zwei unabhaengigen Paritaetsbloecken pro Stripe. Zwei Platten duerfen gleichzeitig ausfallen.

• Nutzkapazitaet: (n-2) × Plattengroesse
• Performance: Schreiblast steigt gegenueber RAID 5 nochmals deutlich (mehr Paritaetsberechnung), Rebuild dauert laenger, ist aber ungleich sicherer
• Einsatz im KMU: De-facto-Nachfolger von RAID 5 bei Platten ab ca. 4-6 TB

RAID 10 (1+0) - Gespiegelte Stripes

Mehrere RAID-1-Paare werden zu einem RAID 0 zusammengefasst. Mindestens vier Platten noetig.

• Nutzkapazitaet: 50 %
• Performance: Beste Kombination aus Schreib- und Leseperformance unter den redundanten Levels, kein Paritaets-Overhead
• Einsatz im KMU: SQL-Server-Datenbanken, Terminalserver-Profile, alles mit hoher Random-I/O-Last

Nested RAID: 01 vs. 10 und wann RAID 50/60 Sinn ergibt

RAID 1+0 und RAID 0+1 klingen gleich, sind es aber nicht:

• RAID 10 (1+0): Erst spiegeln, dann stripen. Faellt eine Platte aus, bleibt nur ihr Spiegelpartner “gefaehrdet” - der Rest des Arrays laeuft unbeeintraechtigt weiter. Deutlich robuster.
• RAID 01 (0+1): Erst stripen, dann spiegeln. Faellt eine Platte aus, faellt die komplette Stripe-Haelfte aus, und der verbleibende Stripe-Satz laeuft ohne jede Redundanz weiter, bis der Rebuild fertig ist. Praktisch nur noch von historischer Bedeutung, in der Praxis fast immer durch RAID 10 ersetzt.

Bei sehr grossen Arrays (12+ Platten) kommen RAID 50 (mehrere RAID-5-Gruppen als RAID-0-Stripe) und RAID 60 (mehrere RAID-6-Gruppen als RAID-0-Stripe) ins Spiel. Der Gedanke: Man begrenzt die Groesse einer einzelnen Paritaetsgruppe (z. B. auf 6-8 Platten), um Rebuild-Zeit und URE-Risiko pro Gruppe klein zu halten, gewinnt aber durch das Striping ueber die Gruppen zusaetzliche Performance. Typischer Einsatz: grosse Storage-Arrays mit 16-48 Platten, wo weder ein einzelnes riesiges RAID 6 noch reines RAID 10 (zu teuer) sinnvoll waere.

Das Write-Hole-Problem

Bei RAID 5 und RAID 6 wird die Paritaet aus mehreren Datenbloecken berechnet und getrennt geschrieben. Das ist keine atomare Operation ueber mehrere physische Platten hinweg. Faellt der Strom genau zwischen dem Schreiben der Datenbloecke und dem Schreiben des zugehoerigen Paritaetsblocks aus, bleibt die Paritaet inkonsistent zu den Daten - ohne dass das Array das sofort merkt. Das Problem zeigt sich meist erst, wenn spaeter tatsaechlich ein Rebuild noetig ist: Dann wird aus der (falschen) Paritaet ein falscher Datenblock rekonstruiert, lautlos und ohne Fehlermeldung.

Das ist kein theoretisches Randproblem, sondern eine reale, wenn auch seltene Fehlerkette: unsauberer Stromausfall mitten in einem Write plus ein spaeterer zweiter Fehler, bevor die Inkonsistenz auffaellt.

Drei Wege, das Write-Hole zu schliessen:

1. Battery-Backed Cache (BBU) / Flash-Backed Write Cache (FBWC): Der Hardware-RAID-Controller haelt die im Schreibcache befindlichen, noch nicht auf Platte committeten Daten bei Stromausfall per Batterie oder Flash-Modul am Leben und schreibt sie beim naechsten Boot fertig. Ohne BBU/FBWC sollte der Write-Cache eines Hardware-Controllers nie im Write-Back-Modus laufen, sondern auf Write-Through gestellt werden - das kostet Performance, aber verhindert Datenverlust.
2. Journaling (z. B. Linux mdadm mit Write-Intent-Bitmap oder dediziertem Journal-Device): Bevor ein Stripe geschrieben wird, wird knapp protokolliert, welcher Stripe gerade “in Arbeit” ist. Nach einem Absturz muss nur dieser Bereich neu abgeglichen werden, nicht das komplette Array.
3. Copy-on-Write-Dateisysteme wie ZFS (RAID-Z): Hier wird ein Stripe nie “an Ort und Stelle” ueberschrieben, sondern immer komplett neu an eine freie Stelle geschrieben und erst danach per Transaktions-Commit sichtbar gemacht. Ein Write-Hole im klassischen Sinn kann dadurch konzeptionell nicht entstehen.

Status bei einem typischen PowerEdge-Server mit PERC-Controller pruefen:

# Dell PERC / storcli Beispiel
storcli64 /c0 show all | grep -i "BBU\|Cache"

# Alternative: MegaCli
MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL

Bei Linux Software-RAID (mdadm) ist ein Journal-Device fuer RAID 5/6 dringend zu empfehlen, idealerweise eine kleine, schnelle SSD/NVMe:

# Bestehendes RAID6 um ein Journal-Device (z. B. NVMe) erweitern
mdadm --add-journal /dev/md0 /dev/nvme0n1

# Status pruefen: journal sollte als "journal" gelistet sein
mdadm --detail /dev/md0

Die RAID-5-Death-Falle: URE bei grossen Platten

Das ist der wichtigste Grund, warum RAID 5 seit Jahren zunehmend aus dem KMU-Umfeld verschwindet. Kern des Problems: Jede Festplatte hat eine spezifizierte Unrecoverable Read Error Rate (URE), typischerweise 1 in 10^14 gelesenen Bits bei Consumer-/Nearline-SATA-Platten (Enterprise-SAS-Platten liegen oft bei 1 in 10^15 oder besser).

10^14 Bit sind rund 12,5 TB. Das heisst: statistisch tritt bei jedem gelesenen Datenvolumen dieser Groessenordnung ein nicht korrigierbarer Lesefehler auf.

Das Problem beim RAID-5-Rebuild: Faellt eine Platte aus, muss der Controller alle verbleibenden Platten vollstaendig lesen, um die fehlende Platte zu rekonstruieren. Bei einem Array aus sechs 8-TB-Platten (5 verbleibende Platten × 8 TB = 40 TB zu lesende Datenmenge) steigt die Wahrscheinlichkeit, dabei mindestens eine URE zu treffen, auf einen erschreckend hohen, meist deutlich ueber 90 % liegenden Wert. Trifft der Rebuild eine URE, bricht er ab oder liefert stillschweigend korrupte Daten - je nach Controller-Verhalten. Bei RAID 5 gibt es keine zweite Paritaet, die das auffangen koennte: das Array ist in diesem Moment faktisch verloren.

Grobe Faustformel fuer die Ausfallwahrscheinlichkeit während eines Rebuilds:

P(URE waehrend Rebuild) ≈ 1 - (1 - 1/URE_Rate)^(zu lesende Bits)

Mit URE_Rate = 10^14 und einer zu lesenden Datenmenge von 40 TB (= 40 × 8 × 10^12 Bit ≈ 3,2 × 10^14 Bit) ergibt sich rechnerisch eine Erfolgswahrscheinlichkeit von nur noch e^(-3,2) ≈ 4 % - also eine Trefferwahrscheinlichkeit fuer mindestens eine URE von rund 96 %. Selbst bei deutlich kleineren Arrays (z. B. 12 TB Gesamtlesevolumen) liegt die Ausfallwahrscheinlichkeit nach dieser Formel bereits im hohen zweistelligen Prozentbereich.

Wichtig: URE-Statistiken sind Wahrscheinlichkeiten, kein Determinismus - viele RAID-5-Arrays laufen jahrelang unauffaellig. Das aendert aber nichts daran, dass das Restrisiko im Ernstfall genau dann zuschlaegt, wenn man es sich am wenigsten leisten kann (Platte 1 ist bereits tot, das Array laeuft degraded).

Rebuild-Zeiten und Performance-Impact realistisch einschaetzen

Ein Rebuild ist kein Nebenbei-Vorgang. Waehrend des Rebuilds:

• laufen alle verbleibenden Platten dauerhaft auf oder nahe 100 % Auslastung
• sinkt die I/O-Performance des Arrays fuer produktive Zugriffe spuerbar (je nach Controller-Priorisierung 20-70 %)
• steigt bei RAID 5/6 das Risiko eines zweiten Ausfalls genau in dieser Phase am staerksten, weil die Platten thermisch und mechanisch am staerksten belastet werden

Grobe Richtwerte fuer Rebuild-Dauer (stark abhaengig von Controller, Plattentyp und Auslastung waehrend des Rebuilds):

RAID 10 gewinnt hier doppelt: Rebuild ist ein simpler Block-Kopiervorgang von einer Platte, kein Lesen des gesamten restlichen Arrays und keine Paritaetsberechnung - entsprechend kurz das Risikofenster.

# mdadm: Rebuild-Geschwindigkeit begrenzen (KB/s pro Platte)
echo 50000 > /proc/sys/dev/raid/speed_limit_max
echo 10000 > /proc/sys/dev/raid/speed_limit_min

# Aktuellen Rebuild-Fortschritt anzeigen
cat /proc/mdstat

# Windows Storage Spaces: Repair-Status eines Pools abfragen
Get-VirtualDisk | Select FriendlyName, HealthStatus, RepairPercentageCompleted

Hardware-RAID vs. Software-RAID vs. ZFS/Storage Spaces

ZFS und Storage Spaces loesen das Problem architektonisch anders als klassisches RAID: Statt “dumm” Bloecke zu spiegeln oder Paritaet zu berechnen, kennt das Dateisystem selbst die Belegung und kann beim Resilver/Repair nur tatsaechlich genutzte Bloecke neu schreiben - das verkuerzt Rebuild-Zeiten bei duennnbelegten Pools erheblich und bringt echte Bitrot-Erkennung via Checksummen mit, was klassisches Hardware- oder mdadm-RAID grundsaetzlich nicht kann.

Hotspare-Strategien und Stripe-Size richtig waehlen

Hotspare: dedicated vs. global vs. distributed

• Dedicated Hotspare: Eine Ersatzplatte ist fest einem einzelnen Array zugeordnet und springt bei Ausfall sofort automatisch ein. Einfach, aber im Mehrarray-System kapazitativ ineffizient (jede Array-Gruppe braucht ihre eigene Reserve).
• Global/Shared Hotspare: Eine oder mehrere Ersatzplatten stehen mehreren Arrays am selben Controller zur Verfuegung. Effizienter, aber bei gleichzeitigem Ausfall in zwei Arrays reicht die Reserve nicht.
• Distributed Spare Capacity (z. B. ZFS dRAID, manche Enterprise-Arrays): Statt einer physisch ungenutzten Ersatzplatte wird die Reservekapazitaet ueber alle Platten verteilt vorgehalten. Der Rebuild schreibt dann parallel auf viele Platten statt seriell auf eine einzige - das verkuerzt die Rebuild-Zeit drastisch, weil nicht eine einzelne Spare-Platte zum Flaschenhals wird.

Stripe-Size (Chunk-Size) - die unterschaetzte Stellschraube

Die Stripe-Size (haeufig 64 KB, 128 KB oder 256 KB) bestimmt, wie gross der zusammenhaengende Datenblock ist, der auf eine einzelne Platte geschrieben wird, bevor der naechste Block auf die naechste Platte wandert.

• Kleine Stripe-Size (z. B. 64 KB): Gut fuer viele kleine, zufaellige I/Os (Datenbank-Transaktionslogs, Mailserver) - mehr Platten sind gleichzeitig an einem einzelnen I/O-Request beteiligt, was Latenz senkt.
• Grosse Stripe-Size (z. B. 256 KB-1 MB): Gut fuer wenige, grosse sequenzielle Zugriffe (Videoschnitt, Backup-Repositories, Datei-Streaming) - weniger Overhead pro I/O-Operation.

Faustregel: Stripe-Size an die dominante I/O-Groesse der Anwendung ausrichten. SQL Server arbeitet z. B. mit 64-KB-Extents, weshalb 64 KB oder ein Vielfaches davon fuer SQL-Datenvolumes eine gaengige Empfehlung ist (siehe dazu vertieft SQL Server: Indizes und Performance-Tuning).

# Windows: neues Volume mit definierter Interleave/Stripe-Size auf einem Storage Pool anlegen
New-VirtualDisk -StoragePoolFriendlyName "Pool01" `
  -FriendlyName "SQL-Data" `
  -ResiliencySettingName Mirror `
  -Interleave 65536 `
  -UseMaximumSize

# Linux mdadm: RAID10 mit expliziter Chunk-Size anlegen
mdadm --create /dev/md0 --level=10 --raid-devices=4 \
  --chunk=64 /dev/sd[b-e]1

Entscheidungsbaum: welches RAID fuer welchen Zweck

Brauche ich Redundanz ueberhaupt?
├─ Nein (reine Cache-/Scratch-Daten) ──────────► RAID 0
└─ Ja
   ├─ Random-I/O hoch (DB, VMs, Terminalserver)?
   │  ├─ Budget/Kapazitaet unkritisch ─────────► RAID 10
   │  └─ Kapazitaet wichtiger als Performance ─► RAID 6 (oder ZFS RAID-Z2)
   ├─ Ueberwiegend sequenziell (Archiv, Backup-Ziel, Fileserver)?
   │  ├─ Platten < 4 TB, wenige Platten (<=4) ─► RAID 5 vertretbar
   │  └─ Platten >= 4 TB oder >4 Platten ─────► RAID 6 / RAID-Z2
   └─ Sehr grosses Array (12+ Platten)?
      ├─ Performance-fokussiert ───────────────► RAID 10
      └─ Kapazitaet-fokussiert ────────────────► RAID 60 / RAID-Z2-Pools

Praxis-Checkliste fuer den Schweizer KMU-Alltag

1. Vor dem Kauf: Plattengroesse, URE-Rate (Datenblatt!) und geplante Array-Groesse gegeneinander abwaegen. Ab 4-6 TB pro Platte kein reines RAID 5 mehr fuer Produktivdaten.
2. BBU/FBWC pruefen: Bei jedem Hardware-RAID-Controller im Rahmen der jaehrlichen Wartung Batteriestatus und Cache-Modus kontrollieren.
3. Monitoring einrichten: SMART-Werte, RAID-Status und Hotspare-Verfuegbarkeit automatisiert ueberwachen, nicht manuell nachschauen.
4. Rebuild-Test einplanen: Mindestens einmal jaehrlich in einer Testumgebung (oder bei geplantem Plattentausch) einen echten Rebuild durchfuehren und die Dauer dokumentieren - Ueberraschungen lieber ausserhalb eines echten Ausfalls erleben.
5. Ersatzteilstrategie: Fuer Hardware-RAID-Controller Ersatzhardware oder klar definierten Beschaffungsweg (4h/NBD-Support) sicherstellen.
6. Backup ist Pflicht: RAID reduziert Ausfallzeit, ersetzt aber nie ein unabhaengiges Backup nach der 3-2-1-Regel.

Weiterlernen

• Microsoft Learn: Mirror-accelerated parity in ReFS/Storage Spaces Direct
• Linux Software RAID: mdadm Dokumentation (Kernel.org Wiki)
• OpenZFS Documentation: RAIDZ
• IBM Support: Re-Evaluating RAID-5 and RAID-6 for slower larger drives
• Dell: storcli/MegaCli Referenz fuer PERC-Controller
• Backup-Strategie: die 3-2-1-Regel

Videos

YouTube

YouTube