4 Stunden Ausfall, ein Failover-System und radikale Transparenz4 Stunden Ausfall, ein Failover-System und radikale Transparenz

4 Stunden Ausfall, ein Failover-System und radikale Transparenz

In der letzten Nacht war lake8.dev etwa 5 Stunden offline.

Es war kein Angriff. Es war kein Fehler. Es war eine elektrische Überspannung, die den Leitungsschutzschalter auslöste - eine der Dinge, die nachts passieren, die den Strom abschalten, während man schläft und man nichts tun kann, bis man aufwacht.

Wir schreiben dies, weil radikale Transparenz eines unserer Grundwerte ist. Die Verkehrsdaten von lake8.dev sind öffentlich auf stats.lake8.dev. Der Ausfall ist in den Protokollen sichtbar. Es macht keinen Sinn, nicht darüber zu sprechen.


Was ist passiert

Nachtsüber brannte eine elektrische Überspannung durch — der Leitungsschutzschalter löste aus. Die Infrastruktur von lake8.dev läuft auf physischer Hardware in San Pietro in Casale - einem Raspberry Pi 4B, einem Orange Pi Zero 3, einem Orange Pi Lite. Ohne Strom schaltet sich alles ab.

Wir haben eine Eaton 5E900UD-USV installiert, aber bei 5 Stunden ohne Strom reicht die Batterie nicht aus. Die Webseite blieb bis zum Morgen offline, als wir den ausgelösten Leitungsschutzschalter fanden, den Strom wiederherstellten und die Systeme automatisch neu starteten.

Keine Daten verloren. Kein Schaden an der Infrastruktur. Nur 4 Stunden Unerreichbarkeit.


Was wir heute Morgen gemacht haben

Sobald wir aufwachten, implementierten wir ein automatisches DNS-Failover-System.

So funktioniert es:

Ein Monitor läuft auf dem Orange Pi Zero 3 jede 60 Sekunden. Er testet die Konnektivität nach außen. Wenn er feststellt, dass Eolo (unser ISP) nicht erreichbar ist, führt er automatisch diese Sequenz aus:

Keine Eolo-Konnektivität
Automatischer Wechsel zur 4G-Backupverbindung (über USB-Ethernet)
GoDaddy-API-Aufruf → DNS von lake8.dev auf GitHub Pages geändert
lake8.dev → Wartungsseite HTTPS
Wenn Eolo zurückkommt → DNS wiederhergestellt → Website online

Die Wartungsseite ist bereits live, mehrsprachig (IT/EN/DE/ES), über HTTPS mit einem gültigen Zertifikat zugänglich.

⚠️ Errata corrige — 12.07.2026
Eine frühere Version dieses Artikels gab die Failover-Zeit als ~90 Sekunden und die Wiederherstellungszeit als ~60 Sekunden an. Diese Werte bezogen sich auf den technischen DNS-Wechsel, nicht auf die von Besuchern wahrgenommene Zeit. Die TTL-Propagierung (600s, ~10 Minuten) fehlte. Die korrekten Zeiten sind unten angegeben.

Failover-Zeit im Test verifiziert: ~90 Sekunden für den DNS-Wechsel + ~10 Minuten TTL-Propagierung (600s). Gesamtzeit bis Besucher die Wartungsseite sehen: ~12 Minuten.

Wiederherstellungszeit im Test verifiziert: ~60 Sekunden für den DNS-Wechsel + ~10 Minuten TTL-Propagierung (600s). Gesamtzeit bis Besucher die Website wieder online sehen: ~12 Minuten.


Warum wir das erzählen

Weil lake8.dev der Null-Kunde seiner eigenen Produkte und Philosophien ist.

Einer der Säulen von Lagotto BI und dem Ökosystem lake8.dev ist radikale Transparenz - reale, öffentliche, überprüfbare Daten, ohne Filter. Wenn wir einen nächtlichen Ausfall verbergen, wenden wir diese Philosophie nur an, wenn es bequem ist.

Der Ausfall ist passiert. Das Failover-System existierte nicht. Jetzt existiert es. Die Daten auf stats.lake8.dev zeigen die Verkehrslücken. Alles überprüfbar.


Was bleibt zu tun

Das DNS-Failover-System ist aktiv und getestet. Aber vollständige Resilienz erfordert noch:

  • NUT-Konfiguration — kontrollierte Abschaltung, wenn die USV-Batterie unter kritischen Schwellenwert fällt
  • Watchdog-Skript — automatische Erkennung und Rücksetzung im Falle eines Systemstillstands
  • Vollständige Testsequenz — End-to-End-Stromausfallsimulation

Wir werden sie in den kommenden Wochen implementieren. Wenn sie fertig sind, werden wir darüber schreiben.

Quellen

Autor: Giantommaso Fogli
Veröffentlichungsdatum: 2026-07-11

Rechte und Quellenangaben

Bilder, Logos und Fotografien sind Eigentum ihrer jeweiligen Inhaber. Verwendet für Kommentarzwecke.


← Back to blog