Halli hallo hallöchen! In den letzten Wochen hat mich dieser Server gleich zwei mal auf Trab gehalten und ich dachte, das könnte euch auch interessieren. Also: Bereit für was technisches?

Kaum ist man mal weg!

Anfang März war ich, ihr könnt es hier nachlesen, geschäftlich in Paris. Ich habe vor der Abfahrt noch geunkt: Hoffentlich läuft alles, wenn ich nicht hier bin um alle Geräte regelmäßig zu streicheln… Und am Mittwoch Nachmittag kam prompt die eMail: Website ist offline. Oh Schreck! Der Puls geht durch die Decke, Adrenalin-Ausschüttung. Und ich sitze hier in Paris und soll mich auf die Arbeit konzentrieren.

Auf dem Weg zurück ins Hotel hab ich mir erst mal überlegt, was es denn alles sein könnte:

• Internet gestört -> Kann ich Eva fragen
• Webserver abgestürzt -> Dann komme ich zumindest noch aus der Ferne auf die Kommandozeile und kann reparieren
• Fritzbox kaputt?
• SERVER DEFEKT?!?

Also habe ich versucht, das Thema analytisch an zu gehen und Eva gefragt, ob denn unser Internet noch geht. Und leider – das ging noch. Das wäre noch am „billigsten“ gewesen, denn dann hätte ich nix reparieren müssen.

Stufe zwei: Aus der Ferne auf die Kommandozeile anmelden – ging nicht. Wenn das Internet läuft und die Verbindung zum Server trotzdem weg ist, dann ist wohl der Server abgestürzt oder „gestorben“. Schritt drei: Reboot.

Aber auch nach dem Neustart kam er nicht online. War also doch die Hardware defekt? Ich sah mich schon den Server einschicken, Wochenlang auf Ersatz warten… Panik macht sich breit. Langsam hab ich angefangen, meine Verhandlungsposition mit dem Hersteller zu prüfen. Ich hatte noch Garantie… Kann ich erst ein Austauschgerät bekommen?

In meiner Verzweiflung habe ich noch einmal versucht heraus zu bekommen, ob ich irgendwie aus dem Internet auf den Rechner zugreifen kann. Zum Beispiel mit „ping“: Unknown host. DNS-Namensauflösung: Unresolvable. Und da, ganz langsam, machte sich ein Verdacht breit: Der DynDNS-Anbieter, der gegen Bezahlung aus dem Namen (soltauhome.dyndns.org) eine IP Adresse macht. Aber von denen hatte ich schon seit Ewigkeiten keine Nachrichten mehr bekommen… ob das was damit zu tun hat?

Ich habe dort im Kundenkonto meine web.de Adresse hinterlegt. Und was hat web.de vor ungefähr einem Jahr aktiviert? Einen nicht deaktivierbaren Spam-Filter auf deren Server. Etwas, das ich nur begrüße, wenn sie den Mist auch zuverlässig filtern. Aber leider ist web.de mit der zuverlässigen Erkennung von Spam regelmäßig überfordert und wirft tonnenweise zulässige eMails in den Spam-Ordner. Etwas, das mein Thunderbird seit fast 20 Jahren deutlich besser kann und das mich regelmäßig zwingt, mich über den Browser bei web.de anzumelden und den Spam-Ordner zu durchforsten. Dilettanten.

Genau dort, im Spam-Ordner, warteten vier eMails von DynDNS auf meine Aufmerksamkeit, die mich in den letzten Tagen darüber informieren wollten, dass eine neue Zahlung ansteht, die wegen einer abgelaufenen Kreditkartennummer im Konto nicht eingezogen werden konnte. Die mir weiterhin mitteilen wollten, das mein gebuchter Dienst dringend zu verlängern sei und dass mit Stichtag eben diesen Mittwochs der Dienst eingestellt würde. Super.

Immerhin: Neue Kreditkarte hinterlegt, Dienst bezahlt, und keine 5 Minuten später kam die eMail vom Monitoring: Website ist wieder online. So einfach kann es sein…

Das Fest mit der Platte: Festplatte

Ihr habt es ja vielleicht hier schon gelesen, seit Ende Januar läuft das hier auf neuer Hardware. Das tut es auch sehr flott und stabil. Zumindest im Allgemeinen.

Wie es sich gehört, wird hier regelmäßig Backup gemacht. Zunächst auf eine interne Festplatte und dann, alle paar Wochen, von dort auf eine externe Platte verschoben. Vor ein paar Tagen ist mir bei einer Routine-Kontrolle der Server-Logfiles folgendes ins Auge gehüpft:

ata7.00: exception Emask 0x10 SAct 0x1800 SErr 0x280100 action 0x6 frozen
ata7.00: irq_stat 0x08000000, interface fatal error
ata7: SError: { UnrecovData 10B8B BadCRC }
ata7.00: failed command: READ FPDMA QUEUED
ata7.00: cmd 60/00:58:ef:74:a7/08:00:74:00:00/40 tag 11 ncq dma 1048576 in
ata7.00: status: { DRDY }
ata7.00: failed command: READ FPDMA QUEUED
ata7.00: cmd 60/00:60:ef:7c:a7/08:00:74:00:00/40 tag 12 ncq dma 1048576 in
ata7.00: status: { DRDY }
ata7: hard resetting link

Die alarmierenden Teile dieser Meldung sind:

• action frozen
• interface fatal error
• badCRC (ungültige Prüfsumme)
• hard resetting link

Immer dann, wenn es um Daten und deren Transport zwischen Festplatten geht, will man solche Meldungen lieber nicht lesen. Was ist hier los? Festplatte defekt? Controller „im Arsch“? War das schon immer so? Oder ist das gerade erst aufgetaucht? Fragen über Fragen.

Also habe ich die Suchmaschine meiner Wahl angeworfen und nach ähnlichen Vorfällen und deren Behebung gesucht. Besonders häufig wurde dabei eine Inkompatibilität genau meines Festplattenmodells mit bestimmten Controllern erwähnt. Sicherheitshalber wurde direkt die Rückgabe der Festplatte und der Neukauf eines anderen Herstellers initiiert. Gleich nachdem die neue Platte angekommen war wurde sie ins System integriert und natürlich habe ich mir dabei noch einmal ein Bein gestellt. Aber das erzähle ich euch ein anderes Mal, oder ihr sprecht mich einfach darauf an 😉

Gestern Abend gab es nach erfolgreicher Installation der neuen Platte einen ersten Test: Und siehe da, nach ein paar Lesezugriffen stehen die gleichen Fehler wieder im Logfile. Ja leck mich doch! Immerhin: An der Platte lag es also wahrscheinlich nicht. Woran dann?

Der Teufel ist bekanntlich ein Eichhörnchen und deshalb habe ich in meiner Verzweiflung die Platte mal vom oberen in den unteren Slot gesteckt. Danach wurde selbstverständlich ein weiterer Test gemacht und DER war dann erfolgreich. Erstmal Glück gehabt. Und jetzt?

Es steht nach wie vor ein möglicher Defekt im Raum, und wenn der quasi „am Einschub“ hängt, dann möglicherweise am Mainboard oder dem Festplattencontroller. Da meines Wissens die beiden Einschübe am gleichen Controller hängen, tendiere ich dazu, diesen zunächst als Ursache aus zu schließen. Einer der Einschübe funktioniert schließlich. Mein Verdacht geht eher in die Richtung der Verbindungskabel oder des Rahmens und seiner Kontakte.

Heute habe ich jedenfalls den Hersteller angeschrieben, das Problem geschildert und angefragt, ob man mir sicherheitshalber mal ein solches Kabel zwecks Austausch zuschicken mag. Daumendrücken ist angesagt.

Und bis dahin heißt es: Weiterhin fleißig Backups machen und immer mal wieder das Logfile kontrollieren.

A propos: Macht ihr auch immer brav Backups?

Viele Grüße und „happy backupping“,
Bloke