RAID — Redundant Array of Independent Disks

Grundlagen — Striping, Mirroring und Parity

RAID basiert auf drei grundlegenden Techniken, die einzeln oder in Kombination eingesetzt werden: Striping verteilt Daten blockweise über mehrere Festplatten (Stripe-Einheit typischerweise 64–256 KB), um parallele Lese- und Schreibzugriffe zu ermöglichen und so den Durchsatz zu erhöhen. Mirroring speichert identische Kopien der Daten auf zwei oder mehr Datenträgern, sodass beim Ausfall einer Platte die zweite nahtlos übernimmt. Parity berechnet über XOR-Operationen Prüfinformationen, die es erlauben, die Daten einer ausgefallenen Platte aus den verbleibenden Platten und der Paritätsinformation mathematisch zu rekonstruieren. Die Wahl der Stripe-Größe beeinflusst die Performance erheblich: Kleine Stripes (z. B. 16 KB) optimieren sequentiellen Lesedurchsatz, während größere Stripes (256 KB+) für zufällige I/O-Operationen günstiger sind.

Die Nettokapazität eines RAID-Verbunds hängt vom gewählten Level ab. Bei RAID 0 (reines Striping) steht die Gesamtkapazität aller Platten zur Verfügung: Kapazität = n × Plattengröße. Bei RAID 1 (Mirroring) halbiert sich die nutzbare Kapazität: Kapazität = n/2 × Plattengröße. Bei RAID 5 geht die Kapazität einer Platte für Paritätsdaten verloren: Kapazität = (n-1) × Plattengröße. Bei RAID 6 sind es zwei Platten: Kapazität = (n-2) × Plattengröße. RAID 10 kombiniert Mirroring und Striping und bietet Kapazität = n/2 × Plattengröße. Diese Berechnungen setzen Platten gleicher Größe voraus — bei unterschiedlich großen Platten bestimmt die kleinste Platte die nutzbare Kapazität pro Slot.

Ein kritischer Parameter ist die MTBF (Mean Time Between Failures), die für Enterprise-HDDs typischerweise bei 1,2–2,5 Millionen Stunden liegt. Weitaus wichtiger ist jedoch die Rebuild-Zeit nach einem Plattenausfall: Während des Rebuilds muss der Controller jedes Byte der verbleibenden Platten lesen und die Daten der ausgefallenen Platte rekonstruieren. Bei einer 16-TB-HDD kann dieser Vorgang 12–24 Stunden oder länger dauern — abhängig von der I/O-Last. Während dieser kritischen Phase besteht das Risiko eines URE (Unrecoverable Read Error): Bei einer typischen URE-Rate von 10^14 Bits (ca. 12,5 TB) bei Consumer-HDDs ist die Wahrscheinlichkeit, während des Rebuilds eines großen Arrays auf einen unkorrigierbaren Lesefehler zu treffen, signifikant. Dies ist der Hauptgrund, warum RAID 5 für große Platten als überholt gilt und RAID 6 oder RAID 10 empfohlen wird.

RAID-Level im Vergleich

Jedes RAID-Level bietet ein spezifisches Gleichgewicht zwischen Kapazitätseffizienz, Lese-/Schreib-Performance und Ausfallsicherheit. Die Wahl des richtigen Levels hängt vom Anwendungsszenario ab: Datenbanken stellen andere Anforderungen als Archiv-Speicher, und Virtualisierungsumgebungen benötigen eine andere Charakteristik als Videoschnittsysteme.

In der Praxis dominieren fünf RAID-Level den Markt, wobei RAID 1, RAID 6 und RAID 10 für produktive Umgebungen empfohlen werden. RAID 0 findet sich ausschließlich in Szenarien ohne Redundanzanforderung (Scratch-Disks, temporäre Daten), während RAID 5 aufgrund der URE-Problematik bei großen Platten zunehmend durch RAID 6 ersetzt wird. Für hochperformante Workloads mit maximaler Ausfallsicherheit — etwa Datenbankserver oder Virtualisierungshosts — ist RAID 10 die erste Wahl.

• RAID 0 — Striping: Daten werden blockweise über alle Platten verteilt, ohne Redundanz. Kapazität: 100 % (n × Disk). Lese- und Schreib-Performance skalieren linear mit der Plattenanzahl. Ausfallsicherheit: keine — der Ausfall einer einzigen Platte führt zum Totalverlust aller Daten. Einsatz nur für temporäre Daten, Caches oder Scratch-Volumes, die jederzeit reproduzierbar sind.
• RAID 1 — Mirroring: Identische Kopie auf zwei (oder mehr) Platten. Kapazität: 50 % (n/2 × Disk). Lesezugriffe können auf beide Platten verteilt werden (nahezu doppelte Lesegeschwindigkeit). Schreibzugriffe werden auf beiden Platten parallel ausgeführt, sind aber durch die langsamere Platte limitiert. Überlebt den Ausfall einer Platte pro Spiegel. Ideal für Betriebssystem-Volumes, Boot-Partitionen und kleine Datenbanken.
• RAID 5 — Striping mit verteilter Parity: Daten und Paritätsinformationen werden über alle Platten verteilt. Kapazität: (n-1) × Disk (Minimum 3 Platten). Gute Leseperformance, aber Schreiboperationen erfordern ein Read-Modify-Write (Daten + Parität lesen, neue Parität berechnen, beides schreiben) — bekannt als Write Penalty. Überlebt den Ausfall einer Platte. Aufgrund der URE-Problematik bei Platten >4 TB zunehmend durch RAID 6 ersetzt.
• RAID 6 — Double Parity: Wie RAID 5, aber mit zwei unabhängigen Paritätsberechnungen (P+Q, basierend auf Reed-Solomon-Codes oder Galois-Feld-Arithmetik). Kapazität: (n-2) × Disk (Minimum 4 Platten). Überlebt den gleichzeitigen Ausfall von zwei Platten. Der höhere Write Penalty (6 I/O-Operationen pro Schreibvorgang) wird durch Write-Back-Cache des RAID-Controllers kompensiert. Empfohlen für alle Produktivumgebungen mit Platten ≥4 TB.
• RAID 10 — Stripe of Mirrors: Kombiniert RAID 1 (Mirroring) und RAID 0 (Striping). Kapazität: 50 % (n/2 × Disk, Minimum 4 Platten). Höchste Lese- und Schreib-Performance aller redundanten RAID-Level, da kein Parity-Overhead. Überlebt mindestens einen Plattenausfall pro Spiegel-Paar — im besten Fall die Hälfte aller Platten. Schnellster Rebuild, da nur eine einzelne Platte gespiegelt werden muss. Erste Wahl für Datenbanken, Virtualisierung und hochperformante Workloads.

Best Practices für RAID-Konfiguration und Betrieb

Der häufigste und gefährlichste Irrtum im Zusammenhang mit RAID lautet: „RAID ist ein Backup.“ Das ist falsch. RAID schützt ausschließlich vor dem physischen Ausfall einzelner Datenträger. Gegen versehentliches Löschen, Ransomware-Verschlüsselung, Controller-Defekte, Firmware-Bugs oder Brände bietet RAID keinerlei Schutz. Ein vollständiges 3-2-1-Backup-Konzept (3 Kopien, 2 verschiedene Medientypen, 1 Offsite-Kopie) ist zwingend erforderlich — unabhängig vom eingesetzten RAID-Level.

Die Wahl zwischen Hardware-RAID, Software-RAID und Fake-RAID hat erhebliche Auswirkungen auf Performance, Zuverlässigkeit und Flexibilität. Hardware-RAID-Controller (z. B. Broadcom MegaRAID, Microchip Adaptec) verfügen über einen eigenen Prozessor und Battery-Backed Write Cache (BBU) oder Flash-Backed Write Cache (FBU), der Schreiboperationen puffert und so die Performance dramatisch verbessert. Software-RAID (Linux mdadm, Windows Storage Spaces, ZFS, Btrfs) nutzt die Server-CPU für RAID-Berechnungen und bietet mehr Flexibilität — insbesondere ZFS und Btrfs mit integrierter Prüfsummenvalidierung gegen Silent Data Corruption (Bit Rot). Fake-RAID (im BIOS integrierter RAID-Modus günstiger Mainboards) sollte in Produktionsumgebungen vermieden werden, da er weder die Performance von Hardware-RAID noch die Flexibilität von Software-RAID bietet.

Moderne Speicherumgebungen setzen zunehmend auf SSD-RAID, das besondere Anforderungen stellt. SSDs haben keine mechanischen Bauteile und damit keine Seek-Time, was RAID-5/6-Write-Penalty-Berechnungen verändert. Gleichzeitig müssen RAID-Controller TRIM/UNMAP-Kommandos an die SSDs durchreichen können, um Wear-Leveling und Garbage Collection zu ermöglichen. Nicht alle Hardware-RAID-Controller unterstützen TRIM — in solchen Fällen ist Software-RAID (ZFS, mdadm) die bessere Wahl. Die endliche Schreiblebensdauer von SSDs (gemessen in DWPD — Drive Writes Per Day) muss bei der Kapazitätsplanung berücksichtigt werden.

• RAID ist kein Backup: RAID schützt nur vor Plattenausfällen. Ransomware, versehentliches Löschen, Controller-Defekte und Katastrophen erfordern ein separates 3-2-1-Backup. Testen Sie regelmäßig die Wiederherstellbarkeit Ihrer Backups — ein ungetestetes Backup ist kein Backup.
• Hot Spare konfigurieren: Ein dedizierter Hot Spare wird automatisch in den Verbund eingebunden, sobald eine Platte ausfällt — ohne manuellen Eingriff. Dies reduziert das kritische Rebuild-Fenster von Stunden auf die Reaktionszeit des Controllers (Sekunden). Globale Hot Spares bedienen mehrere Arrays, dedizierte Hot Spares nur ein bestimmtes Array.
• Rebuild-Monitoring: Während eines Rebuilds ist das Array im degradierten Zustand — ein weiterer Plattenausfall kann zum Datenverlust führen. Überwachen Sie Rebuild-Fortschritt, I/O-Latenz und Plattentemperaturen aktiv. Konfigurieren Sie Rebuild-Priorität (High) und limitieren Sie gleichzeitige Produktions-I/O während des Rebuilds.
• Battery-Backed Write Cache (BBU/FBU): Hardware-RAID-Controller sollten immer mit funktionsfähigem Write-Cache-Schutz betrieben werden. Bei Ausfall der BBU/FBU schaltet der Controller auf Write-Through um, was die Schreibperformance um den Faktor 10–100x reduzieren kann. Überwachen Sie den BBU-Status und planen Sie den präventiven Austausch alle 2–3 Jahre.
• SSD-RAID vs. HDD-RAID: Bei SSD-RAID auf TRIM-Unterstützung des Controllers achten (mdadm und ZFS reichen TRIM durch). SSD-Endurance (DWPD) bei der Planung berücksichtigen. Für gemischte Workloads bieten Tiered-Storage-Lösungen (SSD-Tier für Hot Data, HDD-Tier für Cold Data) den besten Kompromiss aus Performance und Kosten.
• ZFS / Btrfs Software-RAID: Dateisystem-integriertes RAID mit End-to-End-Checksummen erkennt und repariert Silent Data Corruption (Bit Rot) automatisch. ZFS RAIDZ1/Z2/Z3 entspricht konzeptionell RAID 5/6 mit dreifacher Parität. Copy-on-Write und Snapshots bieten zusätzliche Datensicherheit. Nachteil: höherer RAM-Bedarf (Faustregel: 1 GB RAM pro TB Storage für ZFS).