Der Server war weg. Der Fehler lag nicht bei mir.

Am 10. August 2026 um 03:55 Uhr (MESZ) meldete meine Überwachung, dass mein Server nicht mehr erreichbar war. Kein Update am Vortag, keine Konfigurationsänderung, kein Wartungsfenster. Einfach Stille.

Wer eigene Systeme betreibt, kennt den Moment und die Frage, die sofort mitkommt: Habe ich das verursacht? Diese Frage ist keine Eitelkeit. Sie bestimmt, was du als Nächstes tust. Liegt es an dir, suchst du im eigenen System. Liegt es nicht an dir, ist jede Minute, die du dort suchst, verlorene Zeit.

Die eigentliche Aufgabe war deshalb nicht, den Server zu reparieren. Sie war, von außen zu beweisen, wo die Ursache liegt. Genau das lässt sich lernen, und es funktioniert unabhängig davon, ob du einen eigenen Server betreibst oder einen Dienst nutzt, der plötzlich nicht mehr reagiert.

Das Problem

Die Meldung kam nicht vom Anbieter, sondern von meiner eigenen Überwachung. Ich betreibe dafür Uptime Kuma auf einem zweiten, unabhängigen System. Das ist keine Spielerei, sondern eine Geschäftsentscheidung: Wenn ich Kunden gegenüber für Verfügbarkeit einstehe, will ich nicht davon abhängen, was der Anbieter über den Zustand meiner Systeme behauptet. Ich will es selbst wissen, und zwar zuerst.

Um 03:55 Uhr schlugen zwei voneinander unabhängige Prüfungen gleichzeitig an: die Erreichbarkeit der Anwendung lief in eine Zeitüberschreitung, und von 47 gesendeten Netzwerkpaketen kam kein einziges zurück. Sechs Minuten später meldete auch die Verwaltungsoberfläche meiner eigenen Infrastruktur den Server als nicht erreichbar und schaltete die laufenden Automatisierungen ab.

Drei Meldungen, dieselbe Richtung. Nur die Steuerungsebene des Anbieters war anderer Meinung.

Der erste Widerspruch

In der Verwaltungsoberfläche des Anbieters gibt es zwei Dinge, die man leicht für dasselbe hält. Sie sind es nicht, und der Unterschied hat diese Diagnose eröffnet.

Das eine ist die Statusanzeige. Sie meldete durchgehend "running". Dieses Feld ist ein gespeicherter Zustand in der Verwaltung des Anbieters, kein Messwert. Es sagt aus, was zuletzt eingetragen wurde, nicht, was gerade passiert.

Das andere sind die Graphen für Prozessorlast, Netzwerk und Festplatte. Das sind echte Messwerte, und zwar gemessen von der Ebene, auf der mein Server läuft, nicht von meinem Server selbst. Diese Ebene, das Wirtssystem, führt meine virtuelle Maschine aus. Sie kann sie deshalb auch dann noch beobachten, wenn in der Maschine gar nichts mehr läuft.

Und genau diese Graphen zeigten etwas, das ich vorher so noch nicht gesehen hatte: Alle drei enden zum selben Zeitpunkt. Sie fallen nicht auf null ab, die Aufzeichnung hört auf.

Dieser Unterschied ist der Kern der ganzen Geschichte. Wäre mein System abgestürzt oder vom Netz getrennt gewesen, hätte es weiterhin Messpunkte gegeben: Netzwerk auf null, Prozessorlast im Leerlauf. Eine Linie auf null ist immer noch eine Linie. Dass die Messung selbst endet, bedeutet, dass es nichts mehr zu messen gab. Die Maschine wurde nicht mehr ausgeführt.

Damit stand eine Verwaltungsoberfläche vor mir, die sich selbst widersprach. Ein Statusfeld, das "läuft" sagt, und eine Messung derselben Ebene, die seit Stunden nichts mehr aufzeichnet. Der Widerspruch war der erste ernsthafte Hinweis, aber ein Hinweis ist noch kein Beweis. Beim Verdacht stehen zu bleiben, wäre genau der Fehler gewesen, den ich anderen abgewöhne.

Die Bestätigung von außen

Der Verdacht musste sich von außen bestätigen lassen, unabhängig von jeder Anzeige des Anbieters. Ich habe deshalb vom zweiten Server aus gemessen. Drei Befunde kamen zusammen.

Zeitüberschreitung, nicht Ablehnung. Das ist der Unterschied, den man einmal verstanden haben muss. Wenn ein System erreichbar ist, eine Verbindung aber nicht zulässt, kommt eine Ablehnung zurück, im Fachjargon "Connection refused". Das heißt sinngemäß: Ich bin da, und ich sage Nein. Kommt dagegen gar keine Antwort, läuft die Anfrage in eine Zeitüberschreitung, einen Timeout. Das heißt: Da ist niemand.

Stell es dir wie eine Haustür vor. "Refused" ist, wenn jemand aufmacht und dich wegschickt. "Timeout" ist, wenn du klingelst und nichts passiert. Zwei völlig verschiedene Befunde, zwei völlig verschiedene Ursachen. Bei mir war es durchgehend Timeout, auf allen Wegen.

Die Firewall ausgeschlossen, nicht vermutet. Der naheliegendste Verdacht bei "keine Antwort" ist eine Firewall-Regel, die man selbst verbockt hat. Also habe ich die Route zum Server verfolgt, gezielt auf zwei Ports, die freigegeben sind. Die Pakete kamen bis in das Netz des Anbieters und dort war Schluss. Eine falsche Regel auf meiner Seite hätte ein anderes Bild ergeben. Der Verdacht war damit nicht abgeschwächt, sondern ausgeschlossen.

Der Bildschirm bleibt schwarz. Über die Notfallkonsole kommt man normalerweise auch dann auf ein System, wenn das Netzwerk streikt, weil diese Konsole nicht vom Server selbst kommt, sondern von der Ebene darunter. Sie verband nicht und wurde sofort wieder getrennt. Auch das Wirtssystem reagierte also nicht mehr.

Vier Beobachtungen, eine Richtung. Der Verdacht aus den Graphen war bestätigt, der nächstliegende Gegenverdacht ausgeräumt.

Das Ticket beim Anbieter war zu diesem Zeitpunkt bereits offen, eröffnet um 06:27 Uhr (MESZ), gleich nachdem klar war, dass der Server nicht von selbst zurückkommt. Knapp eine Stunde später, um 07:21 Uhr, habe ich die vier Befunde nachgereicht. Das ist der Unterschied zwischen "bei mir geht was nicht" und einer Meldung, die dem Empfänger sagt, wo er nachsehen muss.

Die Rückmeldung bestätigte die Diagnose: Problem auf dem Wirtssystem, inzwischen behoben, der Server sei vom Anbieter neu gestartet worden. Auf Nachfrage kam noch, dass keine Migration auf ein anderes Wirtssystem nötig war. Die Frage, wie wahrscheinlich eine Wiederholung ist, blieb unbeantwortet.

Zwei Irrwege, die dazugehören

Fallstudien lesen sich meistens so, als wäre alles glatt gelaufen. Bei mir waren zwei Fehlschlüsse drin, und beide sind lehrreicher als der saubere Teil.

Zum Kontext: Der Alarm erreichte mich abends, unterwegs, mit nichts als dem Telefon in der Tasche. Die komplette Diagnose lief über eine Terminal-App auf Telefon und Tablet, von der ersten Prüfung bis zum letzten Nachtrag im Ticket. Ein Rechner war nicht im Spiel.

Der erste Irrweg kam aus dieser Umgebung. Mitten in einem Diagnoseblock riss die Verbindung zum zweiten Server ab, ohne dass ich es bemerkte. Die restlichen Befehle liefen danach lokal auf dem Telefon weiter. Die Ausgaben sahen völlig plausibel aus. Ein Ergebnis daraus, hundert Prozent Paketverlust, wäre fast als Befund im Ticket gelandet. Gemessen war es aber aus einem Mobilfunknetz, das diese Art von Anfragen ohnehin blockiert. Aufgefallen ist es nicht mir, sondern dem KI-Assistenten, mit dem ich die Analyse durchgegangen bin. Seitdem steht die Abfrage des Rechnernamens am Anfang jedes Diagnoseblocks. Zwei Sekunden Aufwand, die eine falsche Fährte verhindern.

Der zweite Irrweg kam von der KI. Sie schloss aus der Laufzeit des Systems, es habe während des Ausfalls gar keinen Neustart gegeben, ohne den absoluten Startzeitpunkt gegenzuprüfen. Ich habe korrigiert. Unmittelbar danach las dieselbe Analyse den Zeitstempel als Ortszeit statt als Weltzeit und verschob den Neustart um Stunden. Zweimal hintereinander wurde eine Beobachtung als Bestätigung der bevorzugten These genommen, statt sie gegenzuprüfen.

Bemerkenswert daran ist die Richtung: Meinen Fehler hat die KI gefunden, ihre Fehler habe ich gefunden. Das ist kein Argument gegen den Einsatz solcher Werkzeuge und auch keines dafür, ihnen blind zu folgen. Es ist ein Argument für die Gegenprüfung als Methode, und dafür, dass am Ende ein Mensch entscheidet.

Die Zeitzonenfalle

Ein Detail am Rande, das mehr Fehlersuchen ruiniert, als man denkt. Bei diesem Vorfall lagen vier Zeitzonen gleichzeitig auf dem Tisch: Das Systemprotokoll schreibt in Weltzeit, ein Dienst darauf meldete in mitteleuropäischer Sommerzeit, meine Geräte standen auf einer dritten Zone, und ich selbst saß in einer vierten.

Das Tückische daran ist nicht, dass die Uhrzeiten falsch wären. Sie sind alle richtig. Sie beschreiben denselben Moment nur mit verschiedenen Zahlen. Wenn du zwei Protokolle nebeneinanderlegst und beide Zeiten plausibel aussehen, entsteht daraus eine Reihenfolge von Ereignissen, die es nie gegeben hat. Ursache und Wirkung tauschen den Platz, ohne dass irgendetwas offensichtlich falsch wirkt.

Dazu kommt ein zweiter Effekt, der noch weniger Beachtung findet: Ein Protokoll schreibt einen festen Zeitstempel. Eine Chat-App oder ein Mailprogramm rechnet ihn bei jedem Öffnen neu um, auf die Zone, die gerade eingestellt ist. Wer einen Screenshot als Beleg weiterreicht, dokumentiert damit auch die Einstellung seines Geräts, und niemand schreibt dazu, welche das war.

Deshalb steht in diesem Artikel hinter jeder wichtigen Uhrzeit die Zeitzone. Das Thema bekommt demnächst einen eigenen Artikel, es verdient mehr Platz als diesen Absatz.

Das Ergebnis

Um 11:39 Uhr (MESZ) antwortete der Server wieder auf Netzwerkebene, zwei Minuten später lieferte auch die Anwendung wieder eine gültige Antwort. Knapp acht Stunden Ausfall, genauer: 7 Stunden und 44 Minuten.

An dieser Stelle wäre der Vorfall für viele beendet. Er ist wieder da, weiter im Text. Ich halte das für den falschen Reflex, und zwar aus zwei Gründen: Protokolle sind flüchtig, und der Befund bestimmt, was danach zu tun ist. Also zuerst Datenintegrität, dann Kosmetik.

Im Anschluss geprüft und dokumentiert:

• Der Speicherpool meldet sich fehlerfrei, keine Lese-, Schreib- oder Prüfsummenfehler. Das verwendete Dateisystem schreibt Änderungen an neue Stellen, statt bestehende zu überschreiben. Deshalb übersteht es einen harten Abbruch ohne Spuren.
• Beide Datenbanken erkannten das unsaubere Herunterfahren und stellten sich selbst wieder her, sauber abgeschlossen, ohne Fehler.
• Die Datenbank der Automatisierungsumgebung bestand die Integritätsprüfung.
• Die Nextcloud-Instanz lief ohne offenen Wartungsmodus, ohne ausstehende Datenbankänderungen, ohne fehlende Indizes.

Kein Datenverlust, keine Folgeschäden. Erst danach habe ich den geprüften Zustand gesichert, mit einem zusätzlichen Restic-Backup außerhalb des täglichen Automatismus.

Das ist die Reihenfolge, auf die es ankommt. Der Server lief längst wieder, die Dienste waren erreichbar, niemand hätte etwas gemerkt. Geprüft wurde trotzdem, vollständig, statt nach dem ersten "geht ja wieder" abzubrechen. Und gesichert wurde nicht irgendein Zustand, sondern der, von dem ich wusste, dass er in Ordnung ist.

Die Prüfung förderte noch etwas ganz anderes zutage: einen alten Eintrag in der Laufwerkskonfiguration, übrig aus der Zeit vor einer Dateisystem-Migration, der ein Laufwerk noch im alten Format einbinden wollte. Er war unwirksam und blockierte auch keinen Start, aber er lag da herum. Jetzt ist er weg. Solche Altlasten findet man nicht, wenn man nach einem Ausfall nur schaut, ob die Seite wieder lädt.

Was du daraus mitnehmen kannst

Der Defekt auf dem Wirtssystem ist für dich vermutlich belanglos. Drei Dinge sind es nicht:

Eine Statusanzeige ist keine Messung. "Läuft" bedeutet, dass ein Feld in einer Verwaltung auf "läuft" steht. Ob wirklich etwas läuft, sagen dir nur die Daten dahinter. Und wer das unabhängig vom Anbieter wissen will, muss selbst messen.

Der naheliegende Verdacht gehört ausgeschlossen, nicht angenommen. Wenn du die Firewall verdächtigst, prüf sie so, dass die Antwort eindeutig ist. Ein stehen gelassener Verdacht kostet dich Stunden in der falschen Richtung.

Erreichbar ist nicht geprüft. Zwischen "es läuft wieder" und "ich weiß, dass nichts kaputt ist" liegt genau die Arbeit, die niemand sieht und die im Ernstfall zählt.

Wenn du bei so einer Fehlersuche jemanden brauchst, der systematisch vorgeht und dir hinterher sagen kann, was tatsächlich geprüft wurde: klare-beratung.de