Datenrettung vom Server – RAID-Wiederherstellung, HP ProLiant, Dell PowerEdge

Sofort-Antwort: Wenn Ihr Server HP ProLiant, Dell PowerEdge oder ein anderes Gerät mit Hardware-RAID-Controller in den Status „Degraded” oder „Offline” gefallen ist, schalten Sie ihn sofort aus. Versuchen Sie nicht blind eine „Foreign Config” nach einem Controller-Tausch zu importieren, starten Sie keinen Rebuild eines degradierten Arrays und initialisieren Sie vor allem kein neues virtuelles Laufwerk. Jeder Schreibversuch oder die Wiederherstellung der Konfiguration verringert die Chance auf Datenrettung drastisch, da die proprietären Metadaten von Controllern wie HP Smart Array oder Dell PERC in Millisekunden überschrieben werden. Die Chance auf Rettung ist bei sofortiger Abschaltung des Servers und korrektem Vorgehen im Labor hoch, selbst wenn das Array „Failed” meldet oder der Controller selbst ausfällt. Die Diagnose ist bei uns immer kostenlos und wir nennen Ihnen den Preis im Voraus, Sie gehen also kein Risiko ein.

Bei einem Server-RAID ist es tückisch, dass die Administrationsoberfläche oft einfache Optionen anbietet: Konfiguration importieren, Rebuild starten, neues virtuelles Laufwerk erstellen. Nur ist in dem Moment, in dem das Array bereits Degraded, Offline oder Foreign Config meldet, nicht sicher, ob der Controller die ursprüngliche Struktur noch korrekt liest. Was wie ein routinemäßiger Service aussieht, kann sich innerhalb einer Bestätigung in überschriebene Metadaten und einen verlorenen VMFS-Datastore verwandeln.

Schnelle Orientierung anhand der Server-Meldung

Wenn der Server Foreign Config, Virtual Drive Offline oder einen nicht verfügbaren VMware-Datastore meldet, geht es nicht nur um die Festplatten. Gleichzeitig müssen der Controller, die Steckplatzreihenfolge, die RAID-Metadaten und das Dateisystem der Virtualisierung betrachtet werden.

• Foreign Configuration: Nicht ohne Analyse importieren oder löschen. Zuerst die Festplatten kennzeichnen und herausfinden, warum die Konfiguration als fremd angesehen wird.
• Virtual Drive Offline / Failed: Server ausschalten. Wiederholte Reboots können eine Initialisierung oder weitere Schreibvorgänge in die Metadaten auslösen.
• Unconfigured Good nach Controller-Tausch: Heißt nicht, dass die Festplatten leer sind. Es bedeutet, dass der neue Controller die ursprüngliche Konfiguration nicht sieht.
• Rebuild failed bei RAID 5/6: Ein weiterer Versuch belastet in der Regel dieselben Platten erneut. Ohne Sektor-Klone ist das ein Hazardspiel.
• VMware VMFS Datastore inaccessible: Nicht auf Format, Resignature oder das Erstellen eines neuen Datastore klicken. Dadurch geht die Struktur der virtuellen Maschinen verloren.

Das sichere Vorgehen ist bei HP Smart Array, Dell PERC und LSI MegaRAID gleich: physische Reihenfolge der Festplatten bewahren, Array von Schreibzugriffen trennen, jede Festplatte einzeln klonen und erst anhand der Kopien prüfen, wie das Array zusammengesetzt war.

1. Warum ein Hardware-RAID im Server eine andere Liga ist

Während bei günstigen NAS-Systemen oder Software-Arrays mit einem relativ standardisierten Header gearbeitet wird, verwenden Enterprise-Server dedizierte RAID-Controller mit eigener Logik und geschlossenen Metadaten. Das ist ein grundlegender Unterschied, der die Datenrettung zu einer detektivischen Arbeit auf Bit-Ebene macht.

Proprietäre Metadaten und die Falle namens „Foreign Config”

Controller wie HP Smart Array (Serie Pxxx), Dell PERC (H710, H730, H740), Broadcom/LSI MegaRAID oder Adaptec/Microsemi erstellen auf den Festplatten eigene Konfigurationssektoren, die Informationen über das RAID-Level, die Stripe-Größe, die Reihenfolge der Festplatten und deren Position innerhalb des Arrays enthalten. Diese Metadaten sind nicht zwischen den Herstellern übertragbar, oft nicht einmal zwischen verschiedenen Controller-Generationen derselben Firma. Wenn der Controller nach dem Start nicht die erwartete Konfiguration sieht, meldet er „Foreign Configuration”. Die anschließende Auswahl von „Import Foreign” oder „Clear” ohne tiefgehende Kenntnis der Situation schreibt auf die Festplatten und kann die letzte bekannte korrekte Struktur des Arrays überschreiben.

Virtualisierung über dem RAID: eine unsichtbare weitere Ebene

Enterprise-Server speichern Dateien in der Regel nicht direkt. Auf dem Hardware-RAID-Volume läuft ein Hypervisor – meistens VMware ESXi mit VMFS-Datastores oder Microsoft Hyper-V mit dem VHDX-Format. Wenn das Array ausfällt, verlieren Sie nicht nur ein Dateisystem, sondern einen gesamten Container mit virtuellen Servern. Die Labor-Rekonstruktion darf daher nicht beim Zusammensetzen der Blöcke enden, sondern muss tiefer gehen: die VMFS-Struktur finden und reparieren, ihre Tabellen prüfen und die virtuellen Festplatten extrahieren. Das ist der entscheidende Kontext, der den Server von einer einfachen externen Box unterscheidet.

2. Typische Ausfallszenarien eines Server-Arrays

Ein Hardware-RAID im Server ist robust, aber seine Ausfälle haben oft einen spezifischen Verlauf, der in einem fatalen Offline-Status endet.

Degradiertes RAID 5 und kaskadierender Ausfall

Das häufigste Szenario. RAID 5 toleriert den Verlust einer einzigen Festplatte. Der Administrator bemerkt eine blinkende orange LED, bestellt eine neue Platte und startet den Austausch. Das Problem ist, dass alle verbleibenden Platten im Array in der Regel das gleiche Alter haben, aus derselben Produktionscharge stammen und dieselbe Anzahl an Betriebsstunden aufweisen. Ein vollständiger Rebuild, der Dutzende von Stunden dauert, stellt eine extreme Belastung dar. Wenn auf einer anderen Platte auch nur ein einziger defekter Sektor auftritt, an dem der Rebuild hängenbleibt, wechselt das Array von Degraded direkt auf Failed. Bei RAID 6 mit zwei Paritätsplatten ist die Situation besser, aber auch dort gilt Null-Toleranz während des Rebuilds – siehe den realen Fall mit 20 Platten unten.

Controller-Ausfall und „Foreign Config”

Ein Hardware-Controller ist nicht unsterblich. Er kann aufgrund von Überspannung, einem Kurzschluss auf der Backplane oder einfach nach Jahren des Betriebs ausfallen. Wenn Sie die Festplatten entnehmen und in einen anderen Server (oder einen anderen Steckplatz) stecken, meldet der Controller eine fremde Konfiguration. Ein blinder Import ohne Kenntnis des ursprünglichen Stripe-Offsets, der Ausrichtung und der Firmware-Version birgt das Risiko, dass der Controller neue Metadaten falsch schreibt – besonders wenn sich die Geometrie der Datenverteilung zwischen den Controller-Generationen geändert hat. Ein einfaches Umstecken der Festplatten von einem Server in einen anderen kann somit zum Auslöschen der Array-Struktur führen.

Beschädigter VMFS-Datastore und Expander-Ausfall

Besonders tückisch sind Stromausfälle oder momentane Störungen des SAS-Expanders (Backplane). Die Backplane kann für Millisekunden mehrere Festplatten gleichzeitig abtrennen. Der Hardware-Controller stuft sie sofort als tot ein und markiert sie als „Failed”. Dabei liegt gar kein physischer Defekt vor, aber das Array ist zerstört. Ebenso kann ein ungeschickter Eingriff in ESXi (z. B. das Erstellen einer neuen Partition dort, wo sich ein Datastore befand) VMFS in ein unlesbares Metadaten-Chaos verwandeln.

3. Was Sie mit einem Server-RAID-Controller NICHT tun dürfen

Dies ist absolut entscheidend. Bitte geben Sie dies an Ihre IT-Kollegen weiter – es geht um Schritte, die die letzte Chance auf Rettung zunichtemachen.

• Importieren Sie „Foreign Configuration” nicht blind. Solange Sie nicht wissen, warum die Konfiguration als fremd betrachtet wird, ist der Import eine tickende Zeitbombe. Besonders wenn der Controller getauscht oder Platten umgesteckt wurden.
• Initialisieren Sie kein neues virtuelles Laufwerk. Wenn der Server auf das alte VD nicht reagiert, wählen Sie niemals „New Volume / New Logical Drive” auf denselben physischen Festplatten. Dieser Schritt überschreibt den Array-Header und zerstört mit Sicherheit die Partitionstabelle.
• Starten Sie keinen Rebuild, wenn Sie zwei oder mehr defekte Festplatten sehen. Sobald Sie sich bei RAID 5 in einem Zustand mit mehreren Problemen befinden, geht es nicht um Wartung, sondern um Rettung. Jede Sekunde Lese-Belastung beim Rebuild tötet die verbleibenden Platten (siehe kaskadierender Ausfall).
• Stecken Sie Festplatten nicht durch Versuch und Irrtum zwischen den Positionen um. Der Hardware-Controller identifiziert die Steckplätze. Wenn Sie diese vor dem Entfernen nicht kennzeichnen, verlieren wir Zeit und erhöhen das Risiko.
• Führen Sie kein Firmware-Upgrade des Controllers oder Hypervisors auf einem defekten Array durch. Der Versuch, ein nicht funktionierendes Array durch Einspielen einer neueren Version der Smart Array / PERC Firmware zu reparieren, kann die Art und Weise ändern, wie Metadaten gelesen werden.
• Erstellen Sie unter ESXi keinen neuen Datastore. Wenn vCenter „Inaccessible” meldet, klicken Sie nicht auf „Format” oder „Resignature”. Geben Sie es zu uns.

4. Wie das Labor die Rettung eines Server-Arrays angeht

Das Geheimnis liegt darin, sich nicht mehr auf die Logik des Controllers zu verlassen, sondern mit den Rohdaten zu arbeiten.

1. Klonen auf Sektorebene. Jede einzelne Festplatte (SAS wie auch SATA) wird auf spezialisierte Klon-Stationen (PC-3000, DeepSpar Disk Imager) übertragen. Ziel ist es, Sektor für Sektor alle lesbaren Daten auszulesen, bevor die Festplatten zerfallen. Defekte Sektoren behandeln wir hardwarebasiert, nicht durch Software-Timeouts des Controllers. Festplatten mit beschädigten Köpfen kommen in die Reinraum-Workstation.
2. Offline-Analyse des proprietären Layouts. Aus den Klonen extrahieren wir die binären Metadaten. Hier unterscheidet sich HP Smart Array grundlegend von Dell PERC. Wir suchen nach Parametern: Stripe-Größe, Paritäts-Rotation (left/right, synchron/asynchron) und vor allem die tatsächliche Reihenfolge der Festplatten und der Offset des Datenbeginns (einige Controller lassen vor den Daten einen reservierten Bereich). Wir schätzen nichts – alles wird anhand der Struktur des Dateisystems verifiziert.
3. Virtuelle Rekonstruktion des Arrays. Auf unserem Berechnungsspeicher (Staging 120 TB SATA RAID 10) setzen wir die Klone zu einem virtuellen Blockgerät zusammen. Wir verwenden nicht den ursprünglichen Server-Controller. Wenn auf dem Array VMware läuft, folgt die entscheidende Phase: die Rekonstruktion der VMFS-Tabellen – Superblock, Allocation Pointer, Verknüpfung von VMDK und VHDX.
4. Extraktion auf das Staging-System. Die resultierenden Daten (oft Dutzende TB) werden auf ein verifiziertes Dateisystem extrahiert. Wenn der Kunde nur eine bestimmte virtuelle Maschine benötigt, extrahieren wir nur deren VMDK-Datei.

5. Realer Fall: Enterprise-Rekonstruktion eines RAID 6 mit 20 Festplatten

Genau im Sinne der oben beschriebenen Tücken verlief die Rettung für ein Projektierungsbüro in Brünn. Es handelte sich um ein 160-TB-Array mit 20 Festplatten in RAID 6, aber die Situation ist perfekt auf jeden großen Server mit Hardware-RAID übertragbar.

Am Montag fiel Platte #7 aus. Der Administrator bestellte eine Ersatzplatte und startete den anspruchsvollen Rebuild. Am Dienstag fiel Platte #12 aus – das Array erreichte einen kritischen Zustand, lief aber noch (zwei Paritäten hätten das bewältigen sollen). Doch nach 30 Stunden blieb der Rebuild an einem defekten Sektor der „gesunden” Platte #5 hängen. Der fehlerhafte Sektor trat gerade aufgrund der brutalen Belastung während des Rebuilds auf, und schlagartig hatte das Array drei Problemstellen – die Paritätsrekonstruktion schlug fehl, das Array ging offline. Die Lösung erforderte das Klonen aller 20 Platten, das Offline-Auffinden des proprietären Stripe-Offsets und der Reihenfolge sowie die Extraktion der Daten auf unser Staging-System. Es dauerte 11 Tage, das Ergebnis waren 100 % aller Daten. Details: 20-Disk-RAID 6.

Häufig gestellte Fragen

Der Controller ist tot, verliere ich das ganze Array?

Nein. Wenn nur der Controller tot ist (und die Festplatten mechanisch in Ordnung sind), bleiben die Daten auf den Scheiben erhalten. Wir lösen das, indem wir die Festplatten klonen und das Array anhand der proprietären Metadaten, die auf den Platten verblieben sind, softwareseitig zusammensetzen. Wir benötigen nicht zwingend einen identischen Ersatz-Controller, was entscheidend ist, da ältere HP- oder Dell-Modelle nicht mehr beschaffbar sind. Generell gilt: Je früher Sie es abschalten, desto besser. Mehr zu den Regeln für RAID siehe RAID- und NAS-Rettung.

Nach dem Controller-Tausch meldet der Server „Foreign Config”. Was nun?

Ausschalten, Festplattenpositionen kennzeichnen und absolut nichts im BIOS des Controllers unternehmen. Wenn Sie das Array zu uns schicken, lesen wir die alte Konfiguration offline aus den Plattenklonen ein und verifizieren sie anhand der Dateisystemstruktur. Die Option „Import Foreign” ist ein Hazardspiel, da Sie nicht wissen, ob der neue Controller dieselbe Ausrichtung und Leselogik wie der alte hat.

Kann ich Festplatten aus einem HP ProLiant in einen anderen Server einbauen und das Array importieren?

Wir raten dringend davon ab. Im Labor tun wir das zwar, aber ausschließlich zum Lesen auf Hardware, die nicht auf die Festplatten schreibt. Ein anderer Server kann beim Booten mit der Synchronisation beginnen oder die Platten direkt in den Status „Unconfigured Good” versetzen und damit die RAID-Metadaten löschen.

Darauf läuft VMware ESXi – kann nur eine einzige virtuelle Maschine gerettet werden?

Ja. Sobald wir den gesamten VMFS-Datastore virtuell rekonstruiert haben, können wir selektiv nur die gewählten virtuellen Festplatten (VMDK) extrahieren. Es ist nicht nötig, den gesamten Datastore zu retten, was besonders bei begrenzter Kapazität auf Ihrer Seite nützlich ist.

RAID 5 auf einem Dell und eine Platte ist ausgefallen – muss ich sofort die Rettung veranlassen?

Wenn das Array nur in den Status Degraded geraten ist, ist es Zeit für ein Backup, nicht für Panik – aber unter der Bedingung, dass kein Rebuild gestartet und sofort mit dem Kopieren der Daten begonnen wird. Wenn es Ihr Primärspeicher ist und Sie kein Backup haben, ist das Abschalten des Servers und die Übergabe der Platten an uns sicherer, als darauf zu hoffen, dass die Jahre alten Nachbarplatten einen stundenlangen Rebuild durchhalten.

Wie lange dauert die Rettung eines Server-Arrays?

Die genaue Zeit wird von der Kapazität und dem Umfang der Beschädigung beeinflusst. Standard-Arrays mit 4–8 Platten bearbeiten wir innerhalb weniger Arbeitstage. Massive Rekonstruktionen von Dutzenden Terabytes (siehe 20-Disk-RAID 6) können auch zwei bis drei Wochen in Anspruch nehmen. Eine genaue Schätzung erhalten Sie nach der Diagnose.

Was jetzt zu tun ist

1. Schalten Sie den Server sofort aus. Wenn er nicht startet, trennen Sie die Stromversorgung. Führen Sie keine weiteren Reboots durch und versuchen Sie nicht, mit integrierten Tools zu reparieren.
2. Kennzeichnen Sie die Festplatten physisch. Notieren Sie vor der Handhabung deren Positionen (Slot 1, Slot 2…). Bei HP- und Dell-Servern mit Hot-Swap-Einschüben ist die Reihenfolge entscheidend. Fotografieren Sie auch die hinteren Anschlüsse, falls zugänglich.
3. Lassen Sie keinen gewöhnlichen IT-Techniker ohne Erfahrung mit Laborrettung daran. Ein Standard-IT-Techniker hat in der Regel keine Anweisung, nicht in das Array einzugreifen und die Konfiguration nicht blind zu importieren.
4. Kontaktieren Sie unser Labor. Rufen Sie uns NONSTOP unter +420 775 556 063 an oder nutzen Sie unsere unverbindliche Beratung. Wir vereinbaren eine Abholung oder den sicheren Transport der Festplatten nach Brünn.
5. Rechnen Sie mit einer kostenlosen Diagnose. Im Labor beurteilen wir die Festplatten, prüfen, ob auf sie geschrieben wurde, und nennen Ihnen den genauen Preis für die komplette Wiederherstellung. Sie zahlen erst nach erfolgreich abgeschlossener Arbeit, nach Ansicht der Liste der geretteten Dateien.

Zusammenfassung in Stichpunkten

• Hardware-Controller (HP, Dell, LSI) verwenden proprietäre Metadaten; ein Austausch des Controllers „Stück für Stück” scheitert oft und endet mit dem Verlust der Konfiguration.
• Ein kaskadierender Ausfall während des Rebuilds ist bei älteren Festplatten in RAID 5/6 die Hauptursache für ein fatales Versagen – das Array darf nicht weiter belastet werden.
• Bei der Meldung „Foreign Config” ist jeder Import ohne Offline-Analyse ein Risiko, die Array-Struktur zu überschreiben.
• Virtualisierung fügt eine weitere Ebene hinzu: Nach dem Zusammensetzen der Blöcke muss das Labor die VMFS/NTFS-Strukturen reparieren und die virtuellen Festplatten (VMDK/VHDX) herauslösen.
• Netgear ReadyNAS (X-RAID) sowie großvolumige Enterprise-Boxen erfordern denselben Ansatz – Plattenklon, Entschlüsselung der Parität und Offline-Rekonstruktion.
• Das Labor ITHOPE arbeitet mit SAS- und SATA-Klon-Stationen, in sauberer Umgebung und mit einem Staging von 120 TB – und vor allem offline, ohne einen einzigen Schreibzugriff auf die Originalplatten.

Ist Ihr Server in den Status Degraded oder Offline gefallen? Starten Sie keinen Rebuild und importieren Sie keine fremde Konfiguration – jeder Versuch verringert die Chancen. Unverbindliche Beratung · Diagnose kostenlos · Kontakt · +420 775 556 063 (NONSTOP)

Siehe auch: Datenrettung aus einem RAID-Array · Synology NAS · QNAP NAS · RAID- und NAS-Rettung (Dienstleistung) · Case Study: 20-Disk-RAID 6

Über den Autor

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