RAID-Migration von 5 auf 6: Ablauf in fünf Schritten

Der Preis ist eindeutig: mindestens ein zusätzliches Laufwerk, eine reduzierte nutzbare Kapazität und ein Re-Striping, das Controller, Datenträger und I/O-Pfad über Stunden oder Tage belastet.

Der RAID-5-auf-RAID-6-Migrationsablauf ist keine Datenkopie. Der Controller verteilt sämtliche Stripe-Segmente neu und ergänzt eine zweite, verteilte Parität. Das Volume bleibt bei geeigneter Hardware online. Online bedeutet jedoch nur: Der Zugriff kann weiterlaufen. Es bedeutet nicht: ohne Risiko, ohne Last oder ohne Leistungsabfall.

Eine Online-RAID-Level-Migration ersetzt kein geprüftes Backup. Sie verlagert den Wartungszeitraum in den laufenden Betrieb.

Technische Voraussetzungen für die Umstellung

RAID 6 benötigt mindestens vier physische Laufwerke. Ein RAID-5-Verbund mit drei Datenträgern lässt sich daher erst nach Einbau eines vierten Laufwerks migrieren. Bei größeren Arrays gilt derselbe Grundsatz: Für die Umwandlung muss mindestens ein weiterer Datenträger verfügbar sein.

Die nutzbare Kapazität berechnet sich immer mit der Kapazität des kleinsten Laufwerks im Verbund. Größere neue Laufwerke funktionieren technisch, ihr zusätzlicher Speicherbereich bleibt jedoch ungenutzt, solange nicht alle vorhandenen Laufwerke entsprechend erweitert werden.

Ein Beispiel mit fünf Laufwerken zu jeweils 12 TB verdeutlicht die Kapazitätsänderung:

• RAID 5 stellt theoretisch 48 TB nutzbare Rohkapazität bereit: (5 − 1) × 12 TB.
• RAID 6 stellt theoretisch 36 TB nutzbare Rohkapazität bereit: (5 − 2) × 12 TB.
• Die Migration erhöht nicht die nutzbare Kapazität. Sie wandelt die Kapazität eines Laufwerks in zusätzliche Redundanz um.

Vor dem Start muss der Controller die RAID-Level-Migration tatsächlich unterstützen. Aktuelle Enterprise-Controller, etwa aus den Dell-PERC- oder Intel-RAID-Familien, beherrschen diese Funktion in der Regel. Auch NAS-Systeme mit QNAP QTS oder Synology DSM bieten je nach Modell und Laufwerkskonfiguration eine Online-Migration an. Entscheidend sind Controller-Modell, Firmwarestand, installierter Cache und die genaue Ausgangskonfiguration.

Nicht jeder RAID-Controller erlaubt jede Transformation. Ein älteres Controller-Firmware-Release kann die Migration blockieren, obwohl die Hardware grundsätzlich RAID 6 unterstützt. Die Verwaltungskonsole muss explizit eine Umstellung von RAID 5 auf RAID 6 mit Laufwerkserweiterung anbieten. Fehlt diese Option, bleibt nur ein Neuaufbau des Arrays aus einem Backup.

Auch der Zustand des bestehenden RAID 5 ist ein Ausschlusskriterium. Eine Migration startet nur mit einem optimalen Arrayzustand:

• Alle Mitgliedslaufwerke stehen auf „Online“ oder „Optimal“.
• Es läuft kein Rebuild, keine Konsistenzprüfung und keine vorherige Erweiterung.
• Es gibt keine schwebenden Sektoren, Medienfehler oder Controller-Warnungen.
• Die Cache-Batterie oder der Superkondensator des Controllers arbeitet fehlerfrei.
• Die USV ist funktionsfähig und korrekt dimensioniert.
• Die Firmwarestände von Controller, Backplane und Laufwerken sind geprüft.

Ein degradiertes RAID 5 wird nicht migriert. Zuerst wird der defekte Datenträger ersetzt, der Rebuild vollständig abgeschlossen und das Ereignisprotokoll ausgewertet. Eine zweite große Schreiboperation auf einem instabilen Verbund erhöht die Wahrscheinlichkeit eines vollständigen Array-Verlusts.

Schritt 1: Backup erstellen und Wiederherstellung prüfen

Der kritische Fehler bei einer RAID-Migration ist die Gleichsetzung von Redundanz und Datensicherung. RAID 6 schützt gegen den Ausfall von zwei Laufwerken. Es schützt nicht gegen fehlerhafte Paritätsberechnung, Controllerdefekte, versehentliches Löschen, Ransomware, Firmwarefehler oder einen Stromausfall während eines Schreibvorgangs.

Vor dem Re-Striping ist ein vollständiges Backup erforderlich. Nicht nur ein Sicherungslauf mit grünem Status. Die Wiederherstellbarkeit muss überprüft werden.

Die Mindestanforderung besteht aus drei Ebenen:

1. Konsistente Datensicherung erstellen. Datenbanken, virtuelle Maschinen und Anwendungen müssen in einem wiederherstellbaren Zustand gesichert werden. Ein reines Dateikopieren während laufender Transaktionen reicht für viele Workloads nicht aus.

2. Backup außerhalb des RAID-Systems ablegen. Ein zweites Volume im selben Server ist kein unabhängiges Backup. Geeignet sind ein separates Speichersystem, eine dedizierte Backup-Appliance, ein verschlüsseltes externes Medium oder ein räumlich getrennter Sicherungsstandort.

3. Stichprobenweise Wiederherstellung durchführen. Mindestens kritische Dateien, eine virtuelle Maschine oder eine Datenbankinstanz müssen testweise zurückgespielt werden. Nur dadurch wird aus einem Backup ein belastbarer Wiederanlaufpunkt.

Die Sicherung sollte vor Beginn der Migration abgeschlossen sein. Parallel laufende inkrementelle Sicherungen sind sinnvoll, ersetzen aber nicht den konsistenten Ausgangsstand. Bei stark veränderten Datenbeständen ist zusätzlich ein definiertes Änderungsfenster erforderlich. Sonst entsteht zwischen Vollsicherung und Migrationsbeginn eine Lücke, die im Störungsfall separat rekonstruiert werden muss.

Die USV gehört in diesen Schritt. Re-Striping erzeugt über lange Zeit Schreiblast. Ein abrupter Spannungsverlust kann bei aktivem Schreibcache oder unvollständig geschriebenen Stripe-Segmenten zu einem inkonsistenten Zustand führen. Ein funktionierender batteriegestützter Cache reduziert dieses Risiko, eliminiert es aber nicht.

Schritt 2: Neues Laufwerk auswählen und physisch integrieren

Das zusätzliche Laufwerk muss mindestens die Kapazität des kleinsten vorhandenen RAID-5-Mitglieds besitzen. Bei identischen Laufwerksserien ist die Auswahl einfach. In heterogenen Beständen reicht die nominelle Kapazitätsangabe auf dem Etikett nicht immer aus.

Ein als 8-TB-HDD vermarktetes Modell kann je nach Hersteller und Sektorformat geringfügig weniger adressierbare Sektoren bereitstellen als ein anderes 8-TB-Modell. Der Controller orientiert sich an der tatsächlich verfügbaren Blockzahl. Deshalb sind gleiche Modellreihen oder mindestens identische Netto-Kapazitäten die saubere Lösung.

Für Enterprise-Storage gelten zusätzliche Kriterien:

• Schnittstelle: SAS und SATA dürfen nur kombiniert werden, wenn Backplane und Controller dies ausdrücklich unterstützen. In produktiven Arrays ist eine einheitliche Schnittstelle vorzuziehen.
• Sektorformat: 512e, 4Kn und native 512-Byte-Formate müssen zum bestehenden Verbund passen. Ein abweichendes Format kann die Aufnahme verhindern.
• Drehzahl und Latenzklasse: Eine 7.200-U/min-Nearline-SAS-HDD sollte nicht mit einer hochdrehenden 15K-SAS-HDD in einem leistungsrelevanten Array kombiniert werden.
• Fehlerbehandlung: Bei SATA-HDDs sind zeitlich begrenzte Fehlerkorrekturmechanismen erforderlich. Enterprise-Modelle mit TLER-, ERC- oder CCTL-Äquivalenten reduzieren das Risiko, dass ein Laufwerk bei einem Lesefehler zu lange blockiert und vom Controller als ausgefallen markiert wird.
• Firmwarestand: Unterschiedliche Firmware kann in Einzelfällen zu abweichendem Fehlerverhalten, höherer Latenz oder ungleichmäßiger Queue-Verarbeitung führen.
• Schreiblast: Bei SSD-Arrays müssen TBW-Wert, verbleibende Lebensdauer und der Zustand der internen Reservekapazität geprüft werden. RAID 6 erhöht die Paritätsschreibvorgänge.

Vor dem Einbau wird der freie Einschub eindeutig dokumentiert. Bei Servern mit mehreren Backplanes oder externen Erweiterungsgehäusen ist die Zuordnung von Steckplatz, Laufwerks-ID und virtuellem Datenträger relevant. Ein falsch gezogener Datenträger während der Vorbereitung kann aus einer geplanten Migration unmittelbar einen Rebuild machen.

Hot-Swap-fähige Systeme erlauben den Einbau im Betrieb. Das Laufwerk wird danach nicht sofort als Mitglied des Arrays verwendet. Zuerst muss der Controller es erkennen und seinen Zustand melden. Je nach Plattform erscheint es als „Ready“, „Unconfigured Good“, „Available“ oder als freier Datenträgerpool.

Ein Laufwerk mit dem Status „Foreign“ wird nicht ungeprüft eingebunden. Solche Datenträger enthalten häufig Metadaten eines vorherigen RAID-Verbunds. Die Fremdkonfiguration darf erst nach eindeutiger Identifikation gelöscht werden. Andernfalls besteht das Risiko, Konfigurationsinformationen falsch zuzuordnen.

Schritt 3: Controller und Array für das Re-Striping vorbereiten

Jetzt wird aus der Hardwareänderung ein geplanter Eingriff. In der Controller-Verwaltung werden zunächst der Zustand des virtuellen Datenträgers, die Cache-Policy und die Ereignisprotokolle geprüft.

Ein RAID-5-Array darf nur im Status „Optimal“ oder dem herstellerspezifischen Äquivalent umgestellt werden. Ein einzelner korrigierter Lesefehler ist nicht zwingend ein Abbruchkriterium. Häufen sich jedoch Medienfehler, Timeout-Ereignisse oder Link-Resets, ist die Migration zu verschieben. Das Array wird beim Re-Striping vollständig gelesen und umfassend beschrieben. Latente Laufwerksprobleme treten unter dieser Last deutlich häufiger zutage.

Vor dem Start sind drei Einstellungen relevant:

1. Rebuild- beziehungsweise Transformationspriorität festlegen. Eine hohe Priorität verkürzt die Migrationsdauer, reduziert aber die verfügbare I/O-Leistung für Anwendungen. Eine niedrige Priorität schont den Betrieb, verlängert jedoch das Risikozeitfenster.

2. Cache-Status kontrollieren. Write-Back-Cache ist nur mit intakter Absicherung durch Batterie oder Superkondensator vertretbar. Meldet der Controller einen Fehler am Cache-Schutz, fällt er häufig auf Write-Through zurück. Die Latenz steigt, die Migration verlängert sich erheblich.

3. Monitoring aktivieren. Erforderlich sind mindestens Warnungen für Laufwerksausfälle, Temperaturgrenzen, Controllerfehler, Cache-Zustand und Fortschrittsstillstand. Ein Migrationsprozess ohne Überwachung ist keine Betriebsstrategie.

Bei Linux-Software-RAID erfolgt die Vorbereitung anders als bei einem Hardware-Controller. Das neue Laufwerk wird zunächst als Ersatzlaufwerk in das MD-Array aufgenommen. Anschließend wird die Umformung mit mdadm --grow ausgelöst. Die exakte Syntax hängt von Gerätenamen, Array-Nummer, Ziel-RAID-Level und Laufwerksanzahl ab. Ein Befehl darf nicht aus einem allgemeinen Beispiel übernommen werden. Zuerst müssen Ausgabe von mdadm --detail, Partitionslayout und Metadatenformat zum konkreten System passen.

Bei NAS-Systemen ist die Abstraktion höher, die technischen Grenzen bleiben identisch. Die grafische Oberfläche kann die Optionen „Laufwerk hinzufügen“ und „RAID-Typ ändern“ kombinieren. Intern findet dennoch ein Re-Striping statt. Die Anzeige eines Fortschrittsbalkens ist kein Freigabesignal für Wartungsarbeiten an anderen Laufwerken.

Re-Striping ist eine Vollastoperation auf den gesamten Verbund. Parallel geplante Firmware-Updates, Neustarts und Kabelarbeiten sind in diesem Zeitraum auszuschließen.

Schritt 4: Online-RAID-Level-Migration starten

Die eigentliche RAID-Controller-Migration wird in der Verwaltungsoberfläche des Controllers oder NAS gestartet. Der Ablauf unterscheidet sich in der Bezeichnung, nicht in der Logik:

• Ziel-RAID-Level RAID 6 auswählen.
• Das neue, freie Laufwerk dem bestehenden virtuellen Datenträger zuordnen.
• Kapazitäts- und Redundanzänderung bestätigen.
• Re-Striping oder RAID-Level-Migration starten.
• Fortschritt, geschätzte Restzeit und Fehlerprotokoll überwachen.

Manche Controller führen die Erweiterung der physisch verfügbaren Laufwerke und die RAID-Level-Änderung als einen Vorgang aus. Andere verlangen zwei getrennte Schritte: zuerst Online Capacity Expansion, danach RAID Level Migration. Die Reihenfolge gibt die jeweilige Firmware vor. Ein manuelles Abkürzen ist nicht zulässig.

Während der Migration bleibt der logische Datenträger meist erreichbar. Die Performance ist jedoch nicht konstant. Besonders betroffen sind zufällige Schreibzugriffe, datenbanknahe Anwendungen, Virtualisierungs-Hosts und Systeme mit geringer Cache-Reserve. RAID 6 benötigt zwei Paritätsberechnungen. Bei einem klassischen Write-Penalty-Szenario erhöht das die Zahl der erforderlichen Ein- und Ausgaben gegenüber RAID 5.

Die Belastung hängt von mehreren Parametern ab:

Eine belastbare Laufzeitprognose ist vorab nicht möglich. Mehrere Stunden sind normal. Bei großen Festplatten, niedriger Rebuild-Priorität und laufender Produktivlast kann der Vorgang drei bis fünf Tage dauern. Die geschätzte Restzeit des Controllers ist ein dynamischer Wert. Sie verändert sich mit I/O-Last, Fehlerkorrekturen und Cache-Auslastung.

Während dieser Phase gelten klare Betriebsgrenzen:

• Keine Laufwerke umstecken oder vorsorglich ersetzen.
• Keine Controller-, BIOS- oder NAS-Firmware aktualisieren.
• Keine geplanten Neustarts durchführen.
• Keine Konsistenzprüfung parallel erzwingen, sofern der Hersteller dies nicht ausdrücklich vorsieht.
• Keine zusätzliche Volume-Erweiterung starten.
• Keine Backup-Jobs mit hoher Vollscan-Last in das engste Migrationsfenster legen, sofern dies organisatorisch vermeidbar ist.

Ein Abbruch über die Verwaltungsoberfläche ist nur dann zu erwägen, wenn die Plattform eine dokumentierte, sichere Abbruchfunktion anbietet. Ein erzwungenes Ausschalten ist keine Abbruchfunktion. Es ist ein ungeplanter Fehlerfall.

Schritt 5: Rebuild überwachen und Volume-Erweiterung abschließen

Nach dem Start wird der Prozess nicht nur auf Prozentwerte kontrolliert. Entscheidend sind Fehlerzähler, Laufwerkszustände, Temperaturdaten und die Stabilität der Transformationsrate. Ein Fortschritt von 37 Prozent mit wiederholten Medienfehlern ist kein normaler Verlauf.

Die Überwachung sollte mindestens folgende Werte erfassen:

• Status des virtuellen RAID-6-Datenträgers.
• Status jedes einzelnen physischen Laufwerks.
• Fortschritt und aktuelle Transformationsrate.
• Controller-Cache-Zustand.
• Anzahl korrigierter und nicht korrigierter Lesefehler.
• Temperatur von Laufwerken, Backplane und Controller.
• Ereignisprotokolle zu Timeouts, Resets und Kommunikationsfehlern.
• Latenzzeiten und Durchsatz der betroffenen Anwendungen.

Ein vorübergehender Einbruch bei Durchsatz und Antwortzeit ist erwartbar. Nicht erwartbar sind stark steigende Fehlerraten, wiederkehrende Laufwerksabmeldungen oder ein Fortschrittswert, der über lange Zeit ohne erkennbare I/O-Aktivität steht. In diesem Fall wird nicht reflexartig neu gestartet. Zuerst werden Controller-Protokoll, Betriebssystemmeldungen, Stromversorgung und Laufwerksdiagnostik ausgewertet.

Nach erfolgreichem Re-Striping meldet der Controller den neuen RAID-Level und die veränderte virtuelle Kapazität. Das bedeutet noch nicht automatisch, dass Betriebssystem, Hypervisor oder Dateisystem den zusätzlichen Platz verwenden können.

Hier sind drei Ebenen zu unterscheiden:

1. Physische Laufwerksebene: Das neue Laufwerk ist Mitglied des RAID-6-Verbunds.

2. RAID-Volume-Ebene: Der virtuelle Datenträger wurde auf RAID 6 umgestellt. Je nach Controller kann seine logische Größe unverändert bleiben oder nach einer separaten Erweiterung wachsen.

3. Betriebssystem- und Dateisystemebene: Partition, LVM-Physical-Volume, logisches Volume, Datastore oder Dateisystem müssen gegebenenfalls separat erweitert werden.

Bei einer reinen RAID-5-zu-RAID-6-Umwandlung mit exakt einem zusätzlichen Laufwerk entsteht häufig keine zusätzliche nutzbare Kapazität. Das zusätzliche Laufwerk kompensiert die zweite Parität. Eine Volume-Erweiterung kann daher technisch möglich, aber kapazitativ wirkungslos sein. Das Ergebnis ist höhere Redundanz, nicht mehr Speicherplatz.

Nach Abschluss folgt eine Konsistenzprüfung nach Herstellervorgabe. Sie bestätigt, dass Paritätsinformationen und Stripe-Struktur plausibel sind. Diese Prüfung wird nicht während eines noch aktiven Re-Stripings erzwungen. Erst der vollständig abgeschlossene und fehlerfreie Status erlaubt den Übergang in den Normalbetrieb.

Die Abschlussprüfung umfasst:

• RAID-Level ist eindeutig als RAID 6 ausgewiesen.
• Alle Laufwerke stehen auf „Optimal“, „Online“ oder dem jeweiligen Sollstatus.
• Kein Rebuild und keine Migration laufen mehr.
• Controller- und Systemprotokolle enthalten keine neuen kritischen Fehler.
• Anwendungen erreichen die erwarteten Volumes und Datastores.
• Die gemessenen Latenzzeiten liegen nach Ende der Transformation wieder im betrieblich zulässigen Bereich.
• Das vor der Migration erstellte Backup bleibt erhalten, bis die Nachkontrolle abgeschlossen ist.

Typische Fehler bei der RAID-5-auf-RAID-6-Migration

Der häufigste Fehler ist der Start ohne verifiziertes Backup. Die Online-Fähigkeit eines Controllers wird dabei als Sicherheitsgarantie missverstanden. Sie ist lediglich eine Verfügbarkeitsfunktion.

Der zweite Fehler ist die Wahl eines nominell passenden, technisch aber ungeeigneten Laufwerks. Zu geringe Netto-Kapazität, abweichendes Sektorformat oder ungeeignete Laufwerksfirmware führen zu Ablehnung durch den Controller oder zu einem heterogenen Array mit schlechter vorhersehbarem Verhalten.

Der dritte Fehler liegt in der Ressourcenplanung. Re-Striping wird als kurze Verwaltungsaufgabe eingeplant, obwohl es die I/O-Reserven über mehrere Tage reduzieren kann. Bei Virtualisierungshosts und Datenbanken muss das Wartungsfenster nicht nur nach Kalender, sondern nach Schreiblast definiert werden.

Der vierte Fehler betrifft die Kapazitätserwartung. RAID 6 gewinnt gegenüber RAID 5 keine Speicherkapazität. Bei gleicher Laufwerkszahl sinkt sie um die Größe eines weiteren Datenträgers. Wird ein Laufwerk hinzugefügt und gleichzeitig von RAID 5 auf RAID 6 gewechselt, bleibt die nutzbare Größe oft unverändert.

Abschluss: Redundanz erhöhen, Risiko kontrollieren

Die Umstellung von RAID 5 auf RAID 6 ist sinnvoll, wenn die Laufwerkskapazitäten wachsen, die Wiederherstellungszeiten steigen und ein zweiter Ausfall während Rebuild oder Re-Striping nicht mehr akzeptabel ist. Sie ist keine Wartungsmaßnahme für zwischendurch.

Der sichere Ablauf folgt einer festen Reihenfolge: Arrayzustand prüfen, Backup verifizieren, kompatibles Laufwerk integrieren, Controller-Migration kontrolliert starten und den Abschluss auf RAID-, Betriebssystem- und Anwendungsebene validieren. Die zweite Parität reduziert das Risiko eines doppelten Laufwerksausfalls. Sie reduziert nicht die Anforderungen an Backup, Monitoring und saubere Betriebsführung.