Was ist RAID? RAID 0, 1, 5, 6 und 10 einfach erklärt, mit echten Tests (2026)

Was ist RAID? RAID steht für Redundant Array of Independent Disks und bedeutet: Mehrere Festplatten oder SSDs werden so zusammengeschaltet, dass das Betriebssystem sie wie ein einziges Laufwerk sieht. Je nach Verfahren, dem sogenannten RAID-Level, wird das Laufwerk dadurch schneller, ausfallsicherer oder beides. RAID 1 spiegelt zum Beispiel jede Platte auf eine zweite, damit der Server weiterläuft, wenn eine davon stirbt. RAID 0 verteilt die Daten dagegen nur auf mehrere Platten und macht das System schneller, aber nicht sicherer.

Das ist die Lehrbuch-Antwort. Weil wir solche Sätze nicht einfach abschreiben wollten, haben wir am 8. Oktober 2026 auf einem Linux-Server mit mdadm (Version 4.3, Kernel 6.8) echte RAID-Verbünde gebaut, Platten absichtlich ausfallen lassen, Daten gelöscht und Bits verdreht. Drei Ergebnisse vorweg:

1. Eine Platte aus einem RAID 1 zu ziehen, hat der Server nicht einmal bemerkt: Die Prüfsumme einer 200-MiB-Datei war danach identisch. Eine Datei zu löschen, war dagegen sofort auf beiden Platten endgültig. RAID schützt vor Hardware, nicht vor Fehlern.

2. Wir haben auf einer der beiden Spiegelplatten heimlich 8 MiB Daten zerstört. Der Befehl repair hat das gefunden und „repariert”, und zwar, indem er die kaputte Kopie über die gute geschrieben hat. Danach waren beide Platten wieder identisch, und beide falsch.

3. Der Server, auf dem dieser Blog läuft, hat gar kein RAID: /proc/mdstat ist leer, es gibt genau eine virtuelle Platte. Das ist bei einem VPS normal und kein Fehler. Warum, steht weiter unten.

Was ist RAID? Die Grundidee in einer Minute

Eine einzelne Festplatte hat zwei Probleme: Sie ist irgendwann zu langsam, und sie geht irgendwann kaputt. RAID löst beides, indem mehrere Platten zusammenarbeiten. Dafür gibt es genau drei Werkzeuge, aus denen sich alle RAID-Level zusammensetzen:

Der Name stammt aus einem Aufsatz von David Patterson, Garth Gibson und Randy Katz an der University of California, Berkeley, aus dem Jahr 1988. Damals stand das „I” noch für Inexpensive: Statt einer teuren Großrechner-Platte sollten viele billige PC-Platten zusammenarbeiten. Heute sagt man meist Independent, gemeint ist dasselbe.

Wichtig für das Verständnis: Für das Betriebssystem und alle Programme darüber ist ein RAID ein ganz normales Laufwerk. Unter Linux heißt es zum Beispiel /dev/md0, darauf liegt ein Dateisystem wie ext4, und keine Anwendung weiß, dass darunter zwei, vier oder zwölf Platten arbeiten. Genau das ist der Grund, warum RAID keine Backups ersetzen kann, dazu gleich mehr.

Gute Einführung in die vier gängigen Level aus Sicht der IT-Ausbildung. Hinweis: Der Kanal wirbt im Video für seinen eigenen Prüfungskurs.

Die RAID-Level im Überblick

Es gibt offiziell RAID 0 bis RAID 6 und eine Reihe von Kombinationen. In der Praxis begegnen dir heute fast nur noch fünf: RAID 0, 1, 5, 6 und 10. RAID 2, 3 und 4 sind historisch und spielen außerhalb von Prüfungsfragen kaum noch eine Rolle.

RAID 0: Striping, schnell und ohne Netz

RAID 0 verteilt die Daten blockweise auf alle Platten. Bei zwei Platten landet Block 1 auf Platte A, Block 2 auf Platte B, Block 3 wieder auf A und so weiter. Beim Lesen und Schreiben arbeiten beide Platten gleichzeitig, deshalb ist RAID 0 bei großen Dateien ungefähr so viel schneller, wie Platten beteiligt sind.

Der Haken: Es gibt keinerlei Redundanz. Jede Datei ist über alle Platten verstreut. Stirbt eine einzige Platte, fehlt von fast jeder Datei ein Stück, und das gesamte Laufwerk ist verloren. Ein RAID 0 aus zwei Platten ist also doppelt so ausfallgefährdet wie eine einzelne Platte. Streng genommen ist das „R” in RAID 0 eine Lüge.

In unserem Test hat mdadm sich sogar geweigert, eine Platte aus dem RAID 0 als defekt zu markieren: „Cannot remove /dev/loop4 from /dev/md94, array will be failed.” Das Programm schützt dich also vor dem Klick, aber nicht vor der Hardware. Wenn die Platte wirklich stirbt, fragt sie nicht.

Sinnvoll für: Scratch-Speicher, Video-Schnitt-Caches, Build-Verzeichnisse, alles, was sich jederzeit neu erzeugen lässt.

RAID 1: Spiegelung, einfach und robust

RAID 1 schreibt jeden Block identisch auf zwei (oder mehr) Platten. Fällt eine aus, läuft das System mit der anderen einfach weiter. Nutzbar ist nur die Kapazität einer Platte, die Hälfte des gekauften Speichers geht also für die Sicherheit drauf.

RAID 1 ist der Standard bei gemieteten Dedicated Servern: Die meisten Anbieter liefern ihre Maschinen mit zwei Platten aus, genau dafür. Auch wir empfehlen das in unserem Vergleich VPS vs. Dedicated Server als absolute Untergrenze.

Sinnvoll für: Systemplatten, kleine Server, alles mit zwei Laufwerken.

RAID 5: Parität über drei oder mehr Platten

RAID 5 braucht mindestens drei Platten. Die Daten werden wie bei RAID 0 verteilt, zusätzlich wird pro Streifen ein Paritätsblock berechnet und reihum auf den Platten abgelegt. Die Parität ist im Kern eine XOR-Verknüpfung: Kennt man alle Blöcke eines Streifens bis auf einen, lässt sich der fehlende ausrechnen.

Damit darf eine beliebige Platte ausfallen. Die Kapazität einer Platte geht für Parität drauf, bei drei Platten bleiben also zwei Drittel nutzbar, bei acht Platten sieben Achtel. Das macht RAID 5 auf dem Papier sehr attraktiv.

In der Praxis hat RAID 5 aber einen schlechten Ruf, und der ist verdient. Nach dem Ausfall einer Platte ist das Array ohne jede Redundanz, und zwar so lange, bis der Rebuild fertig ist. Dafür muss jedes einzelne Bit aller übrigen Platten fehlerfrei gelesen werden. Bei großen Festplatten dauert das viele Stunden, und genau in dieser Zeit sind die alten Platten am stärksten belastet. Mehr dazu im Abschnitt über Rebuilds.

RAID 6: doppelte Parität

RAID 6 funktioniert wie RAID 5, legt aber zwei unabhängige Paritätsblöcke pro Streifen ab. Es braucht mindestens vier Platten, und es dürfen zwei beliebige gleichzeitig ausfallen. Der Preis: zwei Platten Kapazität und etwas mehr Rechenaufwand beim Schreiben. Bei großen Arrays mit vielen Festplatten ist RAID 6 heute die vernünftige Wahl statt RAID 5.

RAID 10: Spiegeln und Verteilen

RAID 10 (gesprochen „eins-null”, nicht „zehn”) kombiniert beides: Die Platten werden paarweise gespiegelt, und über die Paare wird gestriped. Bei vier Platten entstehen zwei Spiegelpaare, über die die Daten verteilt werden. Ergebnis: Tempo fast wie RAID 0, Ausfallsicherheit wie RAID 1, und sehr schnelle Rebuilds, weil nur eine Platte kopiert werden muss statt aus allen anderen zurückgerechnet.

Der Nachteil ist wieder die Kapazität: Nur die Hälfte ist nutzbar. Dafür ist RAID 10 der Liebling für Datenbanken und virtuelle Maschinen, bei denen viele kleine, zufällige Schreibzugriffe passieren, die RAID 5 und 6 wegen der Paritätsberechnung bremsen.

Eine Feinheit, die oft falsch erklärt wird: RAID 10 übersteht mindestens eine ausgefallene Platte, im besten Fall sogar zwei, aber nur, wenn sie aus verschiedenen Spiegelpaaren stammen. Sterben beide Platten desselben Paars, ist das Array verloren.

RAID-Level im Vergleich: Kapazität, Ausfallsicherheit, Einsatz

Wir haben alle fünf Level mit mdadm auf jeweils gleich großen Test-Laufwerken (je 512 MiB) angelegt und abgelesen, wie viel Platz übrig bleibt. Die Werte sind gemessen, nicht ausgerechnet:

Die kleinen Differenzen (1.020 statt 1.024 MiB) sind die Metadaten, die mdadm am Anfang jeder Platte ablegt. Die Formel für die Praxis:

• RAID 0: Summe aller Platten
• RAID 1: eine Platte
• RAID 5: (Anzahl − 1) × Plattengröße
• RAID 6: (Anzahl − 2) × Plattengröße
• RAID 10: Hälfte der Summe

Bei unterschiedlich großen Platten zählt immer die kleinste. Wer eine 4-TB- und eine 8-TB-Platte spiegelt, bekommt 4 TB, die restlichen 4 TB liegen brach.

Was wir getestet haben: RAID 1 unter Beschuss

Für die Tests haben wir auf unserem Server vier Image-Dateien angelegt und als Loop-Geräte eingebunden. Das ist die übliche Methode, um RAID gefahrlos auszuprobieren, ohne echte Platten zu opfern. Wer es nachmachen möchte:

# Vier Test-"Platten" à 512 MiB als Dateien anlegen
for i in 0 1 2 3; do truncate -s 512M d$i.img; done
for i in 0 1 2 3; do losetup -f --show d$i.img; done
# Ausgabe z. B.: /dev/loop4 /dev/loop12 /dev/loop19 /dev/loop21

# RAID 1 aus zwei davon bauen
mdadm --create /dev/md90 --level=1 --raid-devices=2 /dev/loop4 /dev/loop12
cat /proc/mdstat

Das Anlegen dauerte 0,04 Sekunden, danach synchronisiert mdadm die beiden Platten im Hintergrund. In /proc/mdstat sieht das so aus:

md90 : active raid1 loop12[1] loop4[0]
      523264 blocks super 1.2 [2/2] [UU]
      [=======>.............]  resync = 38.5% (201728/523264)

[2/2] [UU] ist die wichtigste Zeile, die du dir merken solltest: zwei von zwei Platten aktiv, beide Up. Steht da [2/1] [_U], fehlt eine.

Test 1: Eine Platte fällt aus

Wir haben ein ext4-Dateisystem angelegt, eine 200 MiB große Zufallsdatei geschrieben, ihre Prüfsumme notiert und dann eine Platte für defekt erklärt:

mdadm /dev/md90 --fail /dev/loop4
cat /proc/mdstat
# md90 : active raid1 loop12[1] loop4[0](F)
#       523264 blocks super 1.2 [2/1] [_U]

Danach haben wir den Lese-Cache des Kernels geleert und die Datei erneut geprüft. Ergebnis: identische Prüfsumme (ade88f31… vorher wie nachher). Für jede Anwendung auf dem Server war nichts passiert. Genau dafür ist RAID gebaut.

Und genau das ist auch die Gefahr: Ein RAID, das degradiert läuft, sieht von außen völlig gesund aus. Wenn niemand auf /proc/mdstat schaut, läuft der Server womöglich monatelang auf einer einzigen Platte, und der eigentliche Schutz existiert nur noch auf dem Papier.

Test 2: Eine Datei wird gelöscht

Auf demselben, gerade degradierten Array haben wir die Datei gelöscht. Sie war weg. Nicht auf einer Platte, sondern auf dem RAID, denn für das RAID ist das Löschen ein ganz normaler Schreibvorgang, der brav auf alle Spiegel verteilt wird. Gleiches gilt für einen Verschlüsselungstrojaner, ein fehlerhaftes Update, ein versehentliches rm -rf oder ein kaputtes Datenbank-Migrationsskript.

Test 3: Rebuild nach Plattentausch

Dann haben wir die „defekte” Platte entfernt, gelöscht und als frische Platte wieder hinzugefügt:

mdadm /dev/md90 --remove /dev/loop4
wipefs -a /dev/loop4
mdadm /dev/md90 --add /dev/loop4
mdadm --wait /dev/md90

Der Rebuild über 511 MiB dauerte 2,2 Sekunden. Das klingt beeindruckend, ist aber eine Testumgebung: Die Loop-Geräte liegen auf einer SSD, und es waren nur ein halbes Gigabyte. Bei echten Festplatten rechnet man anders, und das ist der eigentlich wichtige Teil.

Test 4: Stille Datenfehler, und warum repair sie verschlimmert

Platten fallen nicht immer laut aus. Manchmal liefern sie einfach falsche Daten zurück, ohne Fehlermeldung. Man nennt das stille Datenkorruption oder Bit Rot. Um zu sehen, wie RAID damit umgeht, haben wir an mdadm vorbei direkt auf eine der beiden Spiegelplatten 4 MiB Zufallsdaten geschrieben und dann den eingebauten Konsistenzcheck gestartet:

echo check > /sys/block/md90/md/sync_action
mdadm --wait /dev/md90
cat /sys/block/md90/md/mismatch_cnt
# 8192

8.192 Sektoren à 512 Byte sind exakt die 4 MiB, die wir zerstört hatten. Der Check hat den Schaden also gefunden. Der logische nächste Schritt ist repair, danach meldete ein erneuter Check mismatch_cnt=0. Alles grün.

Aber grün heißt bei RAID 1 nur: Die beiden Platten sind wieder gleich. Nicht: Sie sind wieder richtig. Deshalb haben wir den Test wiederholt, diesmal ohne Dateisystem dazwischen, mit einem 500 MiB großen bekannten Datenmuster direkt auf dem Array, und haben gezielt die erste Platte beschädigt:

Das RAID hat die kaputten Daten an Anwendungen ausgeliefert, ohne Warnung, bei jedem Lesevorgang. Und repair hat dann nicht die gute Kopie wiederhergestellt, sondern die kaputte auf die gute Platte übertragen. Danach waren beide Spiegel konsistent falsch.

Das ist kein Fehler in mdadm, sondern eine Grenze des Verfahrens: Ein klassisches RAID 1 hat zwei Kopien und keine Möglichkeit zu wissen, welche stimmt. Es gibt keine Prüfsumme pro Block, also nimmt es bei einer Abweichung schlicht die erste. Die Kernel-Dokumentation zu md sagt sinngemäß dasselbe: repair macht die Kopien gleich, nicht korrekt. Schutz gegen stille Fehler bieten erst Dateisysteme mit eigenen Prüfsummen wie ZFS oder Btrfs. Die merken bei jedem Lesen, welche Kopie zur gespeicherten Prüfsumme passt, und reparieren gezielt aus der richtigen.

In der Praxis ist stille Korruption selten, weil moderne Platten intern selbst prüfen. Aber der Test zeigt, warum ein grünes RAID-Statuslicht weniger aussagt, als es scheint.

Test 5: RAID 5 verliert eine Platte

Bei RAID 5 aus drei Platten haben wir eine 300 MiB große Datei geschrieben, eine Platte als ausgefallen markiert und die Datei wieder gelesen: Prüfsumme identisch, die fehlenden Blöcke wurden live aus der Parität zurückgerechnet. Status danach: [3/2] [_UU], „clean, degraded”.

Den zweiten Ausfall wollte mdadm nicht simulieren lassen: „Cannot remove … array will be failed.” Auch das ist ehrlich: Ab hier gibt es nichts mehr zu retten. Bei echter Hardware entscheidet nicht mdadm, ob eine zweite Platte stirbt.

Der Rebuild: die gefährlichsten Stunden im Leben eines RAIDs

In unserem Test dauerte der Rebuild Sekunden. Bei echter Hardware ist er der kritischste Moment, und das aus drei Gründen.

Erstens die Dauer. Ein Rebuild muss die neue Platte vollständig beschreiben, unabhängig davon, wie viel tatsächlich belegt ist (bei mdadm; ZFS ist hier klüger und kopiert nur belegte Blöcke). Eine große Festplatte schreibt sequenziell grob 200 bis 250 MB/s. Für eine 16-TB-Platte heißt das rechnerisch:

16.000.000 MB ÷ 200 MB/s = 80.000 Sekunden ≈ 22 Stunden, im allerbesten Fall.

Läuft der Server nebenbei unter Last, drosselt der Kernel den Rebuild (Standardwerte stehen in /proc/sys/dev/raid/speed_limit_min und speed_limit_max), und aus einem Tag werden schnell zwei oder drei.

Zweitens die Belastung. Bei RAID 5 und 6 muss für den Rebuild jede einzelne verbleibende Platte komplett gelesen werden. Die Platten sind meist gleich alt, aus derselben Charge, haben dieselben Betriebsstunden. Wenn eine stirbt, sind die anderen statistisch nicht weit dahinter, und jetzt bekommen sie die höchste Last ihres Lebens.

Drittens Lesefehler. Festplattenhersteller geben für Consumer-Platten oft eine Fehlerrate von einem nicht lesbaren Sektor pro 10¹⁴ gelesenen Bits an, das sind rund 12,5 TB. Das ist eine Worst-Case-Angabe, echte Platten sind meist deutlich besser. Aber bei einem RAID 5 aus vier 16-TB-Platten werden beim Rebuild 48 TB gelesen. Selbst wenn die reale Rate zehnmal besser ist, bleibt ein Restrisiko, dass mitten im Rebuild ein Sektor nicht lesbar ist, und bei RAID 5 gibt es dann keine zweite Parität mehr, die einspringen kann. Genau deshalb raten viele Admins bei großen Festplatten von RAID 5 ab und zu RAID 6 oder RAID 10.

Was daraus folgt:

• Bei großen HDDs: RAID 6 oder RAID 10, nicht RAID 5.
• Platten aus verschiedenen Chargen oder mit versetztem Kaufdatum mischen, wenn möglich.
• Eine Hot-Spare-Platte einplanen, damit der Rebuild sofort startet und nicht erst, wenn jemand den Ausfall bemerkt.
• Vor dem Rebuild ein aktuelles Backup haben. Immer.

RAID ist kein Backup

Das ist der wichtigste Satz dieses Artikels, und er steht in jedem Forum. Trotzdem verwechseln ihn viele, weil RAID und Backup beide mit „Datensicherheit” zu tun haben. Sie lösen aber zwei völlig verschiedene Probleme:

Kurz gesagt: RAID sorgt für Verfügbarkeit, Backups sorgen für Wiederherstellbarkeit. RAID verhindert, dass dein Server um drei Uhr nachts ausfällt, weil eine Platte gestorben ist. Ein Backup verhindert, dass deine Daten weg sind, weil irgendetwas anderes schiefgegangen ist. Du brauchst beides, und wenn du dich für eins entscheiden musst, dann für das Backup.

Wie ein Backup aussieht, das diesen Namen verdient, haben wir in unserem Artikel zur 3-2-1 Backup-Strategie mit echten Restore-Tests beschrieben. Dort ist RAID übrigens ausdrücklich nicht als „zweites Medium” zugelassen.

Hardware-RAID, Software-RAID oder ZFS?

RAID lässt sich auf drei Arten umsetzen, und die Wahl ist heute klarer als vor zehn Jahren.

Hardware-RAID

Ein eigener Controller (eine Steckkarte oder ein Chip auf dem Mainboard) übernimmt die Arbeit. Das Betriebssystem sieht nur ein fertiges Laufwerk. Gute Controller haben einen Cache mit Batterie oder Kondensator, der Schreibvorgänge bei Stromausfall rettet.

Der große Nachteil: Das Array hängt am Controller. Stirbt die Karte, brauchst du in der Regel dasselbe Modell oder zumindest denselben Hersteller, um die Platten wieder lesen zu können. Außerdem verdeckt der Controller den Zustand der einzelnen Platten vor dem Betriebssystem, SMART-Werte sind oft nur über Herstellertools erreichbar.

Die sogenannten Fake-RAIDs auf Consumer-Mainboards sind übrigens meist gar kein Hardware-RAID, sondern Treiber-Software mit BIOS-Oberfläche, und vereinen die Nachteile beider Welten.

Software-RAID (mdadm unter Linux)

Linux bringt mit mdadm seit über zwanzig Jahren ein ausgereiftes Software-RAID mit. Die Rechenarbeit erledigt die CPU, was bei heutigen Prozessoren keine Rolle mehr spielt. Der Vorteil: Die Platten lassen sich in jeden anderen Linux-Rechner stecken und dort mit mdadm --assemble --scan wieder zusammensetzen. Kein Controller, keine Herstellerbindung.

Fast alle gemieteten Dedicated Server werden mit Software-RAID ausgeliefert oder lassen sich bei der Installation damit einrichten. Für die meisten Linux-Server ist das die richtige Wahl.

ZFS und Btrfs

ZFS (und mit Einschränkungen Btrfs) vereinen Dateisystem und Volume-Manager. Sie bieten eigene RAID-Varianten: Mirror, RAID-Z1 (entspricht RAID 5), RAID-Z2 (RAID 6) und RAID-Z3. Der entscheidende Unterschied ist die Prüfsumme pro Block. Damit lösen sie genau das Problem aus unserem Test 4: Bei einer Abweichung wissen sie, welche Kopie stimmt. Dazu kommen Snapshots, Kompression und Rebuilds, die nur belegte Daten kopieren.

Der Preis ist mehr Komplexität und ein höherer RAM-Bedarf bei ZFS. Und: ZFS will die Platten direkt sehen, nicht durch einen Hardware-RAID-Controller hindurch. Darauf weist auch Proxmox in seiner Dokumentation ausdrücklich hin, wir haben das im Vergleich Proxmox vs. ESXi zitiert.

Kurze, deutschsprachige Erklärung von RAID 0, 1 und 5. Das Video ist von 2020, an den Grundlagen hat sich seitdem nichts geändert.

Braucht mein Server überhaupt RAID?

Das hängt davon ab, wem die Hardware gehört.

Beim VPS oder in der Cloud: nein, jedenfalls nicht selbst. Ein VPS bekommt eine virtuelle Platte, die beim Anbieter auf einem redundanten Storage liegt, typischerweise RAID 10, Ceph oder ein ähnliches System. Zwei virtuelle Platten im selben VPS zu spiegeln, bringt nichts, weil beide auf derselben physischen Hardware landen. Unser eigener Server ist genau so ein Fall: lsblk zeigt eine einzige Platte sda, /proc/mdstat meldet unused devices: <none>. Die Redundanz ist da, nur eben eine Ebene tiefer, und nicht unter unserer Kontrolle. Umso wichtiger ist das externe Backup.

Beim Dedicated Server: ja, unbedingt. Hier gehört die Hardware für die Mietdauer dir, und damit auch ihr Ausfall. Ohne RAID bedeutet eine tote Platte: Server offline, Ticket beim Anbieter, Platte tauschen, Betriebssystem neu installieren, Backup zurückspielen. Mit RAID 1 bedeutet sie: Ticket, Platte tauschen, mdadm --add, fertig, und der Server lief die ganze Zeit.

Beim NAS zu Hause oder im Büro: Ja, meist RAID 1 bei zwei Platten, RAID 6 oder RAID-Z2 ab vier bis fünf großen Platten. Und dazu ein Backup außer Haus, denn das NAS steht im selben Raum wie der Rest und teilt dessen Schicksal bei Brand oder Einbruch.

Auf dem Desktop-PC: Selten sinnvoll. Ein ordentliches Backup bringt dort mehr als ein Spiegel.

RAID überwachen: der Teil, den alle vergessen

Ein RAID, dessen Ausfall niemand bemerkt, schützt dich genau einmal. Danach läuft es auf einer Platte, und der nächste Ausfall ist der letzte. Diese drei Dinge sollten auf jedem Server mit Software-RAID eingerichtet sein:

1. Mail bei Ausfall. mdadm hat einen eingebauten Überwachungsmodus. Auf Debian und Ubuntu läuft er nach der Installation bereits als Dienst, er braucht nur eine Empfängeradresse:

# /etc/mdadm/mdadm.conf
MAILADDR admin@example.com

# Testmail für jedes Array verschicken
mdadm --monitor --scan --test --oneshot

Damit die Mail ankommt, braucht der Server ein funktionierendes Mailsystem (zum Beispiel msmtp oder einen Postfix-Relay). Den Test wirklich ausführen, sonst weißt du nicht, ob der Alarm ankommt.

2. Regelmäßiger Konsistenzcheck. Debian und Ubuntu bringen einen monatlichen Check mit, der genau das check aus unserem Test 4 ausführt. Auf unserem Ubuntu 24.04 läuft er als systemd-Timer mdcheck_start.timer (nächster Lauf laut systemctl list-timers: 1. November, 03:52 Uhr), ältere Versionen nutzen dafür checkarray per Cron. Der Wert in mismatch_cnt sollte danach 0 sein. Ist er es nicht, stimmt etwas mit einer Platte nicht.

3. SMART-Werte der einzelnen Platten. RAID meldet erst, wenn eine Platte schon ausgefallen ist. smartmontools erkennt oft vorher, dass sie stirbt (zum Beispiel an steigenden Reallocated Sectors):

apt install smartmontools
smartctl -H /dev/sda   # Kurzbefund
smartctl -a /dev/sda   # alle Werte

Den Dienst smartd so einrichten, dass er ebenfalls eine Mail schickt. Wie du solche Prüfungen regelmäßig automatisch laufen lässt, zeigt unsere Anleitung zum Cronjob erstellen.

Eine Platte tauschen: Schritt für Schritt mit mdadm

Wenn die Mail kommt, sieht der Ablauf bei einem RAID 1 so aus:

1. Status prüfen: cat /proc/mdstat und mdadm --detail /dev/md0. Welche Platte ist als (F) markiert oder fehlt?
2. Seriennummer notieren: smartctl -i /dev/sdb. Damit der Techniker im Rechenzentrum die richtige Platte zieht. Die falsche zu ziehen, ist der klassische Weg, aus einem degradierten RAID 1 ein totes zu machen.
3. Aus dem Array entfernen: mdadm /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1 (für jede Partition bzw. jedes Array auf der Platte).
4. Platte tauschen lassen (beim Dedicated Server per Ticket beim Anbieter).
5. Partitionstabelle kopieren: Bei GPT zum Beispiel sgdisk -R /dev/sdb /dev/sda und danach sgdisk -G /dev/sdb für neue GUIDs. Achtung auf die Richtung: Ziel kommt zuerst.
6. Wieder hinzufügen: mdadm /dev/md0 --add /dev/sdb1. Der Rebuild startet automatisch.
7. Bootloader auf die neue Platte schreiben, sonst startet der Server nicht mehr, falls später die andere Platte ausfällt. Je nach System grub-install /dev/sdb.
8. Warten und beobachten: watch cat /proc/mdstat, bis wieder [UU] dasteht.

Vor Schritt 3 sollte das letzte Backup geprüft sein. Ein Rebuild ist der Moment, in dem man es am ehesten braucht.

Häufige Fragen

Was ist RAID einfach erklärt?

RAID ist ein Verfahren, bei dem mehrere Festplatten zu einem Laufwerk zusammengeschaltet werden. Je nach Variante wird das Laufwerk dadurch schneller (Daten verteilen), ausfallsicherer (Daten spiegeln oder Parität berechnen) oder beides.

Wofür steht RAID?

Redundant Array of Independent Disks, auf Deutsch etwa „redundante Anordnung unabhängiger Festplatten”. Ursprünglich stand das I für Inexpensive, also „preiswert”.

Welches RAID ist das beste?

Es gibt kein bestes, nur ein passendes. Für zwei Platten ist RAID 1 die Standardwahl. Für Datenbanken und VMs mit vier oder mehr Platten RAID 10. Für große Datenmengen auf vielen HDDs RAID 6 oder RAID-Z2. RAID 0 nur für Daten, die du jederzeit wieder erzeugen kannst.

Ist RAID ein Backup?

Nein. RAID schützt vor dem Ausfall einer Platte, nicht vor Löschen, Ransomware, Softwarefehlern, Brand oder Diebstahl. In unserem Test war eine gelöschte Datei sofort auf allen Spiegeln weg. Du brauchst zusätzlich ein Backup, idealerweise nach der 3-2-1-Regel.

Was ist der Unterschied zwischen RAID 1 und RAID 0?

RAID 1 spiegelt: gleiche Daten auf zwei Platten, eine darf ausfallen, die Hälfte der Kapazität ist nutzbar. RAID 0 verteilt: Daten wechselnd auf zwei Platten, doppelt so schnell und doppelt so groß, aber fällt eine Platte aus, ist alles weg.

Wie viele Festplatten brauche ich für RAID 5?

Mindestens drei. Nutzbar ist die Kapazität aller Platten minus einer. Bei großen Festplatten (ab etwa 8 TB) ist RAID 6 mit mindestens vier Platten die sicherere Wahl, weil der Rebuild sehr lange dauert.

Was passiert, wenn bei RAID 1 eine Platte ausfällt?

Nichts, was du ohne Überwachung bemerken würdest. Der Server liest und schreibt mit der verbleibenden Platte weiter. In unserem Test war die Prüfsumme einer Datei vor und nach dem Ausfall identisch. Du musst die Platte trotzdem schnell tauschen, denn bis dahin gibt es keine Redundanz mehr.

Kann man SSDs im RAID betreiben?

Ja, problemlos. Bei SSDs entfallen einige HDD-Probleme (Rebuilds sind deutlich schneller), dafür kommt ein neues hinzu: Zwei gleiche SSDs mit identischer Schreiblast können sich ähnlich abnutzen. Bei mdadm sollte TRIM aktiviert sein, was bei aktuellen Kerneln für RAID 1 und RAID 10 durchgereicht wird.

Hardware-RAID oder Software-RAID?

Für Linux-Server heute meist Software-RAID mit mdadm oder ZFS. Es ist hardwareunabhängig, gut dokumentiert und die CPU-Last ist vernachlässigbar. Hardware-RAID lohnt sich vor allem, wenn Controller mit batteriegepuffertem Cache gebraucht werden oder ein Betriebssystem kein brauchbares Software-RAID mitbringt.

Braucht ein VPS RAID?

Nein. Die Redundanz liegt beim Anbieter auf der Host-Ebene. Zwei virtuelle Platten im selben VPS zu spiegeln, schützt vor nichts, weil sie auf derselben Hardware liegen. Was ein VPS stattdessen braucht, ist ein externes Backup.

Wie lange dauert ein RAID-Rebuild?

Bei mdadm muss die neue Platte vollständig beschrieben werden. Bei einer HDD mit 200 MB/s sind das rechnerisch etwa 1,4 Stunden pro Terabyte, für eine 16-TB-Platte also mindestens 22 Stunden, unter Last deutlich mehr. SSDs und RAID 10 sind erheblich schneller. In unserer Testumgebung dauerte ein Rebuild über 511 MiB 2,2 Sekunden.

Fazit: Was ist RAID, und was ist es nicht?

RAID ist eine der ältesten und solidesten Techniken im Serverbetrieb: Mehrere Platten arbeiten als eine, und der Ausfall einer einzelnen legt nichts lahm. In unserem Test hat RAID 1 genau das geliefert, eine Platte weg und kein einziges Bit verloren.

Aber RAID beantwortet nur eine Frage: Was passiert, wenn eine Platte stirbt? Bei allen anderen Fragen schaut es weg. Gelöschte Dateien verschwinden auf allen Spiegeln, verschlüsselte Daten werden brav mitgespiegelt, und wenn eine Platte still falsche Daten liefert, kann ein klassisches RAID 1 nicht einmal sagen, welche Kopie stimmt, und macht im Zweifel die gute kaputt.

Unsere Empfehlung für 2026:

• VPS: kein eigenes RAID, aber ein externes Backup.
• Dedicated Server: mindestens Software-RAID 1, mit Mail-Alarm, der wirklich getestet ist.
• Viele große Platten: RAID 6, RAID 10 oder ZFS statt RAID 5.
• Immer: RAID und Backup, nie RAID statt Backup.

Wer gerade vor der Entscheidung steht, ob sich ein eigener Server mit RAID überhaupt lohnt, findet im Vergleich VPS vs. Dedicated Server die Rechnung dazu.