Zerfallenes RAID-Array — Datenrettung ab 14.900 CZK, 24/7

Sofortige Antwort: Die Datenrettung aus einem RAID-Array erfordert die sofortige Einstellung aller eigenmächtigen Wiederherstellungsversuche. Sobald das Array ausfällt — insbesondere während eines kritischen Rebuilds — droht ein kaskadierender Ausfall weiterer Festplatten und endgültiger Datenverlust. Ein professionelles Labor liest Daten selbst aus Arrays aus, die mit herkömmlichen Mitteln unlesbar sind, und zwar durch Klonen auf Sektorebene und manuelle Rekonstruktion der Parität, ohne die Originalmedien zu belasten. Die Erfolgschancen sind hoch, wenn Sie den Schreibzugriff auf das Array gestoppt und keine wiederholten Rebuilds versucht haben. Der Eingriff dauert je nach Größe und Zustand der Festplatten in der Regel wenige Tage bis zu mehreren Wochen.

Auf unserem Tisch landete das Enterprise-NAS eines Projektierungsbüros aus Brünn — ein RAID-6-Array mit zwanzig Festplatten und einer Kapazität von 160 TB. Der Administrator tat genau das, was fast jeder im Rahmen des Wiederherstellungsplans getan hätte: Er tauschte die defekte Festplatte aus und startete den Rebuild. Das Problem ist, dass der Wiederherstellungsplan vom idealen Zustand der verbleibenden Festplatten ausgeht. Reale Platter tragen nach jahrelangem Betrieb versteckte defekte Sektoren in sich, die gerade während der extremen Belastung beim Berechnen der neuen Parität aufwachen. Das Ergebnis? Das RAID-Array fällt wie ein Kartenhaus zusammen und statt einer schnellen Reparatur stehen Sie vor einem Totalausfall der Unternehmensdaten.

Dieser Artikel dient als Wegweiser zum Verständnis der Ausfalllogik von RAID-Arrays, als Warnung vor fatalen Fehlern und als Beschreibung von Rettungsmethoden. Haben Sie ein konkretes Gerät wie Synology, QNAP oder einen Server mit Hardware-RAID-Controller, gelten zusätzlich die Spezifika des jeweiligen Herstellers — Details finden Sie auf der Seite RAID- und NAS-Wiederherstellung.

Schnelle Orientierung: RAID-Reparatur nach Symptomen

Das Wort „RAID-Reparatur” verleitet dazu, das Array so schnell wie möglich wieder zum Laufen bringen zu wollen. Wenn das Array jedoch zerfällt — Degraded meldet, offline geht oder beim Rebuild abstürzt — ist das Ziel, zuerst die Daten aus dem degradierten Array herauszuholen und erst dann neuen Storage zu beschaffen. Gehen Sie je nach Symptom wie folgt vor:

• RAID meldet Degraded: Starten Sie keinen neuen Rebuild ohne die Gewissheit, dass alle anderen Festplatten lesbar sind. Zuerst Backup prüfen, Schreibvorgänge stoppen und den Zustand konsultieren.
• Rebuild ist steckengeblieben oder abgestürzt: Array ausschalten. Ein wiederholter Rebuild verschlimmert typischerweise nur die defekten Sektoren auf den verbleibenden Festplatten.
• RAID 5 ist nach der zweiten Festplatte offline: Nicht versuchen, die ursprüngliche Konfiguration „in Gang zu bringen”. Bei RAID 5 kommt es auf die genaue Reihenfolge der Festplatten, die Stripe-Größe und die Parität an.
• RAID 6 ist bei einem dritten Problem ausgefallen: Festplatten in denselben Slots belassen, Positionen kennzeichnen und eine Offline-Rekonstruktion aus Klonen durchführen.
• RAID 0 nach Ausfall einer Festplatte: Daten sind nicht redundant, aber wenn sich die defekte Festplatte physisch lesen oder reparieren lässt, kann die Array-Struktur wieder zusammengesetzt werden.

Durch diesen Unterschied unterscheiden sich die Service-„RAID-Reparatur” und die laborseitige Datenrettung aus einem RAID-Array. Erstere versucht das Gerät wieder in Betrieb zu nehmen, letztere schützt die verbliebenen Inhalte auf den Festplatten.

1. Der Mythos namens „RAID = Backup”

Bevor wir in technische Details eintauchen, müssen wir den gefährlichsten Mythos der Branche ausräumen. Ein RAID-Array (Redundant Array of Independent Disks) wurde nie als Backup konzipiert, sondern als Werkzeug zur Erhöhung der Verfügbarkeit und zum Schutz vor dem Hardwareausfall einer oder mehrerer Festplatten.

Warum ist RAID kein Backup?

• Es schützt Sie nicht vor dem Löschen von Dateien durch menschliches Versagen.
• Es rettet Sie nicht vor Ransomware, die den Inhalt des logischen Volumes verschlüsselt.
• Es hilft nicht bei einem Controller-Ausfall, der sinnlose Metadaten auf das Array schreibt.
• Es versagt bei versehentlicher Reinitialisierung oder dem Erstellen eines neuen Arrays.

Wenn das gesamte Array aufgrund eines Firmwarefehlers, einer Überspannung in der Stromversorgung oder eines Mehrfachausfalls von Festplatten versagt, stehen Sie genauso ohne Daten da, als ob Sie diese auf einer einzigen externen Festplatte gehabt hätten. Das einzig echte Backup ist eine physisch getrennte Kopie der Daten — idealerweise extern oder auf einem anderen Medium. Sobald ein Array in den Status „offline” gerät, erfordert seine Wiederherstellung unabhängig von der verwendeten RAID-Stufe einen Facheingriff.

2. RAID-Level und ihre reale Ausfallresistenz

Verschiedene RAID-Level adressieren die Ausfallresistenz unterschiedlich. Bei der Datenrettung aus einem RAID ist es entscheidend zu verstehen, was im Array beim Ausfall geschieht.

RAID 0 — Striping ohne Ausfallschutz

Daten werden abwechselnd (Stripe) auf alle Festplatten geschrieben, mit dem Ziel maximaler Leistung.

• Ausfallschutz: Keinerlei. Der Ausfall einer einzigen Festplatte bedeutet den Verlust aller Daten, da die Dateien in Fragmente auf alle Festplatten zerstückelt sind.
• RAID-0-Rettung: ist komplex, aber nicht unmöglich. Wir müssen die defekte Festplatte physisch reparieren (z. B. durch Austausch der Leseköpfe in einer Reinraum-Laminarbox), sie klonen und dann die Datenblöcke aller Festplatten in der richtigen Reihenfolge offline zusammensetzen. Das Fehlen von Parität vereinfacht die Mathematik, aber der Mangel an Redundanz erhöht den Druck auf eine perfekte Hardware-Reparatur.

RAID 1 — Spiegelung

Das Schreiben erfolgt gleichzeitig auf beide Festplatten (oder deren Paare). Der Ausfall einer Festplatte schränkt die Funktionalität nicht ein. Ein Risiko entsteht beim Ausfall des Controllers oder wenn auch die verbleibende Festplatte im Spiegel defekt ist. Die Rettung ist oft nur eine Frage des Auslesens der Daten von mindestens einem funktionsfähigen Medium.

RAID 5 — Blockbasierte Parität

Dank der verteilten Parität toleriert das Array den Ausfall einer Festplatte.

• Degraded-Modus: Beim Ausfall einer Festplatte läuft das Array durch Nachberechnung der fehlenden Daten aus der Parität weiter. Dies bedeutet eine enorme Belastung für die verbleibenden Festplatten.
• Wiederherstellungsfehler: Wenn im Degraded-Zustand die Wiederherstellung fehlschlägt (ein defekter Sektor auf der zweiten Festplatte auftaucht), geht das gesamte Array offline. Das Problem besteht darin, herauszufinden, wo genau der Stripe endet und wie die Parität rotiert — hier setzt die analytische Rekonstruktion im Labor an.

RAID 6 — Doppelte Parität

Toleriert den gleichzeitigen Ausfall von zwei Festplatten. Es ist der Standard für große Enterprise-NAS.

• Praxis-Szenario: Auch wenn das Array den Verlust von zwei Festplatten überlebt, kommt die Katastrophe gewöhnlich beim Rebuild, wenn eine dritte Festplatte ausfällt (siehe unser realer Fall des 20-Festplatten-Arrays weiter unten). Aufgrund von zwei Paritätsebenen ist die Komplexität der Offline-Nachberechnung enorm.

RAID 10 — Gespiegelte Stripes

Kombiniert die Geschwindigkeit von RAID 0 und die Redundanz von RAID 1. Kann den Ausfall mehrerer Festplatten überleben, wenn sich diese nicht im selben Spiegelpaar befinden. Wenn doch, legt es den gesamten Stripe lahm.

RAID 50/60

Nur kurz — kombiniert Striping mit Parität. Die Komplexität der Rettung wird hier durch die verschachtelte Struktur multipliziert und erfordert eine fortgeschrittene Analyse.

3. Typische Ausfallszenarien, die wir täglich sehen

In unserem Brünner Labor begegnen uns Verhaltensmuster, die zur Katastrophe führen. Wenn Sie verstehen, was passiert ist, verstehen Sie auch, warum man ein RAID nicht einfach per Klick im BIOS „reparieren” kann.

(a) Ausfall der zweiten Festplatte während des Rebuilds

Der Admin tauscht die defekte Festplatte aus. Damit der Controller die Daten auf die neue Festplatte berechnen kann, muss er jeden Sektor aller übrigen Platter lesen. Alte Festplatten, die jahrelang fehlerfrei gelaufen sind, offenbaren plötzlich unter brutalem Druck Schwachstellen und beginnen fehlerhafte Sektoren zu produzieren. Das Array fällt komplett aus.

(b) Steckengebliebener Rebuild

Der Rebuild startet nicht oder bleibt nach dutzenden Stunden bei wenigen Prozent hängen und setzt nicht fort. Der Controller ist auf einen defekten Sektor gestoßen und weiß nicht, wie er ihn umgehen soll. Ihn mit Gewalt fortzusetzen, bedeutet das Risiko der Zerstörung der Lesekopfmechanik.

(c) Controller-Ausfall und proprietäres Layout

Ein defekter Controller zerschießt die Metadaten. Ein neuer Controller kann die Festplatten zwar möglicherweise erkennen, aber wenn er den ursprünglichen Stripe-Offset und die Paritätsrotation nicht kennt, bietet er nur eine „Foreign Configuration” und die Notwendigkeit der Initialisierung.

(d) Menschliches Versagen

Jemand zieht versehentlich die falsche Festplatte ab, vertauscht die Positionen in den Schächten und startet das Array. Oder führt beim Anblick einer Fehlermeldung eine Reinitialisierung durch.

(e) Gleichzeitiger Ausfall mehrerer Festplatten

Ein Ausfall des Netzteils oder der Backplane im NAS tötet auf einmal 3–4 Festplatten. Das Array gibt dann vor, dass die logische Einheit leer oder nicht zugänglich sei.

4. Was Sie nicht tun dürfen, wenn die Daten eine Rettung wert sind

Dies ist der wichtigste Teil des Artikels. Die meisten endgültig verlorenen Daten verschwanden erst durch panische Versuche einer RAID-Reparatur in Eigenregie.

• Wiederholen Sie niemals den Rebuild eines Degraded-Arrays. Wenn der Rebuild einmal fehlschlug, wird er erneut fehlschlagen — und die Belastung tötet bei jedem weiteren Versuch „gesunde” Festplatten. Genau dieses Szenario ließ das 20-Festplatten-Array im Einleitungsfall ausfallen.
• Vertauschen oder ersetzen Sie Festplatten nicht nach der Versuch-und-Irrtum-Methode. Bei einem Offline-Array müssen Sie die genaue Reihenfolge der Festplatten kennen. Zufälliges Vertauschen in den Schächten zerstört die Chance auf eine logische Rekonstruktion. Markieren Sie vor dem Ausbau stets die Positionen (Slot 1, Slot 2…).
• Installieren Sie keine „RAID Recovery”-Software auf dem Live-Array. Führen Sie niemals Wiederherstellungstools (wie R-Studio) aus, wenn das Betriebssystem gleichzeitig auf das Array schreibt. Jeder zusätzliche Schreibvorgang (Logs, temporäre Dateien) überschreibt die Reste Ihrer ursprünglichen Strukturen.
• Lassen Sie das Array nicht weiter im Degraded-Zustand laufen. Wenn eine Festplatte ausgefallen ist, schalten Sie den Server nicht „erst morgen” ab. Das ist Roulette darauf, ob die zweite Festplatte eine weitere Stunde überlebt. Stoppen Sie sofort den Schreibzugriff und konsultieren Sie uns.
• Verwenden Sie weder „Repair” noch „Factory Reset”. Führen Sie kein Firmware-Upgrade (DSM/QTS) durch und initialisieren Sie kein neues logisches Volume. Dadurch löschen Sie die Reste der Dateisystembeschreibung.

Wenn Sie bereits etwas von dem oben Genannten durchgeführt haben, hören Sie auf. Der Zustand ist dennoch oft lösbar, aber das Array muss sofort ausgeschaltet werden.

5. Wie ein professionelles Labor die Wiederherstellung eines RAID-Arrays löst

Unsere Arbeit besteht nicht aus Raten, sondern aus technischer Exaktheit. Bevor wir zur logischen Wiederherstellung übergehen, müssen wir die Daten physisch schützen.

Klonen auf Sektorebene

Wir arbeiten niemals mit Originalfestplatten. Jede Festplatte des Arrays — ob gesund, defekt oder klackernd — schließen wir an Hardware-Kloning-Geräte (DeepSpar Disk Imager) an. Diese lesen Daten von instabilen Oberflächen extrem sensitiv, überspringen defekte Sektoren und quälen die Festplatten nicht mit den Zeitlimits des Betriebssystems. Dort, wo ein normaler Computer einfriert, gewinnt der DeepSpar das Maximum an Daten.

Arbeiten in sauberer Umgebung

Wenn die Festplattenmechanik physisch ausgefallen ist (Klackern, durchgebrannte Elektronik), führen wir den Austausch der Leseköpfe in einer Laminarbox (Clean Room) durch. Ohne diese würde ein mikroskopisch kleines Staubkörnchen sofort die Platte zerstören.

Offline-Analyse und Entsperren proprietärer Layouts

Nach der Erstellung von Bit-Kopien (Klone) kommt der intellektuelle Kern der gesamten Wiederherstellung zum Zug:

1. Bestimmung der Festplattenreihenfolge: Physische Slots entsprechen oft nicht der Paritätsreihenfolge im Controller.
2. Berechnung der Stripe-Größe und des Offsets: Wir ermitteln, wo der erste Datenblock beginnt. Schon ein Versatz um einen einzigen Sektor bedeutet ein völlig wirres Byte-Chaos.
3. Paritätsrotation: Bei RAID 5/6 müssen wir aufdecken, in welchem Block die Parität liegt (left-symmetric, right-asymmetric etc.).
4. Virtuelle Rekonstruktion: Mit Hilfe von PC-3000-Equipment und eigenen Skripten setzen wir das Array aus den Bit-Kopien zusammen und bauen ein virtuelles Volume, das wir auf Staging-Storage (120 TB SATA RAID 10) überprüfen.

Für Synology, QNAP oder Server mit Hardware-Controller gelten darüber hinaus Spezifika — siehe Datenrettung vom Synology NAS, QNAP NAS und Datenrettung vom Server.

6. Realer Crash eines 20-Festplatten-RAID-6 — warum das auch Ihnen passiert ist

Die beste Illustration ist das erwähnte 20-Festplatten-RAID 6, das aus einem Brünner Projektierungsbüro zu uns kam.

Situation: Enterprise-NAS, 20 Festplatten, 160 TB, RAID 6 (doppelte Parität). Am Montag fiel Festplatte #7 aus. Der Admin bestellte eine Ersatzplatte und startete über Nacht den Rebuild. Am Dienstag fiel eine zweite Festplatte #12 aus — das Array geriet in den Zustand „degraded-critical”, in dem jedes weitere Problem das Ende bedeutet. Ein solches Array sollte man zwei Tage lang nicht anrühren, aber der Rebuild lief dennoch weiter. Nach 30 Stunden traf das Lesen auf einen defekten Sektor auf der scheinbar „gesunden” Festplatte #5. Der Controller wertete dies als Ausfall einer dritten Festplatte und warf das Array offline. Mit herkömmlichen Mitteln nicht wiederherstellbar.

Unsere Lösung: Wir übernahmen alle 20 Festplatten. Über DeepSpar klonten wir sie eine nach der anderen, wobei wir das schwierig langsame Lesen bei Festplatte #5 bewältigten. Die Offline-Analyse deckte das proprietäre Layout des Arrays auf (mdadm + LVM) — wir bestimmten die tatsächliche Reihenfolge der Festplatten, Stripe-Offset und die Paritätsrotation, und das virtuelle Array aus den geklonten Sektoren konnte erfolgreich zusammengesetzt werden. Es dauerte 11 Tage und der Kunde erhielt 100 % seiner Dateien zurück.

Hätte der Admin den Rebuild noch einmal versucht, wäre Festplatte #5 vollständig gestorben und die Datenrettung aus dem RAID hätte sich in eine dramatisch teurere physische Operation verwandelt.

7. Was es kostet und wie lange es dauert

Der Preis für die Datenrettung aus einem RAID-Array richtet sich stets nach der konkreten Situation. Bei ITHOPE gehen wir fair vor: Die kostenlose Diagnose deckt das Ausmaß der Beschädigung auf. Wir untersuchen, ob das Problem rein logisch (gelöschte Metadaten) ist oder ob physische Reparaturen und Klonen notwendig sind. Den Preis nennen wir vor Beginn der Arbeiten, niemals erst danach. Wenn die Daten nicht gerettet werden können (was bei zerfallenen Metadaten ohne Backups in vereinzelten Fällen vorkommt), zahlen Sie keinen Cent.

Die Dauer der Rettung hängt von der Kapazität und dem Zustand der Platter ab — am langsamsten ist die Arbeit mit physisch defekten Mechaniken. Generell gilt: Je weniger Amateur-Rebuild-Versuche das Array mitgemacht hat, desto schneller und günstiger ist die Rettung.

Häufig gestellte Fragen

Kann ich den Rebuild noch einmal versuchen?

Nein, wir raten dringend davon ab. Jeder Rebuild-Versuch bedeutet stundenlanges intensives Lesen aller verbleibenden Festplatten. Wenn die Festplatten am Sterben sind, gibt ihnen ein zweiter Rebuild den Rest — und verwandelt eine einfache logische Wiederherstellung in eine komplizierte physische Rettung.

Holt eine handelsübliche „RAID Recovery”-Software die Daten heraus?

Wenn Sie ein funktionierendes Array mit rein logischem Schaden haben, möglicherweise ja. Bei einem abgestürzten (Offline-)Array mit falschem Offset, beschädigter Festplatten-Firmware oder unlesbaren Sektoren versagt gewöhnliche Software und schreibt zudem oft temporäre Dateien auf die Festplatten, was die Situation verschlimmert.

Wie lange dauert die Datenrettung aus einem RAID im Labor?

Schnelle logische Rekonstruktionen (gesunde Festplatten, bekannte Parameter) lassen sich in wenigen Tagen bewältigen. Komplexe Fälle mit physischen Defekten, wie der 20-Festplatten-Crash oben, erfordern ein bis zwei Wochen. Eine genaue Einschätzung erhalten Sie nach der Diagnose.

Kann RAID 0 gerettet werden?

Ja. Auch wenn RAID 0 keine Parität hat und der Ausfall irgendeiner Festplatte theoretisch den Verlust aller Daten bedeutet, können wir die Daten dank physischer Reparatur der defekten Festplatte (z. B. Kopftausch) und deren exaktem Klonen extrahieren. Die Chance sinkt jedoch, wenn auf die gesunden Festplatten geschrieben wurde, während eine tot war.

Wie viele Festplatten müssen ausfallen, damit es ein Problem wird?

Bei RAID 5 eine, bei RAID 6 zwei. In der Praxis reicht jedoch oft die Kombination aus einer toten Festplatte und ein paar defekten Sektoren auf einer zweiten für den Crash des Arrays — genau deshalb darf ein Degraded-Array nicht weiter belastet werden.

Was jetzt zu tun ist

1. Stoppen Sie den Schreibzugriff und schalten Sie das Array aus. Keine weiteren Rebuilds, kein „noch ein Versuch”. Jede Betriebsminute eines Degraded-Arrays reduziert die Chancen.
2. Ändern Sie die Reihenfolge der Festplatten nicht. Wenn Sie sie ausbauen müssen, kennzeichnen Sie zuerst die Positionen mit einem Marker oder Aufkleber (Slot 1, Slot 2…).
3. Führen Sie keine Recovery-Software auf dem Live-Array aus und initialisieren Sie weder ein neues Volume noch eine „Foreign Config”.
4. Kontaktieren Sie das Labor. Rufen Sie NONSTOP an unter +420 775 556 063 oder nutzen Sie die unverbindliche Beratung. Wir vereinbaren Abholung oder sicheren Transport nach Brünn.
5. Rechnen Sie mit einer kostenlosen Diagnose. Ausmaß des Schadens und Preis für die Wiederherstellung nennen wir im Voraus — Sie zahlen nur für das Ergebnis.

Zusammenfassung in Stichpunkten

• RAID ist kein Backup — es schützt nicht vor Löschung, Ransomware, Controller-Ausfall oder Mehrfachausfällen von Festplatten.
• Die häufigste Ursache für Totalverlust ist der wiederholte Rebuild eines Degraded-Arrays, der den alten „gesunden” Festplatten den Rest gibt (Kaskadenausfall).
• Jeder RAID-Level fällt anders aus — RAID 0 hat keine Toleranz, RAID 5 einen, RAID 6 zwei Festplatten; die Rettung stützt sich stets auf die Reihenfolge der Festplatten, den Stripe-Offset und die Paritätsrotation.
• Rettung = Sektor-level-Klon jeder Festplatte + Offline-Rekonstruktion, niemals Arbeit mit den Originalen.
• Vor der Übergabe des Arrays Rebuild, die Reihenfolge der Festplatten und ein neues Volume nicht antasten — je weniger Amateureingriffe, desto höher die Chancen.
• Bei konkreten Geräten siehe Synology, QNAP und Server mit HW-Controller.

Haben Sie ein Degraded-RAID-Array oder ein Array, das offline gegangen ist? Versuchen Sie keinen Rebuild — jeder weitere Versuch verringert die Chancen. Unverbindliche Beratung · Kostenlose Diagnose · Kontakt · +420 775 556 063 (NONSTOP)

Siehe auch: Datenrettung vom Synology NAS · QNAP NAS · Datenrettung vom Server · RAID- und NAS-Wiederherstellung (Dienstleistung) · Case Study: 20-Festplatten RAID 6 · Defekte Sektoren HDD

Über den Autor

Ing. Miroslav Jaroš ist Inhaber und Senior-Techniker von ITHOPE s.r.o. in Brünn. Er widmet sich seit 2008 der Datenrettung — in 18 Jahren durchliefen über 2.500 Aufträge das Labor, von einzelnen Festplatten bis hin zu Enterprise-RAID-Arrays und NAS. Der Artikel wurde einem fachlichen Fact-Check (Tomáš Kopřiva) anhand der realen Praxis des ITHOPE-Labors unterzogen. Der beschriebene Fall des 20-Festplatten-RAID-6 basiert auf einem realen, anonymisierten Auftrag.