Versehentlicher Befehl bringt datenbank-Server zum Absturz
Die Situation
Ein in Korea ansässiger Managed Service Provider versuchte, Konfigurationsänderungen am NetApp System seines Kunden vorzunehmen, als ein Techniker fälschlicherweise einen "dd"-Befehl auf einigen LUNs startete, wodurch die Daten, die Teil des Sybase-Produktionsservers des Endbenutzers waren, effektiv gelöscht wurden.
Ohne Zugriff auf die Daten drohte dem Managed Service Provider der Verlust des Vertrages mit seinem Kunden sowie potenzielle Haftungskosten.
Der Kunde verfügte über ein NetApp FAS8060 System mit 161 x 900 GB SAS HDDs, die in zwei separaten Aggregaten angeordnet waren (68 Laufwerke + 93 Laufwerke). Der Kunde stellte 3 x 468 GB FC LUNs von jedem Aggregat an einen Sybase Server bereit. Die insgesamt 6 LUNs wurden zu einem einzigen Disk-Pool zusammengefasst, wobei drei logische Volumes aus dem Pool herausgeschnitten wurden. Ein fehlerhafter "dd"-Befehl hatte Nullen auf etwa 45 GB eines der logischen Volumes geschrieben, und dieses Volume war für den Sybase-Server nicht mehr sichtbar.
Die Lösung
Während der ursprünglichen Beratung riet unser Ingenieur von Ontrack dem Kunden, die Aggregate offline zu bringen, um weitere Überschreibschäden zu vermeiden. Die Aggregate wurden innerhalb von 12 Stunden nach dem ursprünglichen Datenverlustereignis offline geschaltet.
Der Kunde legte alle 161 Festplatten von beiden Aggregaten auf einen einzigen Windows-Rechner und verband diesen mit dem RDR-Server (Remote Data Recovery) von Ontrack. Eine erste Überprüfung ergab, dass beide Aggregate den Namen "aggrO" trugen, was unserem Techniker die Möglichkeit nahm, das Aggregat automatisch wiederherzustellen. Die Laufwerke wurden in Aggregatgruppen sortiert und die Aggregate wurden manuell neu aufgebaut.
Unsere Techniker waren dann in der Lage, die Aggregate zu einem Zeitpunkt wiederherzustellen, der so nah wie möglich, aber vor dem Auftreten des "dd"-Schadens lag, wobei die einzelnen Aggregate zu einem Zeitpunkt wiederhergestellt wurden, der innerhalb von zwei Minuten lag.
Das Ergebnis
Unser Ingenieur war nicht in der Lage, die internen Daten zu extrahieren oder zu untersuchen, da die logischen Volumes vom Sybase-Server als RAW-Speicher verwendet wurden. Alle sechs LUNs wurden dann als flache Dateien auf externen Speicher extrahiert. Der NetApp Support konnte dabei helfen, diese LUNs dem Sybase Server wieder zur Verfügung zu stellen.
Die wiederhergestellten logischen Volumes bestanden die Integritätsprüfungen auf dem Sybase Server und der Kunde bestätigte, dass alles ordnungsgemäß funktionierte. Der Datenbankserver des Endanwenders konnte innerhalb weniger Tage nach dem Ausfall ohne Datenverlust wieder online gebracht werden.