Viele IT-Fachhändler sowie Systemhäuser als auch Administratoren kennen das Problem: Man wird zu einem Disaster-Recovery-Einsatz gerufen. Beim Kunden geht nichts mehr, der Betrieb steht still und die Mitarbeiter des Kunden können nicht mehr arbeiten.
Foto: Jeanette Dietl - Fotolia.com
Es sind die Fälle in denen es um die Wiederherstellung der Betriebsbereitschaft von Raid-basierenden IT-Systemen geht, zumeist also Server oder Einsätze an kleinen NAS Systemen. Eigentlich ideale Voraussetzungen für IT-Fachhändler und IT-Systemhäuser um kundenseitig glänzen zu können.
Insbesondere Techniker und Administratoren die über ein gewisses Maß an Erfahrung verfügen, kennen diese Situationen wohl nur zu gut. Die Erwartungshaltung des Kunden manifestiert sich in der Vorstellung, man müsse nur die Hand aufs Raid legen und alles würde gleich wieder funktionieren. Damit verbunden ist der zeitliche Druck, der kundenseitig stets präsent ist oder seitens der eigenen Vorgesetzen schlimmstenfalls noch forciert wird.
Wenn es IT-kritisch wird sollte Sicherheit an erster Stelle stehen und es sollte somit jede Maßnahme vermieden werden, die einen Techniker in die Situation versetzt an datenkritischen Stellen beim Kunden "ohne Netz und doppelten Boden" arbeiten zu müssen.
Leider ist dies häufig genug nicht der Fall. Interne Befragungen unserer Kunden haben ergeben, dass Faktoren wie zeitlicherDruck bei der Datenwiederherstellung hauptverantwortlich für die meisten gescheiterten Wiederherstellungs- und Rebuild-Versuche an RAID- und NAS Systemen sind.
Foto: Kuert Datenrettung Deutschland GmbH
Die üblichen Ausgangsszenarien dieser gescheiterten Wiederherstellungsversuche sind:
Vertauschte Festplattenreihenfolge
Auswahl zu kleiner Ersatz-Festplatten
Plötzlicher Abbruch des Rebuilding-Prozesses aufgrund defekter Sektoren
Manuelle Eingriffe im Rebuilding Prozess
Ein zu starkes Vertrauen in Marketingmerkmale des Herstellers
Abbrüche nach Austausch des Raid-Controllers
Diese Art der Szenarien werden bei Rettungsaufträgen von RAID/NAS Systemen sehr häufig angetroffen und die Fehler bei der Wiederherstellung unterlaufen nicht nur kleineren IT-Fachhändlern sowie Systemhäusern, sondern sind auch in Bereichen bis hinauf zum On-Site Service von Herstellern für uns nachvollziehbar.
Sucht man im Nachgang das Gespräch mit den IT-Technikern und den an dem Rebuilding-Versuch beteiligten Personen, so wird immer wieder der zeitliche Druck als Hauptargument angeführt.
ACHTUNG: In der Folge wird dem Druck des Kunden nachgegeben und ein Rebuilding-Versuch gestartet, ohne eine vorherige Erstellung sektorbasierter Kopien aller sich im Raid befindlichen Datenträger durchgeführt zu haben. Treten bei dieser Aktion Probleme auf, dann ist der Originalzustand der Medien bereits verfälscht und das Kind bereits in den Brunnen gefallen.
Oberstes Gebot: Nehmen Sie sich die Zeit
Festplattenkapazitäten werden nicht kleiner, ganz im Gegenteil. Und je größer die eingesetzten Festplatten in RAID Systemen sind, umso zeitaufwändiger ist die Erstellung einer sektorbasierten Kopie und natürlich auch der spätere Rebuilding-Prozess. Dies sind sehr häufig die Hauptgründe, warum Techniker und Administratoren sich bei der Datenwiederherstellung für ein höheres Risiko entscheiden.
Passieren hier Fehler, dann wird sehr schnell aus einem Wiederherstellungsprozess der einige Stunden in Anspruch nehmen kann, ein Prozess der bis zu mehrere Tage oder bei sehr komplexen Systemen sogar Wochen andauern kann.
Damit Sie erst gar nicht in die Verlegenheit eines gescheiterten Rebuild Prozess kommen, einige Tips:
Arbeiten Sie unter keinen Umständen an den Original-Festplatten im Raid-Verbund
Notieren Sie sich die Reihenfolge aller im Raid eingesetzten Festplatten hierzu zählt die
- Durchnummerierung und Dokumentation der Einschübe am Raid und der hierin eingesetzen Festplatten-ReihenfolgePrüfen Sie am Raid alle Festplatten auf ordnungsgemäße Funktionalität, checken Sie die S.M.A.R.T Parameter
Wenn Sie physikalische oder logische Defekte komplett ausschließen können dann:
- Erstellen Sie eine sektorbasierte Kopie aller sich im Raid befindlichen Festplatten.
- Tauschen Sie die Original Festplatten mit den Kopien aus und beginnen Sie den Rebuilding Prozess des Raid- oder NAS Systems anhand der Kopien.
- Lassen Sie die Originale Festplatten-Konfiguration unberührt. Dies ist die beste Voraussetzung für Rettungslabore.
Die Erstellung von sektorbasierten Kopien verschlingt Zeit, gar keine Frage. Diese Zeit steht jedoch in keinem Verhältnis zu dem Aufwand der entsteht, sollte der Rebuild-Prozess an der Original-Konfiguration durchgeführt werden und scheitern. Denn durch das Anstossen eines Rebuilding-Prozesses wird eine komplette Neu-Organisation der Daten durchgeführt und es werden "neue" Alt-Daten auf das Raid geschrieben und somit die Signaturen der Ursprungskonfiguration vorm Ausfallzeitpunkt überschrieben.
- Lange Reise mit kaputter Festplatte (Hong Kong)
Als ein weltbekannter Radfahrer und Fotograf im Mai 2013 Hong Kong erreichte, entdeckte er, dass seine Festplatte nicht mehr funktionierte. Dies war umso ärgerlicher, als dass er auf ihr Fotos und Videos seiner 40.000 km langen Benefiz-Radtour gespeichert hatte. - Katastrophenfilm (Polen)
Während ein Filmteam einen Film für ein Festival produzierte, verursachten sie am Set den absoluten Super-GAU. Als sie ein Backup ihres Laptops auf eine externe Festplatte zogen, stolperte ein Crew-Mitglied zufälligerweise über den Tisch. Sowohl der Laptop als auch die externe Festplatte krachten zu Boden - und alle Daten waren verloren. 18 Monate Filmproduktion und die zugehörigen Investitionen schienen zwei Monate vor dem Filmfestival verloren. - Vorsicht mit dem Alkohol (USA)
Ein Mann erwachte nach einer langen Party mitten in der Nacht und benutzte das, von dem er ausging, dass es eine Toilette war. Am folgenden Morgen musste er feststellen, dass es sich dabei leider um seinen Laptop handelte. - Die Wut der Spieler (Frankreich)
Eines Tages versuchte eine Mutter von drei Kindern, den Familien-Computer zu starten - sie bekam jedoch nur eine Fehlermeldung. Sie fragte ihre Kinder, ob bei der letzten Benutzung etwas vorgefallen war, denn sie wusste, dass diese ihn zuletzt verwendet hatten. Sie bekam jedoch keine Antwort. Sie fragte nochmals nach, denn sie hatte einen leisen Verdacht. Die älteste Schwester verriet der Mutter schließlich, dass ihr Bruder, als er ein Videospiel verlor, so wütend war, dass er mit seinen Fäusten auf die Tastatur einschlug. - Vereitelter Diebstahl (Italien)
Ein Dieb schleppte nach einem Einbruch zusammen mit anderem Diebesgut auch einen Laptop aus dem Haus - als er floh, geriet er jedoch vermutlich in Panik. Denn den Laptop überließ er im Garten seinem Schicksal. Der Besitzer fand ihn somit am nächsten Tag - allerdings erst, nachdem er die ganze Nacht in Regen gelegen hatte. - Sabotage (Großbritannien)
In Großbritannien bekam Kroll Ontrack ein mysteriöses Paket - darin befand sich nämlich keine Festplatte, sondern nur noch Einzelteile. Als die Ontrack-Ingenieure bei dem Unternehmen anriefen, um der Sache auf den Grund zu gehen, bekamen sie zu hören, dass die Festplatte wohl wiederholt von einem Hammer getroffen wurde. Daher beauftragte das Unternehmen Kroll Ontrack mit der Datenrettung - immerhin eine Datei konnte aus den Bruchstücken wiederhergestellt werden. Was das Unternehmen aus dieser einen Datei lernte, war, dass ein Mitarbeiter versuchte, die Daten zu zerstören, um so Beweise zu vernichten. Diese eine wiederhergestellte Datei war also genug, um den Saboteur zu überführen. - Naturkatastrophen (USA)
Leider sind Naturkatastrophen häufige Ursachen der größten Daten-Desaster. Als ein Anwender hörte, dass Hurricane Sandy auf dem Weg in Richtung des amerikanischen Festlands war, wurde er schnell aktiv und machte ein Backup aller Server. Jedoch konnte er nicht ahnen, dass der Pegel des eine halbe Meile vom Haus entfernten Flusses durch das Unwetter extrem anstieg: So standen sowohl die Server als auch die Backup-Bänder unter mehr als 70 cm tiefem Wasser. - Spinnen (Italien)
Nach dem plötzlichen Zusammenbruch eines fünf Jahre alten Servers zog ein Unternehmen die Datenretter hinzu. Als ein Ingenieur das Laufwerk öffnete, fand er ein Nest von Spinnen vor. Die Spinnen hatten sich ein kleines Feriendomizil im Inneren der Festplatte eingerichtet. - Noch mehr gefällig?
Wer die kuriosesten Datenpannen der vergangenen Jahre Revue passieren lassen möchte, wird in der "Hall of Fame" von Kroll Ontrack fündig.
Scheitert ein Rebuild des Raid Verbunds, ist die Wahrscheinlichkeit hoch, dass auch ein 2. oder 3. Rebuilding Versuch nicht zum gewünschten Ergebnis führen wird und den Gesamtzustand des Raids noch weiter verschlechtert. Ein weiterer wesentlicher Faktor beim Scheitern eines Wiederherstellungsversuchs ist zudem auch der prozentuale Fortschritt, bis der Abbruchzeitpunkt erreicht wurde.
Aus der Sicht der Hersteller
Auch der Support von NAS-Herstellern ist oftmals zu einseitig auf die Wiederherstellung der Funktionsbereitschaft der jeweiligen Systeme fixiert. An dieser Stelle übersehen die Hersteller-Hotlines, dass es kundenseitig vollkommen egal ist, um welche Marke es sich handelt, solange es nur gelingt, die Betriebsbereitschaft vorm Ausfallzeitpunkt wiederherzustellen.
Der Hersteller-Support hat jedoch häufig eine andere Sicht der Dinge, hier dreht sich alles um die ordnungsgemäße Funktionsbereitschaft des jeweiligen Produkts. Datenverlustrisiken werden aus dieser Perspektive häufig zu sekundär betrachtet.
In der Praxis bedeutet dies für einen Hotliner zunächst einmal telefonische Ursachenforschung, ob ein Hardware-Defekt am NAS vorherrscht, beziehungsweise ob das NAS ausgetauscht werden muss oder nicht. Verbunden ist diese Sichtweise auch mit fragwürdigen Handlungsanweisungen, bei denen die Risiken eines potenziellen Datenverlusts häufig komplett unerwähnt bleiben. Insbesondere IT-Händler, die solchen Ratschlägen blindlings folgen, setzen sich im Verlustfall von Kundendaten gegebenenfalls einem Haftungsrisiko aus, was sich unter Kalkulation eines höheren zeitlichen Aufwands für die Erstellung von Kopien einfach vermeiden ließe.
Bei unseren internen Auswertungen für das Jahr 2014 haben wir diese Szenarien häufiger angetroffen als wir es zum Jahresbeginn selbst vermutet haben. Am stärksten verblüfft die Tatsache, dass sich diese Szenarien nicht nur auf die Hotlines kleinerer NAS-Hersteller beschränken. Sie sind auch im Enterprise-Segment anzutreffen sind, sei es durch die Vor-Ort Direktkundenbetreuung innerhalb größerer Rechenzentren oder über die jeweiligen Hotlines.
Sich unter den vorgenannten Aspekten dem Zeitdruck zu beugen und potenzielle Datenverlustrisiken billigend in Kauf zu nehmen, ohne dem Kunden detailliert die Tragweite der Konsequenzen sehr deutlich vor Augen zu führen, grenzt stark an Fahrlässigkeit und somit unprofessioneller Vorgehensweise. (bw)