55 Stunden tot, gemerkt hat es nur das Backup

Am 26. August 2026 um 00:32 hat mein Server littleBrother neu gestartet. Routine-Reboot, nichts Besonderes. Die Container kamen der Reihe nach zurück. Einer nicht.

DocuSeal. Die Plattform, über die bei mir Verträge unterschrieben werden. Sie blieb bis zum 28. August um 09:20 tot, also 55 Stunden. Das Monitoring hat den Ausfall ab der ersten Minute erfasst. Aufgefallen ist er mir über die dritte fehlgeschlagene Backup-Mail in Folge.

Warum hat das Monitoring den Ausfall nicht gemeldet?

Es hat gemeldet. Der Alarm ging nur im normalen Mail-Rauschen unter, weil kein Mensch definiert hatte, welche Meldung wen wann erreichen muss und was passiert, wenn dieser Jemand nicht reagiert.

Monitoring beantwortet eine einzige Frage: läuft der Dienst. Ob jemand die Antwort liest, ist eine zweite Frage, und die beantwortet keine Software. Zwischen beiden liegt die Eskalationskette, und die ist bei den meisten Firmen ein leeres Feld.

Genau das ist der Satz, den ich in Wartungsgesprächen am häufigsten höre: "Wir haben doch Monitoring." Habt ihr. Es zeigt euch grüne und rote Punkte. Wer draufschaut, steht nirgends.

Was hat den Ausfall technisch ausgelöst?

Eine fehlende Zeile in der docker-compose.yml. Der Eintrag restart: war für DocuSeal nicht gesetzt.

Docker verhält sich in diesem Fall nach Vorgabe: keine Restart-Policy bedeutet kein automatischer Neustart. Der Container ist beim Reboot gestorben und blieb liegen. Alle anderen Dienste auf der Maschine hatten ihre Policy und kamen deshalb zurück. Der Unterschied zwischen einem funktionierenden System und einem toten Dienst waren zwei Wörter: unless-stopped.

Der Fix hat 30 Sekunden gedauert. Die Suche danach war das Teure.

Warum hat ausgerechnet das Backup den Fehler gefunden?

Weil das Backup der einzige Prozess ist, der den Dienst jede Nacht wirklich benutzt. pg_dump wollte sich mit der Datenbank verbinden, der Container war weg, das Backup schlug fehl und schickte eine Mail.

Ein Monitoring-Check fragt höflich an, ob eine Adresse antwortet. Ein Backup öffnet die Tür, greift rein und holt Daten raus. Wenn dabei etwas fehlt, merkt es das sofort. Deshalb ist eine fehlgeschlagene Backup-Mail oft das ehrlichste Signal im ganzen Stack.

Bitter daran: Es brauchte drei Fehlversuche in Folge, bis ich hingeschaut habe. Zwei Mails hatte ich vorher weggeklickt.

Was war an 55 Stunden Ausfall teuer?

Der Serverbetrieb selbst hat nichts gekostet. Teuer waren die Verträge, die in diesen 55 Stunden nicht unterschrieben werden konnten, und die drei Nächte, in denen es kein Backup dieses Dienstes gab.

Nach dem Neustart habe ich den Datenbestand geprüft: 13 Einreichungen, 10 Templates, 97 Dateien, alles intakt. Kein Verlust. Das war Glück, keine Vorsorge. Ein Container, der mitten in einem Schreibvorgang stirbt, kann auch anders ausgehen.

Rechne das mal für dich durch. Wie viele Tage kann deine Angebotsstrecke, dein Ticketsystem oder dein Zeiterfassungstool ausfallen, bevor es jemand extern merkt? Und ist "extern merkt" wirklich dein Frühwarnsystem?

Wie kommt so eine fehlende Zeile überhaupt zustande?

Konfigurations-Drift. Der Live-Zustand auf dem Server entfernt sich Update für Update von dem, was in den versionierten Compose-Dateien steht.

Bei mir liegt die Konfiguration in einem Repository namens VPS-configs. Der Abgleich läuft von Hand. Jedes Update, jeder schnelle Fix direkt auf der Maschine, jede Anpassung um 23 Uhr erhöht die Differenz zwischen Repo und Realität. Nach ein paar Monaten weiß niemand mehr, welche Version die Wahrheit ist.

Das Fiese: Ein Dienst mit fehlender Restart-Policy läuft monatelang völlig unauffällig. Er verrät seinen Fehler erst beim Reboot. Und Reboots passieren nachts um 00:32.

Was lief im selben Wartungslauf noch auf?

Ausgelöst hat den ganzen Durchgang eine Update-Benachrichtigung von What's Up Docker. Drei Sachen kamen dabei hoch, die es wert sind, erwähnt zu werden.

• Ghost 6.57.1 auf 6.60.0. Enthält drei Sicherheitspatches mittlerer Schwere vom 20. August. Die Datenbank-Migrationen liefen sauber durch.
• Traefik v3.7.10. Steckt eine kritische Lücke drin: Die Authentifizierung über digestAuth lässt sich umgehen. In meiner Konfiguration nicht ausnutzbar, weil ich diese Middleware gar nicht einsetze. Trotzdem gepatcht.
• Cal.com 6.1.16 auf 6.2.0. Prisma fährt beim Boot Migrationen, die nur in eine Richtung laufen. Kein Rückweg. Nebeneffekt: Die Video-Konferenz-Apps werden dabei deaktiviert. Ein Cronjob schaltet sie danach automatisch wieder ein.

Diese Cal.com-Eigenheit habe ich vor Monaten einmal manuell geradegezogen und dann automatisiert. Seitdem kostet sie null Minuten pro Update. Genau so hätte die Restart-Policy auch aussehen sollen.

Was kannst du am Montag in deiner Firma nachsehen?

Sechs Punkte, für die du keine IT-Ausbildung brauchst. Frag die Leute, die deine Systeme betreuen, und lass dir die Antworten zeigen statt erzählen.

1. Nenn mir den Namen. Frag, welcher Mensch die Monitoring-Alarme liest. Wenn die Antwort eine Verteileradresse ist, liest sie niemand.
2. Urlaubsfall. Was passiert mit einem Alarm um 3 Uhr nachts, wenn diese Person zwei Wochen weg ist? Wenn es keine zweite Stufe gibt, hast du keine Eskalation.
3. Backup-Mails prüfen. Kommen sie nur bei Fehlern? Dann merkt niemand, wenn das Backup selbst stirbt. Erfolgsmeldungen gehören ebenfalls in den Posteingang.
4. Zehn-Minuten-Test. Nimm einen wichtigen internen Dienst, schalte ihn kontrolliert ab und stoppe die Zeit, bis ein Mensch reagiert. Bei mir wären es 55 Stunden gewesen.
5. Kontrollierter Reboot. Starte jeden Server einmal geplant neu, an einem Dienstagvormittag um 10 Uhr. Zähl, was nicht zurückkommt. Diese Liste ist dein Risiko.
6. Repo gegen Realität. Lass dir zeigen, ob die laufende Konfiguration mit der versionierten übereinstimmt. Wenn niemand das beantworten kann, ist die Antwort nein.

Punkt 5 ist der unbequemste und der mit dem größten Ertrag. Ein Reboot am Dienstagvormittag deckt dieselben Fehler auf wie ein Reboot am Sonntag um 00:32. Nur sitzt am Dienstag jemand davor.