Software-RAID unter Linux einrichten, überwachen und retten
Eine einzelne Festplatte ist immer nur eine Frage der Zeit. RAID mit mdadm verteilt Daten redundant über mehrere Platten, sodass ein Festplattenausfall den Server nicht sofort lahmlegt, sondern im laufenden Betrieb behoben werden kann.
Inhaltsverzeichnis
- 1. Warum Software-RAID mit mdadm noch relevant ist
- 2. RAID-Level im Überblick: 0, 1, 5, 6, 10
- 3. Ein RAID-Array mit mdadm anlegen
- 4. Array-Konfiguration dauerhaft speichern
- 5. Status prüfen und Arrays überwachen
- 6. Eine defekte Platte erkennen und ersetzen
- 7. E-Mail-Benachrichtigungen bei Array-Problemen
- 8. Performance-Aspekte und typische Fallstricke
- 9. RAID-Level im direkten Vergleich
- 10. Zusammenfassung
- 11. FAQ
1. Warum Software-RAID mit mdadm noch relevant ist
RAID (Redundant Array of Independent Disks) verteilt Daten über mehrere physische Festplatten, um entweder Ausfallsicherheit, Performance oder beides gleichzeitig zu gewinnen. Unter Linux übernimmt mdadm (Multiple Disk Administration) diese Aufgabe komplett in Software, ohne dass ein teurer Hardware-RAID-Controller nötig ist. Gerade auf virtuellen Servern und in Cloud-Umgebungen, wo Hardware-RAID ohnehin nicht verfügbar ist, ist mdadm die einzig praktikable Option, um lokale Datenredundanz herzustellen.
Ein RAID mit mdadm ersetzt kein Backup, das ist ein häufiges Missverständnis. RAID schützt ausschließlich vor dem Ausfall einzelner Festplatten, nicht vor versehentlichem Löschen, Ransomware oder einem Fehler in der Anwendung, der falsche Daten schreibt. Wer produktive Datenbanken oder Medienverzeichnisse betreibt, kombiniert RAID mit einer separaten Backup-Strategie, RAID sorgt dabei für Verfügbarkeit im laufenden Betrieb, das Backup für Wiederherstellbarkeit nach einem logischen Fehler.
2. RAID-Level im Überblick: 0, 1, 5, 6, 10
Die Wahl des richtigen RAID-Levels bestimmt, wie viel nutzbarer Speicherplatz übrig bleibt und wie viele Plattenausfälle das Array verkraften kann. RAID 0 verteilt Daten ohne jede Redundanz über mehrere Platten und maximiert nur die Geschwindigkeit, fällt eine Platte aus, sind alle Daten verloren. RAID 1 spiegelt Daten identisch auf zwei Platten, verliert dabei die Hälfte der Rohkapazität, verkraftet aber den Ausfall einer der beiden Platten ohne Datenverlust.
RAID 5 verteilt Daten und eine Paritätsinformation über mindestens drei Platten und verkraftet den Ausfall genau einer Platte, bei größeren Arrays mit vielen Terabyte pro Platte wird das Wiederherstellungsrisiko während des Rebuilds jedoch spürbar. RAID 6 erweitert dieses Prinzip um eine zweite Parität und verkraftet zwei gleichzeitige Ausfälle, kostet dafür mehr Kapazität. RAID 10 kombiniert Spiegelung und Streifenbildung, bietet die beste Kombination aus Performance und Ausfallsicherheit, benötigt dafür aber mindestens vier Platten und die Hälfte der Rohkapazität als Overhead.
3. Ein RAID-Array mit mdadm anlegen
Das Anlegen eines Arrays mit mdadm --create benötigt drei Angaben: den Namen des resultierenden Gerätes (üblicherweise /dev/md0), das gewünschte RAID-Level und die Liste der beteiligten Festplatten. Alle beteiligten Platten sollten identisch groß sein, mdadm richtet sich sonst nach der kleinsten Platte und verschenkt Kapazität auf den größeren Geräten.
# Create a RAID 1 mirror from two identical disks
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
# Create a RAID 5 array from four disks (one disk worth of parity)
sudo mdadm --create /dev/md1 --level=5 --raid-devices=4 \
/dev/sdd /dev/sde /dev/sdf /dev/sdg
# Watch the initial sync progress
cat /proc/mdstat
Direkt nach dem Anlegen beginnt mdadm im Hintergrund mit der initialen Synchronisation, bei RAID 1 wird dabei jedes Bit gespiegelt, bei RAID 5 und 6 werden die Paritätsdaten berechnet. Dieser Vorgang kann bei großen Platten mehrere Stunden dauern, das Array ist währenddessen aber bereits nutzbar, wenn auch mit reduzierter Performance. Der Fortschritt lässt sich jederzeit über /proc/mdstat verfolgen.
4. Array-Konfiguration dauerhaft speichern
Ein frisch mit mdadm --create angelegtes Array ist zunächst nur im laufenden System bekannt, nach einem Neustart müsste es sonst manuell wieder zusammengesetzt werden. Die Lösung ist ein Eintrag in /etc/mdadm/mdadm.conf, der die Array-Signatur beschreibt und mdadm beim Boot anweist, das Array automatisch zu erkennen und einzuhängen.
# Persist the array definition so mdadm assembles it automatically on boot
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
# Rebuild the initramfs so the boot process knows about the array
sudo update-initramfs -u
# /etc/fstab entry for the resulting RAID device
UUID=7b2e9f10-4a3c-4d5e-8f61-2b9c0e1a3d44 /var/lib/mysql ext4 defaults,noatime 0 2
Nach der Änderung an mdadm.conf muss die initramfs neu gebaut werden, weil die früheste Phase des Boot-Prozesses das RAID-Array unter Umständen schon braucht, etwa wenn das Root-Dateisystem selbst auf dem Array liegt. Wer diesen Schritt vergisst, erlebt nach dem nächsten Neustart ein Array, das nicht automatisch zusammengesetzt wird, obwohl die Konfigurationsdatei korrekt aussieht.
5. Status prüfen und Arrays überwachen
Der schnellste Weg, den Zustand aller Arrays auf einen Blick zu sehen, ist cat /proc/mdstat, das jede Zeile mit Level, beteiligten Platten und Sync-Status auflistet. Für Details zu einem einzelnen Array, etwa welche Platte aktuell als Spare markiert ist oder wie weit ein Rebuild fortgeschritten ist, liefert mdadm --detail die vollständige Übersicht.
# Current status of every assembled array
cat /proc/mdstat
# Detailed view: disk states, spare devices, sync progress
sudo mdadm --detail /dev/md0
# Trigger a full data scrub (detects silent bit-rot)
echo check | sudo tee /sys/block/md0/md/sync_action
# Read the scrub result afterwards
cat /sys/block/md0/md/mismatch_cnt
Ein regelmäßiger Data-Scrub, ausgelöst über sync_action, vergleicht bei RAID 1 die gespiegelten Kopien beziehungsweise bei RAID 5/6 Daten und Parität und deckt sogenanntes Bit-Rot auf, stille Bitfehler, die sich sonst erst beim nächsten Plattenausfall bemerkbar machen würden. Die meisten Distributionen richten diesen Scrub bereits als monatlichen Cronjob ein, ein Blick in /etc/cron.d/mdadm zeigt, ob das der Fall ist.
6. Eine defekte Platte erkennen und ersetzen
Fällt eine Platte in einem redundanten Array aus, meldet mdstat das Array als degraded, es läuft weiter, aber ohne Redundanz. Der Austausch erfolgt in drei Schritten: die defekte Platte wird explizit als failed markiert, danach aus dem Array entfernt, und erst dann wird die neue Platte hinzugefügt. mdadm startet den Rebuild automatisch, sobald die neue Platte erkannt wird.
# Mark a disk as failed and remove it from the array
sudo mdadm /dev/md0 --fail /dev/sdc
sudo mdadm /dev/md0 --remove /dev/sdc
# Add the replacement disk (must be the same size or larger)
sudo mdadm /dev/md0 --add /dev/sdh
# Watch the rebuild progress
watch cat /proc/mdstat
Während des Rebuilds ist das Array besonders verwundbar, bei RAID 5 zum Beispiel besteht in dieser Phase keine Redundanz mehr, ein zweiter Plattenausfall würde zum vollständigen Datenverlust führen. Genau aus diesem Grund gilt RAID 6 oder RAID 10 bei größeren Arrays mit vielen Terabyte pro Platte als deutlich sicherere Wahl, weil die Rebuild-Zeiten bei großen Platten mittlerweile viele Stunden betragen können.
7. E-Mail-Benachrichtigungen bei Array-Problemen
Ein degradiertes Array, das niemand bemerkt, ist in der Praxis fast so gefährlich wie kein RAID. Der mdadm-eigene Monitoring-Daemon mdmonitor (oder mdadm --monitor) beobachtet alle konfigurierten Arrays im Hintergrund und verschickt bei Ereignissen wie einem Plattenausfall, einem abgeschlossenen Rebuild oder einem erkannten Fehler automatisch eine E-Mail.
Die Konfiguration erfolgt über die Variable MAILADDR in mdadm.conf, ein funktionierender lokaler Mailversand (etwa über Postfix als Relay zu einem externen SMTP-Server) ist dafür Voraussetzung. Ohne diesen Schritt bleibt ein Plattenausfall unter Umständen wochenlang unbemerkt, bis der zweite Ausfall im selben Array zum kompletten Datenverlust führt.
8. Performance-Aspekte und typische Fallstricke
RAID 5 und RAID 6 haben einen spürbaren Schreib-Overhead, den sogenannten Write-Hole beziehungsweise die Notwendigkeit, Parität bei jedem Schreibzugriff neu zu berechnen. Für Datenbank-Workloads mit vielen kleinen, zufälligen Schreibzugriffen ist RAID 10 daher in aller Regel die bessere Wahl, auch wenn es mehr Rohkapazität kostet. RAID 0 sollte auf Produktivsystemen nur für Daten verwendet werden, deren Verlust unkritisch ist, etwa reine Cache-Verzeichnisse.
# /etc/mdadm/mdadm.conf: enable email alerts for array events
MAILADDR ops@mironsoft.de
MAILFROM raid-monitor@mironsoft.de
# Restart the monitoring daemon after changing the config
sudo systemctl restart mdmonitor
sudo systemctl status mdmonitor
Ein häufiger Fallstrick: mdadm erkennt Arrays anhand von Metadaten, die am Anfang oder Ende jeder beteiligten Platte gespeichert werden, wird eine Platte für ein anderes Array wiederverwendet, ohne die alten Metadaten zu löschen, kann mdadm beim nächsten Boot verwirrende Assemblierungsfehler produzieren. mdadm --zero-superblock entfernt diese Reste sauber, bevor eine Platte in ein neues Array übernommen wird.
9. RAID-Level im direkten Vergleich
Jedes RAID-Level ist ein Kompromiss zwischen Kapazität, Performance und Ausfallsicherheit. Die folgende Übersicht zeigt, wann welches Level mit mdadm sinnvoll ist.
| Anforderung | Ungeeignetes Level | Empfohlenes Level mit mdadm | Grund |
|---|---|---|---|
| Nur Performance, unkritische Daten | RAID 5 (unnötiger Overhead) | RAID 0 | Volle Geschwindigkeit, keine Redundanz nötig |
| Zwei Platten, hohe Sicherheit | RAID 0 (kein Schutz) | RAID 1 | Einfache Spiegelung, ein Ausfall verkraftbar |
| Datenbank mit vielen Random-Writes | RAID 5 (Write-Overhead) | RAID 10 | Beste Schreibperformance bei Redundanz |
| Großes Archiv, viele Platten | RAID 5 (Rebuild-Risiko) | RAID 6 | Zwei Ausfälle gleichzeitig verkraftbar |
| Root-Dateisystem absichern | Kein RAID | RAID 1 auf System-Platten | Server bootet trotz Plattenausfall weiter |
In der Praxis dominiert bei Datenbanken RAID 10, bei großen Medienarchiven mit selteneren Schreibzugriffen RAID 6. RAID 5 hat auf modernen, großen Platten wegen der langen Rebuild-Zeiten an Attraktivität verloren, bleibt aber bei kleineren Arrays mit drei bis vier Platten ein solider Kompromiss.
Mironsoft
Linux-Server-Administration, Storage-Redundanz und Ausfallsicherheit
Server, die einen Plattenausfall einfach wegstecken?
Wir planen und richten RAID-Arrays mit mdadm für eure Produktivserver ein, inklusive Monitoring, E-Mail-Alerting und einer sauberen Trennung von RAID-Redundanz und echter Backup-Strategie.
RAID-Planung
Level-Auswahl passend zum Workload: Datenbank, Medienarchiv oder Root-Dateisystem
Monitoring & Alerting
mdmonitor-Einrichtung mit E-Mail-Benachrichtigung bei Plattenausfällen
Notfall-Wiederherstellung
Austausch defekter Platten im laufenden Betrieb ohne Downtime
10. Zusammenfassung
RAID mit mdadm schützt Linux-Server vor dem Ausfall einzelner Festplatten, ersetzt aber kein Backup. Die Wahl des richtigen RAID-Levels, von RAID 1 für einfache Spiegelung bis RAID 10 für Datenbank-Workloads, entscheidet über Kapazität, Performance und wie viele gleichzeitige Ausfälle das Array verkraftet.
Ein Array ohne Monitoring ist nur die halbe Absicherung: erst die Kombination aus /proc/mdstat, regelmäßigem Data-Scrub und E-Mail-Benachrichtigung bei Ereignissen macht aus mdadm ein verlässliches Werkzeug für den produktiven Betrieb.
RAID mit mdadm: Das Wichtigste auf einen Blick
Level-Wahl
RAID 1 für einfache Spiegelung, RAID 10 für Datenbanken, RAID 6 für große Archive mit vielen Platten.
Einrichtung
mdadm --create legt das Array an, ein Eintrag in mdadm.conf plus initramfs-Update macht es dauerhaft.
Monitoring
/proc/mdstat für den Überblick, mdadm --detail für Details, regelmäßiger Data-Scrub gegen Bit-Rot.
Kein Backup-Ersatz
RAID schützt vor Plattenausfall, nicht vor Löschfehlern oder Ransomware. Backup bleibt zusätzlich Pflicht.