Am 30. April 2025 kam es bei Healthchecks. io, einem beliebten Open-Source-Dienst zur Überwachung von Cron-Jobs, zu einem umfangreichen Datenbankausfall, von dem Nutzer etwa 30 Minuten lang betroffen waren. Der Ausfall hatte weitreichende Auswirkungen auf die Verfügbarkeit der Dienste und löste eine Reihe von Maßnahmen aus, die helfen sollen, die Robustheit und Zuverlässigkeit der Datenbankinfrastruktur langfristig zu verbessern. Im Folgenden wird der Vorfall detailliert analysiert, um die Ursachen des Ausfalls nachzuvollziehen und die ergriffenen Maßnahmen sowie zukünftige Strategien zur Fehlervermeidung vorzustellen. Dabei spielt die Hardware des Datenbankservers eine zentrale Rolle, da sie höchstwahrscheinlich die Hauptursache für den Ausfall darstellte. Die ersten Anzeichen für die bevorstehende Störung traten bereits etwa 15 Minuten vor dem eigentlichen Ausfall auf.
Das Monitoring-Tool Netdata registrierte ab 15:30 UTC ungewöhnliche Schwankungen bei der CPU-Temperatur, der Prozessor-Auslastung und der Ein-/Ausgabeaktivität auf dem Datenbankserver. Diese Abweichungen deuteten auf eine instabile Hardware hin, was kurz darauf von einem kritischen Fehler im PostgreSQL-Server bestätigt wurde. Um 15:36 UTC wurde im Systemprotokoll ein „Segfault“ aufgezeichnet, ein schwerwiegender Fehler, der auf einen unerwarteten Speicherzugriffsfehler hinweist. Wenig später, um 15:46 UTC, kam es zum vollständigen Stillstand des Servers. Das System reagierte nicht mehr auf Ping-Anfragen, was auf einen Totalausfall hindeutete. Der Betreiber Pēteris Caune befand sich zum Zeitpunkt des Ausfalls nicht am Arbeitsplatz, sondern etwa 15 Minuten entfernt auf einem Spielplatz mit seinen Kindern. Er hatte zwar einen Laptop dabei, jedoch waren die auf dem Gerät verfügbaren Werkzeuge für eine schnelle Notfallreaktion nicht aktuell.
Um kein weiteres Risiko durch veraltete Tools einzugehen, entschied er sich, zurück in den Arbeitsbereich zu fahren, um von dort den Server neu zu starten. Als er den Hauptarbeitsrechner erreichte und den Datenbankserver nicht mehr erreichen konnte, wurde ein Hardware-Reset durchgeführt. Dieses manuelle Eingreifen brachte den Server nach einigen Minuten wieder zum Laufen, und die Dienste konnten ihren Betrieb fortsetzen. Alternativ hätte auch der Standby-Server sofort den primären Posten übernehmen können; diese Option wurde jedoch zunächst nicht gewählt, da eine automatische und sichere Umschaltung nicht garantiert war. Ein unkontrolliertes Wiederhochfahren des alten Hauptservers hätte zu einer sogenannten Split-Brain-Situation führen können, bei der zwei Systeme gleichzeitig als primäre Datenbank agieren und so inkonsistente Datenzustände hervorrufen. Im Anschluss an die Wiederherstellung begann eine tiefgehende Analyse der Ursache.
Systemprotokolle bestätigten den Segfault und dokumentierten detailliert die Fehlermeldung, die auf einen Speicherzugriffsfehler auf CPU 6 (Kern 12, Sockel 0) hinwies. Trotz dieser kritischen Ausnahme zeigten Diagnosetools wie „smartctl“ keine Fehler bei den NVMe-Speicherlaufwerken. Auch die RAID-Konfiguration war intakt und zeigte keine Auffälligkeiten. Die Kombination aus Temperaturanstieg bei der CPU und sprunghaftem Temperaturabfall bei den NVMe-Laufwerken in den Minuten vor dem Ausfall deuteten jedoch klar auf eine instabile Hardwarekomponente hin, deren genaue Ursache nicht abschließend ermittelt wurde. Da die Fehlersuche anhand des Live-Systems nur begrenzt erfolgversprechend erschien und weitere Experimente an einem produktiven Server riskant gewesen wären, wurde der Fokus schnell auf den Aufbau einer alternativen, stabileren Infrastruktur gelegt. Die bestehenden Datenbankserver liefen bisher auf Hetzner-Barer-Metal-Servern des Typs EX101.
Diese waren mit einem Intel Core i9-13900-Prozessor, 64 GB ECC-RAM und zwei 1,92-TB-NVMe-Laufwerken ausgestattet. Als Ersatz wurden Server des Modells EX130-S ausgewählt, die sich in mehreren wichtigen Aspekten unterschieden. Sie verfügen über einen Intel Xeon 5412U, der vermutlich eine bessere Qualität und größere Stabilität als die bisher eingesetzten Consumer-Prozessoren bietet. Die RAM-Kapazität wurde auf 128 GB ECC verdoppelt, was nicht nur mehr Arbeitsspeicher, sondern auch eine möglicherweise andere, stabilere RAM-Bestückung erlaubte. Auch die Speicherlaufwerke wiesen mit 2 x 3,84 TB NVMe eine deutlich höhere Kapazität und unterschiedliche Modellvarianten auf. Zur Sicherstellung der Stabilität wurden die neuen Server mit dem Tool Stressapptest für zwei Stunden intensiv geprüft, wobei keine korrigierbaren Fehler im ECC-RAM festgestellt wurden. Anschließend wurde das Betriebssystem installiert und mithilfe bestehender Deployment-Skripte PostgreSQL eingerichtet.
Die Datenreplikation von den alten Servern wurde angestoßen und über den weiteren Verlauf intensiv überwacht. Nach einem Tag ohne Auffälligkeiten erfolgte die kontrollierte Umschaltung auf die neue Datenbankinfrastruktur. Dieser Vorfall macht deutlich, dass die Datenbank bei Healthchecks. io weiterhin der kritische Single Point of Failure bleibt. Während andere Komponenten wie Webserver oder Load Balancer durch automatische Ausfallsicherungssysteme geschützt sind und bei Fehlern schnell aus dem Dienst genommen werden können, ist das Datenbanksystem derzeit noch auf manuelle Eingriffe angewiesen. Besonders problematisch sind zudem Teil-Ausfälle, bei denen ein automatisches Failover potenziell mehr Schaden anrichten könnte als ein geplanter manueller Neustart. Die Herausforderung besteht darin, die Datenbankgeräte durch stabilere Hardware, sorgfältige Überwachung und gesicherte Prozesse so ausfallsicher wie möglich zu machen.
Gleichzeitig soll die Häufigkeit von Ausfällen reduziert und ihre Dauer so kurz wie möglich gehalten werden. Dieses Vorgehen setzt Prioritäten auf die Vermeidung von Ausfallzeiten durch die Kombination von Hardware-Qualität und durchdachter Betriebspraxis. Aus technischer Sicht zeigt der Vorfall die Bedeutung, Hardware-Komponenten wie CPU, RAM und Speicherlaufwerke genau zu überwachen. Kleine Abweichungen in Temperatur oder Belastung können frühzeitig Hinweise auf potenzielle Fehlerquellen geben. Auch das Wissen um die genauen Auswirkungen eines Segfaults in Postgres und die Möglichkeit von Split-Brain-Szenarien kann wertvolle Erkenntnisse liefern, um zukünftige automatische Failover-Lösungen besser zu gestalten oder im Zweifelsfall manuelle Eingriffe zu priorisieren. Ebenfalls interessant ist die Wahl zwischen Consumer-Hardware mit hoher Leistung und Server-Hardware, die eher auf Stabilität und Langlebigkeit ausgelegt ist.
Der Wechsel von einem Intel Core i9 zu einem Xeon-Prozessor, sowie die Verdoppelung des ECC-RAM mit größerer Kapazität, zeigt hier eine klare strategische Ausrichtung auf verlässliche Komponenten, die weniger anfällig für plötzliche Ausfälle sind. Gesamt betrachtet illustriert der Vorfall auch die Grenzfälle, in denen technische Überwachungssysteme versagen oder nicht schnell genug reagieren können, wenn der Betreiber selbst nicht sofort am Arbeitsplatz verfügbar ist. Der Umgang mit Notfällen erfordert daher nicht nur technische Maßnahmen, sondern auch organisatorische und personelle Vorbereitungen, um Ausfälle effektiv zu minimieren. Healthchecks. io bleibt ein stark wachsender Dienst, der Kunden eine verlässliche Infrastruktur für ihre regelmäßigen Cron-Überwachungen bieten will. Die Erkenntnisse aus diesem Datenbankausfall fließen unmittelbar in zukünftige Verbesserungen ein, um den Dienst nicht nur stabiler, sondern auch insgesamt sicherer und robuster zu gestalten.
Der Betreiber setzt dabei auf einen pragmatischen Ansatz, der sowohl technische Qualitätssicherung als auch erfahrene manuelle Prozesse kombiniert. Zusammenfassend ist der Datenbankausfall vom 30. April 2025 ein Lehrstück für moderne IT-Infrastrukturen. Er zeigt, wie wichtig es ist, nicht ausschließlich auf automatisierte Systeme zu bauen, sondern proaktive Hardware-Monitoring-Strategien und eine sorgfältige Auswahl der eingesetzten Komponenten zu verfolgen. Zugleich unterstreicht er die Bedeutung einer flexiblen und verantwortungsbewussten Notfallreaktion, die menschliche Expertise mit technischer Präzision verbindet, um schnelle Wiederherstellung und minimalen Dienstunterbruch zu gewährleisten.
