Glorf IT

In dem sehr interessanten TecChannel-Artikel "Desktop-Virtualisierung als Ursache: Datenrettungsfälle bei VMware-Umgebungen steigen stark" werden die Erfahrungen von Ontrack aus dem Jahr 2008 geschildet: Die Rettungsfälle aus virtuellen Umgebungen verzehnfachten sich. Wer aber nun falsche Schlüsse zieht, sollte sich erst die Ursachen durchlesen:

Hintergrund der Entwicklung scheint zu sein, dass in den letzten Jahren zunächst die Server-Virtualisierung das Bild bestimmte, nun aber Unternehmen zunehmend auch auf eine virtualisierte Desktop-Infrastruktur setzen. Und damit steigt exponentiell das Volumen potenziell geschäftskritischer Daten, die in virtuellen Umgebungen vorgehalten werden.

Gibt es also wirklich 10 mal so viele produktiv eingesetzte VMs, die statistisch freilich zu 10 mal so vielen Problem führen?

Durch den SQL-Server-Magazine-Artikel "SQL Server Internals Viewer " von Kevin Kline "entdeckte" ich für mich das Tool. Mit diesem Werkzeug kann man sich den Inhalt von Datenbanken seitenweise ansehen. Das klingt trocken, ist aber einfach genial.

Alleine durch das Ansehen habe ich mehr verstanden als durch die Lektüre von guten Büchern, die ich irgendwann abbrach, weil es einfach zu trocken wurde… Natürlich könne man sich das auch alles mit DBCC PAGE ansehen, aber das ist dann doch noch mal eine Spur härter.

Es ist einfach unglaublich, was man auf den Seiten alles erkennen kann. So habe ich heute beispielsweise mal geschaut, ob ich einer beliebigen vom Kunden geschickten MDF ansehen kann aus wie vielen Dateien die DB bestehen sollte und wo sie zuletzt lagen. Das geht und ist gar nicht so schwer. Ich konnte auch die komplette Liste der internen Systemtabellen sehen und studieren. Einfach genial!

Ideal ist es auch zur Analyse von Datenbank-Korruptionen, aber dazu schreibe ich demnächst noch mehr. Auf der Homepage steht ein kurzer, gelungener Überblick, deswegen schenke ich mir den an dieser Stelle… 😉

Hier geht es zum Download. Interessant ich auch noch der noch junge, aber schon lesenswerte Blog des Autors Danny Gould.

In der September-Ausgabe von TecChannel-Compact (04/2007) ist ein sehr interessanter Test über die Zuverlässigkeit von externen Festplatten.
Der gleiche Artikel findet sich auch online unter dem Titel "Sicherheitsrisiko: Externe Festplatten im Test" (http://www.tecchannel.de/storage/komponenten/451265/).

Insgesamt schneiden die externen Platten gar nicht so schlecht ab, aber in Punkto Hitze wurden sehr bedenkliche Werte gemessen. Laut Datenblättern laufen die Festplatten im Bereich von 5 bis 35Grad Celsius einwandfrei. Darüber erhöht sich die Ausfallrate erheblich, ab etwa 60Grad ist dann auf jeden Fall Sense. Vermutlich steigt ihnen die Hitze zu Kopf. 😉
In dem Artikel wurden einige externe Platten bei verschiedenen Umgebungstemperaturen betrieben und deren Temperatur gemessen. Dabei kamen schon bei 30Grad Umgebungstemperatur etliche Festplatten an oder über die magische 60Grad-Grenze.
Mein Resümee war bei externen Platten für die Datensicherung auf Geräte mit Gehäuselüfter zu setzen…

Wer immer schon mal wissen wollte, wie kaputte Festplatten klingen, der wird bei Hitachi Global Storage Technologies fündig. Bei den Geräuschen läuft es mir eiskalt den Rücken runter…

Die Formulierung ist ja wohl auch stark: "may indicate"

There are various noises that may indicate a failing hard drive. If you are experiencing any of the noises, please contact the technical support center at: […]

Ich nutze die leichte "Kälteperiode", um an ein heißes Problem zu erinnern, das nun wieder auf uns zu kommt: Festplatten verkraften keine Hitze.

Diese triviale Weisheit wird gerne vergessen oder verdrängt. Deswegen der Rat doch noch mal zu überprüfen, wo der Server mit den wichtigen Daten steht: Unter dem Dach? In einem fensterlosen Raum ohne Klimananlage? Ist ein Thermometer in dem Raum?

Natürlich ist auch ein Standort im tiefen Keller nicht immer die beste Wahl (siehe "Problem mit dem Safe"), aber dennoch sind die Hitzeperioden meiner Erfahrung nach die bedeutensten Plattenkiller.

Wir hatten beispielsweise letztes Jahr einen recht lehrreichen Fall bei einem unserer Kunden:
Im seinem Geschäft war es eines Freitags im Laufe des Tages so heiß geworden, dass er zum Feierabend mal lieber alle Rechner herunterfuhr, auch den Server. Die Rechner hatten Zeit sich zu erholen und mussten nicht die unbemannten Räume heizen. Am Montag früh wurde der Server gestartet. Wie sich herausstellte, waren da alle Datenbanken im Eimer, weite Teile der Platte übrigens auch.

Leider kannte ich zu dem Zeitpunkt noch nicht den Artikel "Hitzetod: Jeder PC ist gefährdet" aus TecChannel.

Aus den Datenbank-Dateien konnten wir keinen fachlich brauchbaren Stand mehr basteln. Tragischerweise führte der Kunde immer nur am Wochenende eine Datensicherung durch, aber da war der Server ja gestoppt…
🙁

Deswegen der Tipp: Nur abends oder am Wochenende die Kisten ausschalten reicht nicht: Man benötigt einen kühlen Standort für die Server. Auch in einem kleinen Laden.

Laut TecChannel.de hat Ontrack wieder einen neuen Bericht zur Lage an der Datenrettungsfront mit den Zahlen aus 2006 verfasst. Leider kann ich ihn auf deren Homepage nicht finden. Daher muss ich mich mit den wenigen Happen begnügen, die im Artikel "Datenverlust: Hardware empfindlicher, User schlauer, Viren harmloser" erwähnt werden.

Nahezu 60 Prozent aller Fälle von Datenverlust gehen laut dem Datenretter mittlerweile auf hardwarebedingte Probleme zurück. Im Jahr 2002 lag dieser Wert noch bei 44 Prozent.
[…]
Der Prozentanteil von Schäden durch Computerviren ist von sieben auf zwei Prozent eingebrochen.

Wobei ich es interessanter finde, wie sich die absoluten Zahlen entwickelt haben. Die Prozentangaben alleine sind mir noch nicht aussagekräftig genug, um einen Trend aufzuzeigen. Die Freunde zählen defekte Bänder übrigens auch zu den Hardware-Problemen.

Dennoch spiegelt sich in den Werten meiner Ansicht nach wieder, dass die Betriebssysteme besser geworden sind, die Datenbanksoftware weniger Fehler enthält und die Treiber stabiler. Was man eindeutig ableiten kann: Gerade heutzutage sind Hardware-Ausfälle die häufigste Ursache für Datenverluste.

Und? Heute schon ein Backup gemacht?

In dem Artikel "Oh no – my backup is corrupt too! Help!" beschreibt Paul Randal, dass man nicht nur prüfen sollte, ob die Datenbank in Ordnung ist, sondern auch die Backups prüfen sollte. Eine sehr gute Idee, allerdings gab es dazu am SQL-Server-2000 keine elegante Möglichkeit später die Konsistenz des Backups zu prüfen. Man musste schon einen RESTORE in eine andere Datenbank machen und die dann testen… echt unpraktisch und langwierig!
🙁

Mit dem SQL-Server-2005 sieht es da schon anders aus. Hier gibt es die Möglichkeit die BACKUPs mit Checksummen zu versehen. Sie arbeiten intern genauso wie die Checksummen der Datenbank-Seiten. Dann kann man einfach mit dem RESTORE zu jedem beliebigen Zeitpunkt die Prüfung durchführen:

• BACKUP … WITH CHECKSUM
• RESTORE … WITH VERIFYONLY

Vor ein paar Wochen habe ich mal ein paar defekte Datenbanken für den SQL-Server-2005 erstellt. Die benötigen wir für den Test der Datenbanktests: Werden die defekte auch wirklich von unserer Software gefunden und können sie automatisch beseitigt werden? Ich dachte ja nicht, dass sich auch noch andere Leute für das Thema erwärmen können, aber Tony Rogerson beschreibt eine sehr kreative Methode in dem Blog-Beitrag "How to create a corrupt database using BULK INSERT/ UPDATE and BCP – SQL Server as a HEX editor". Ich selber war da deutlich direkter: mit dbcc page und einem Hex-Editor ging es auch…
😛

Bei Heise.de kann man eine sehr ausführlich Zusammenfassung der Google-Studie zur Haltbarkeit von Festplatten nachlesen.
Diese Studie sollte man in alle Sprachen übersetzen un deren Zusammenfassung zur Pflichtlektüre für jeden EDV-Verantwortlichen machen…

Prometeo wundert sich darüber, dass einer der Haupteinflussfaktoren auch der Hersteller ist. Das wundert mich hingegen nicht, schon früher gab es im "Flurfunk" einige Hersteller von deren Festplatten gewarnt wurde. Als Software-Firma tut man sich allerdings schwer die Namen solcher Firmen ohne zuverlässige Quellenangaben zu veröffentlichen. Deswegen stimme ich zu: es wäre schön gewesen, wenn Google die Namen genannt hätte. Immerhin haben sie ja eine echte Studie mit zuverlässigen Angaben.

Im Artikel "Fixing damaged pages using page restore or manual inserts" beschreibt Paul Randal ganz trickreich, wie man den Inhalt einzelner Seiten aus der Sicherung holt. Das ist in der Praxis durchaus relevant, wenn nur wenige Datenbank-Seiten korrupt wurden. Das war mit den bisherigen SQL-Server-Versionen nicht möglich, bzw. es war viel Handarbeit gefragt.

Am SQL-Server-2005 geht es etwa so:

RESTORE DATABASE dbccpagetest PAGE = '1:158' FROM DISK = 'C:\dbccpagetest.bak';

Dazu fragt Paul:

Isn't that cool? You can restore up to 1000 single pages from a backup at a time.

Und meine Antwort lautet: JAAAAAAA!!!

Es gibt auch eine Schattenseite: es geht nicht immer. Es geht nur, wenn entweder die Seite seit dem Backup nicht "verschoben" wurde, die Daten nicht geändert wurden oder die Datenbank im Recovery-Modus "Full" bzw. "Bulk" war:

You can use single-page restore if you're on SQL Server 2005 and the database is in Full or Bulk-Logged recovery mode, otherwise you need to use the manual method, and that will only work as long as you know the data being salvaged hasn't changed since the last backup.

Ok, die manuelle Methode ist auch nicht von schlechten Eltern. Darauf bin ich leider nicht selber gekommen, obwohl sie auf der Hand liegt. Das liegt aber vermutlich daran, dass bis zu mir meist nur die Fälle vordringen, die keine funktionstüchtige Datensicherung haben.

Hier steht es komplett, vom großen Paul Randal Himself.

Falls sich mal einer Eurer Kunden ziert Geld für die Datensicherung auszugeben, dann könnt Ihr ihm unter die Nase reiben, dass Gewerbetreibende verpflichtet sind für eine funktionierende Datensicherung zu sorgen, sonst handeln sie fahrlässig. Die genauen Formulierungen aus einem Urteil zu einem Datenverlust bei Computer-Reparatur des OLG Hamm (Urteil vom 01. Dezember 2003, 13 U 133/03) sind ausnahmsweise auch für mich Nichtjuristen verständlich und IMHO gut zu verallgemeinern:

Wie dargelegt, gehört es im gewerblichen Anwenderbereich heute zu den vorauszusetzenden Selbstverständlichkeiten, dass eine zuverlässige, zeitnahe und umfassende Datenroutine die Sicherung gewährleistet. Vor einem objektiv datengefährdenden Eingriff muss sich der Werkunternehmer zwar danach erkundigen und gegebenenfalls darüber vergewissern, ob die vom Anwender vorgenommene Datensicherung dem aktuellen Stand entspricht. Zusätzliche Überprüfungspflichten bestehen jedoch nur dann, wenn ernsthafte Zweifel vorliegen, dass die Datensicherung nicht ordnungsgemäß erfolgt ist oder das Sicherungssystem nicht funktioniert (OLG Karlsruhe NJW 1996, 2000; OLG Köln NJW-RR 1997, 558; 1994, 1262; BGH NJW 1996, 2924; Senat in OLGR 2000, 195).

Die Hervorhebungen (oben und unten) sind von mir. In dem Fall hat ein beauftragter EDV-Fachmann eine Reparatur vorgenommen und sich vorher erkundigt, ob es eine aktuelle Datensicherung gibt (für den Fall, dass etwas schief geht). Das wurde bejaht, aber wie sich später herausstellte, gab es zwar keine Datensicherung, aber Datenverluste traten trotzdem auf. Deswegen wollte der Beklagte dem Installateur die Bezahlung kürzen. Das Gericht hat die Sache aber sehr eindeutig geklärt.
Hier noch eine Passage in der der Beklagte sein Fett weg bekommt:

Die Sicherung hätte täglich erfolgen müsse, die Vollsicherung mindestens einmal wöchentlich. Das ist unstreitig nicht geschehen. Aus den Bekundungen des Zeugen N hat der Sachverständige zu Recht entnommen, dass die Sicherung von Daten im Betrieb der Beklagten schon grob fahrlässig (blauäugig) vernachlässigt wurde. […] Unter diesen Voraussetzungen hat sich die Beklagte den Schaden allein zuzurechnen, selbst wenn der Klägerin eine Pflichtverletzung im Sinne der Wahrnehmung von Controllpflichten vorzuwerfen wäre (vgl. BGH NJW-RR 1991, 1240).

Den kompletten Text gibt es bei aufrecht.de

Ergänzend dazu finde ich auch den Artikel "Urteil: Datensicherung ein Muss" bei rechtsanwalt.com interessant.

Das sind zwar schon olle Kamellen, aber neulich schrieb ich: "Wer nicht sichert, hat schon fast verloren." Das wollte ich mal näher begründen…

Unrealistische Erwartungen an die Selbstheilkräfte der Hardware

Gestern erlebten wir leider wieder einen von den Fällen in denen eine völlig defekte Datenbank eines Kunden an uns geschickt wurde, damit wir sie analysieren und retten was zu retten ist. Genau der Kunde hatte aber schon mal Datenbanken an uns geschickt. Mit nur geringen Datenverlusten konnten damals wieder konsistente Datenbestände restauriert werden. Seinerzeit wurde ihm mitgeteilt, dass seine Hardware ein Problem hat und sein EDV-Händler/-Betreuer das untersuchen und lösen soll, vermutlich ein Problem mit Festplatte und/oder Raid-Controller. Das passierte aber nicht…
Nun hat es eine Datenbank von ihm besonders schlimm erwischt. Reparaturversuch erfolglos. Datensicherung: Fehlanzeige.
Was soll man dazu sagen?

Unrealistische Erwartungen an die Haftung der Softwarelieferanten

Das ist leider kein Einzelfall. Besonders frustrierend sind die Fälle in denen man sich unheimlich reinhängt und stundenlang analysiert (weil der Kunde keine Datensicherung hat), aber unter dem Strich doch nichts oder nur wenig zu machen ist. Die meisten Kunden sind dankbar für die Unterstützung. Aber einige versuchen doch tatsächlich bei solchen Totalausfällen unsere Firma für deren Ausfallzeiten haftbar zu machen. Manche wollten sogar die neue Hardware über uns finanzieren…
Meist sind das diejenigen, die auch schon während der Analyse Druck machen, mehrfach anrufen oder von den Kollegen umfassende schriftliche Statusberichte fordern und somit von der Unterstützung abhalten, die sie eindringlich einfordern. Da spielt die Psychologie auch immer eine große Rolle: Schuldgefühle und Verzweiflung ergeben eine explosive Mischung. Dann muss es ganz hektisch gehen, aber dennoch akkurat und fehlerlos.
Wenn sie nur ein Bruchteil des Engagements gezeigt hätten, als es um die Einrichtung der Datensicherung ging, dann wäre ihnen viel Kummer und Leid erspart geblieben. Wer nicht sichert, hat schon fast verloren…
🙁

Das bringt mich darauf, dass ich die Serie mit Hinweisen zur Datensicherung noch nicht abgeschlossen habe. Das ist jetzt in meinem Stack wieder ganz oben.
😉