Go to Top

Versehentliche LUN-Löschung führt zu 45 GB an fehlenden Produktionsserverdaten

Wie wir schon oft gesagt haben, ist einer der Hauptgründe für Datenverlust ein Benutzungsfehler durch den Anwender. Anfang dieses Jahres hat ein Datenwiederherstellungsfall, den unsere Experten schließlich erfolgreich abgeschlossen haben, erneut deutlich gezeigt, dass dies immer noch so ist:

Dabei hatte ein Managed Service Provider mit Sitz in Korea versucht, Konfigurationsänderungen am NetApp-System seines Kunden vorzunehmen, wobei ein Techniker dann fälschlicherweise einen „dd“ -Befehl für einige LUNs startete und dabei die Daten löschte, die integraler Teil des Sybase-Produktionsservers des Endbenutzers waren.

Normalerweise ist der ‚dd‘-Befehl das ursprüngliche Kopier-Dienstprogramm für Datenblöcke unter Unix / Linux-Betriebssystemen, wo es zum Kopieren einzelner Datenblöcke, Dateien oder sogar zum Duplizieren ganzer Plattenlaufwerke verwendet wird. Kurz gesagt, dieser Befehl kann verwendet werden, um Dateien zu kopieren, die auf einem Filer gespeichert sind. Aber wenn er nicht korrekt ausgeführt wird, kann er zu schweren Schaden führen. Wie eben in diesem Fall.

Der Managed-Service-Provider kontaktierte den NetApp-Support, um die LUNs wiederherzustellen, und da dies keine leichte Aufgabe war, fragten sie Ontrack nach ihrer speziellen Datenwiederherstellungsexpertise.

Der Provider verfügte dabei über ein NetApp FAS8060-System mit 161 x 900 GB großen SAS-HDDs, die in zwei separaten Aggregate (68 Laufwerke + 93 Laufwerke) angeordnet waren. Der Endkunde präsentierte 3 x 468 GB FC-LUNs von jedem Aggregat dem Sybase-Server. Die insgesamt 6 LUNs wurden dabei in einem einzigen Disk Pool zusammengefasst, wobei drei logische Volumes aus dem Pool herausgeschnitten wurden. Ein falscher ‚dd‘-Befehl hatte Nullen auf ungefähr 45 GB eines der logischen Volumes geschrieben, und das Volume war dann für den Sybase-Server nicht mehr sichtbar.

Während der ersten Beratung wies unser Ingenieur den Provider an, die Aggregate offline zu schalten, um weitere Überschreibungsschäden zu vermeiden. Die Aggregate wurden schließlich 12 Stunden nach dem Auftreten des ursprünglichen Datenverlustes offline geschaltet. Der Kunde präsentierte  alle 161 HDDs beider Aggregate mittels einer einzelnen Windows-Maschine und verband diese mit einem Ontrack RDR (Remote Data Recovery) Fernwartungs-Server. Eine erste Überprüfung durch Ontrack zeigte, dass beide Aggregate „aggr0“ genannt wurden, wodurch die Möglichkeit unseres Ingenieurs, das Aggregat automatisch wiederaufzubauen, zunichtegemacht wurde. Deshalb wurden die Laufwerke in Aggregatgruppen sortiert und die Aggregate wurden anschließend manuell neu erstellt. Unsere Ingenieure waren dann in der Lage, die Aggregate so zeitnah zum Ausfall wie möglich wiederaufzubauen, allerdings bevor der „dd“ -Schaden auftrat, wobei die separaten Aggregate einen Zeitunterschied von zwei Minuten zwischen ihnen aufwiesen.

Nachdem die beiden Aggregate schließlich neu erstellt wurden, konnten die enthaltenen sechs LUNs als flache Dateien in externe Speicher extrahiert und an NetApp Support übergeben werden.

Nachdem diese sechs LUNs zur Verfügung standen, konnten die NetApp Support-Mitarbeiter dann helfen, diese LUNs endlich wieder dem Sybase Server zu präsentieren bzw. zuzuweisen. Die wiederhergestellten logischen Volumes bestanden dann die Integritätsprüfungen auf dem Sybase-Server und der Endkunde bestätigte schließlich, dass alles ordnungsgemäß funktionierte.

Am Ende konnte so der Kundendatenbankserver innerhalb weniger Tage nach dem Ausfall ohne einen Datenverlust wieder online gebracht werden.

Weitere Informationen zu den Datenwiederherstellungsfähigkeiten von Ontrack finden Sie unter https://www.ontrack.com/de/datenrettung/server-datenrettung/ oder unter https://www.ontrack.com/de/datenrettung/datenbank-datenrettung/