Die Datenrettung in der Datenrettung in der Datenrettung in der Datenrettung…

Virtualisierte Systeme sind mittlerweile in Server-Landschaften nicht mehr wegzudenken. Jedoch steigt mit diesen die Komplexität per physikalischen Server. Gerade haben unsere Techniker im Labor Hamburg einen spannenden Datenrettungsfall erfolgreich abgeschlossen: Einem sehr großem deutschen Provider ist ein Enterprise Storage System verstorben. Das Systemhaus angerufen, eine NetApp bestellt, leider etwa vier Wochen Lieferzeit. Also nimmt man ein gerade im Lager verfügbares Low-Cost-Raid-System (mit 8x 2 TB Festplatten im Raid6-Verbund mit einer Spare-Platte, also etwa 10 TB netto Kapazität) und spielt das vorhandene Backup (wie feig, die haben ein Backup *g*) zurück.

Jetzt kommt der für uns Datenretter schöne Teil der Geschichte: einige Tage vor dem Liefertermin der NetApp stirbt auch dieses Raid-System, mehrere Platten fallen aus. Jedoch *kein* Backup mehr vorhanden (die gesamte Infrastruktur war für das Temporär-Raid nicht ausgelegt). Panik bricht aus, Platten werden wild getauscht, Rebuilds des Raid-Verbundes gestartet. Die Raid-Konfiguration geht verloren, es wird versehentlich ein Raid5 online gezwungen, teilweise Rebuildet. Irgendwann geben die Techniker auf, nach Anrufen bei einigen Datenrettungsanbietern erreicht er Attingo Datenrettung in Hamburg, und ist ganz überrascht, dass sein gegenüber (Anm. d. Redaktion: Attingo *g*) den beschriebenen Ablauf des Datenverlustes auch versteht, bis dato hatte keiner der Anbieter nur ansatzweise Verstanden wovon er spricht.

Nun, die Sache war ja zugegeben noch viel komplexer als bis dato beschrieben: Das RAID-System ist ein NAS, also ein Network Attached Storage. Das bedeutet, dass das RAID-System ein eigenes Betriebssystem verwendet, eine eigene Freigabe-Software und ein Web-Interface zur Konfiguration von RAID, LUNs (Partitions) sowie Freigaben und Berechtigungen besitzt (meistens zumindestens). In der Regel wird Linux oder BSD (aufgrund seiner Lizenz) eingesetzt, in diesem Fall war es jedoch der Windows 2008 Enterprise Storage Server (ja, so etwas gibt es auch auf NAS Boxen…). Der Kunde erklärte nun, er habe auf diesem RAID zwischen 10 und 15 Virtuelle Maschinen (.VMDK). Die wichtigste von diesen virtuellen Maschinen beinhaltet eine VMWARE ESX Installation (pervers, nicht wahr, auf einen Windows Server legt man eine VMDK mit ESX ab). In dieser VMWARE ESX VMDK Datei (dieses enthält das VMFS Dateisystem) befinden sich weitere VMDK Dateien, eine davon eine Linux Installation mit LVM, EXT4 und einer PostgresSQL Installation. Diese benötigen sie ganz dringend, der Rest hat auch ein oder zwei Tage Zeit.

Anfangs war die schwierigste Aufgabe ein Diagramm des Storage-Systems zu konstruieren. Nur wenn die Techniker genau wissen wie die LUNs, Dateisystem, Virtuelle Maschinen, LVMs, etc. abgelegt sind, ist eine schnelle gezielte Datenrettung möglich. In den meisten Fällen hat der Techniker des Kunden jedoch oft gar die exakte Kenntnis darüber.

Im Labor von Attingo wird vorerst immer mit der physikalischen Datenrettung begonnen. Sprich Datenträger ab in den Reinraum, physikalischen Schaden analysieren, beheben und 1:1 Rohdatenkopien anlegen.

Danach stellen sich folgende Fragen: In welcher Reihenfolge hat der Raid-Controller die Festplatten tatsächlich verwendet (diese hat selten etwas mit der Beschriftung auf den Slots zu tun), wie sind die anderen Parameter des Raid-Systems (RAID-Algorithmus, Block-Size, etc.). Da jedoch bereits bereiche durch Rebuilds, Änderung des RAID-Levels mit Online-Force, etc. überschrieben wurden, benötigt man auch den Anfang des „Ursprünglichen“ RAID6-Verbundes (also bis zu welchem Sektor wurde überschrieben). Ab dieser Stelle – vorausgesetzt man hat alle Rohdaten – kann man davon ausgehen, dass die Daten keine Fehler haben. An den Stellen davor sind Rohdaten unwiederbringlich verloren. Jedoch finden die Techniker von Attingo heraus, dass die Spare-Festplatte nach dem Ausfall der ersten Festplatte angesprungen ist und der Controller ein Rebuild gestartet hat. Dieses ist jedoch nach dem Auftreten eines Hardwaredefektes einer weiteren Festplatte abgebrochen. Der Kunde hatte Glück im Unglück – das Rebuild war bereits über die Stelle hinaus gelaufen, bis zu der der RAID5-Rebuild durchgeführt wurde. Da wir auch die Rohdaten der defekten Festplatten auslesen konnten, hatten die Techniker genug Daten zur Verfügung, um aus Einzelteilen (je nach Sektornummer andere Festplatten) auch den Anfang des RAID6-Verbundes rekonstruieren zu können.

Danach können die Attingo mit einer inhouse entwickelten Software-/Hardwarelösung den RAID-Verbund virtuell simulieren.

Das gesamte RAID konnte rekonstruiert werden. Dies war auch sehr wichtig, weil am Anfang des Laufwerks die MFT (Master File Table) von NTFS liegt. VMDKs die im Betrieb wachsen können liegen fragmentiert auf dem Laufwerk, nur mit Hilfe der MFT (Runlist) können die einzelnen Fragmente wieder zusammen gesetzt werden.

Sobald unsere Techniker Zugriff auf die VMDKs hatten war es nur noch Routine: Die VMDK mit VMFS identifizieren, mounten, die benötigte VMDK innerhalb identifizieren, extrahieren, dort dann das LVM extrahieren, die benötigte Partition finden, EXT4 mounten, die PostgreSQL Datenbank finden, kopieren, testen, SQL Dump erstellen und den Kunden ausliefern.

Schöne neue Virtuallisierungswelt.

[Gesamt:0    Durchschnitt: 0/5]

Schreibe einen Kommentar