Ich betreibe meinen eigenen Mailserver. Und ich hatte über Monate das Gefühl, dass die Sache alle halbe Jahr auseinanderfliegt — immer nach einem Update.
Für diesen Artikel habe ich zum ersten Mal nachgesehen, statt mich zu erinnern. Das Ergebnis war unangenehm: Kein einziger meiner Ausfälle ging auf ein Update der Mailserver-Software zurück. Beide Male lag es eine Ebene tiefer.
Ausfall eins: sieben Tage
Ende Mai, nach einem Kernel-Update, hat sich die Container-Software beim Neustart anders entschieden als vorher. Sie schwenkte auf eine neue Speichermethode um — und sah damit keinen einzigen der alten Container mehr. Nicht kaputt, nicht gelöscht. Nur nicht mehr da, wo sie suchte.
docker ps zeigte eine leere Liste. Das ist ein sehr stiller Moment.
Gerettet hat mich ein Backup, das nachts auf mein NAS läuft. 15 Gigabyte zurückgeholt, dazu eine Differenz von ein paar Tagen. Zwei Mails, die dazwischen ankamen, hatte mein iPhone noch im Zwischenspeicher.
Am Ende: keine einzige Mail verloren, rund acht Stunden Arbeit.
Was mich daran bis heute wurmt: Das Backup vom letzten Tag vor dem Crash wurde absichtlich übersprungen, weil das System einen ausstehenden Neustart meldete. Genau das Backup hätte alles abgekürzt.
Ausfall zwei: zwölf Stunden
Ende Juli dasselbe Muster, andere Ausprägung. Die automatischen Sicherheitsupdates hatten einen neuen Kernel installiert und um sechs Uhr morgens durchgestartet. Der Mail-Stack kam nicht sauber hoch.
Das Fehlerbild war eine schöne Kette:
- Der Mail-Zustelldienst hing beim Start in „warte auf DNS”.
- Er wartete zu Recht — der interne Namensauflöser war nicht erreichbar.
- Der war nicht erreichbar, weil eine Netzwerkregel nach dem Neustart fehlte, die den Containern den Weg nach draußen freigibt.
- Und obendrauf galt der Port für den Mailabruf als belegt, obwohl kein einziger Prozess darauf lauschte.
Punkt vier hat mich am längsten gekostet. Da lag eine verwaiste Verbindung vom abgestürzten Dienst, die niemandem mehr gehörte. Werkzeuge, die zeigen „wer hört auf welchem Port”, zeigten nichts an — der Port war trotzdem dicht. Ein Neustart der Container-Software half nicht. Erst das gezielte Abräumen dieser einen alten Verbindung.
Zwischendurch habe ich mich selbst ausgesperrt: Beim Testen der Anmeldung hat der Einbruchschutz meine eigene Adresse gesperrt.
Wie ich es überhaupt gemerkt habe
Beide Male gleich: Apple Mail auf dem Mac hat keine Verbindung mehr aufgebaut.
Nicht meine Überwachung. Nicht eine Push-Nachricht. Ein Mailprogramm, das leicht anders aussah als sonst. Auf dem iPhone lief währenddessen alles weiter, weil das noch aus dem Zwischenspeicher lebte.
Das ist der Satz, den ich mir aus dem Juli mitgenommen habe: Ich hatte Verfügbarkeit überwacht, nicht Funktion. Alle Container meldeten „gesund”. Die Weboberfläche antwortete. Eingehende Mail kam an. Nur abrufen konnte ich sie nicht.
Halbe Funktion ist schlimmer als Totalausfall. Ein toter Server erzeugt sofort Alarm. Ein Server, der nur eine Sache nicht mehr kann, erzeugt gar nichts.
Was ich danach gebaut habe
Ein Skript, das ein Update nicht einfach durchwinkt, sondern absichert. Der Ablauf:
- Gibt es überhaupt ein Update? Wenn nein, sofort raus.
- Datenbank sichern. Ist die Sicherung leer, bricht alles ab. Ein Backup, das man nicht prüft, ist kein Backup.
- Wartungsflag setzen, damit die Überwachung in den nächsten Minuten nicht Alarm schlägt.
- Neue Images vorher herunterladen — das ist der lange Teil und kostet noch keine Ausfallzeit.
- Update einspielen.
- Die Netzwerkregel wiederherstellen, die im Juli gefehlt hat.
- Wenn der Namensauflöser hängt: gezielt neu starten.
- Nachsehen, ob wirklich alles läuft. Bis zu 90 Sekunden Geduld.
- Wartungsflag weg — auch dann, wenn vorher etwas abgebrochen ist.
- Ergebnis aufs Handy.
Schritt sechs und sieben sind direkt aus dem Juli-Ausfall entstanden. Beides Handgriffe, die ich damals nachts im Terminal gemacht habe.
Und jetzt der Teil, der mich beim Nachrechnen überrascht hat
Ich dachte, so ein Lauf dauert zwanzig Minuten. Steht so in meinen Notizen.
Zwei gemessene Läufe sagen etwas anderes:
| Datum | Dauer | Ergebnis |
|---|---|---|
| 1. August | 4:28 | Update durch, 52 Container gesund |
| 20. August | 4:35 | Update durch, 52 Container gesund |
Viereinhalb Minuten. Die zwanzig Minuten in meinen Unterlagen waren geschätzt und nie nachgemessen.
Wichtiger ist aber, was in diesen viereinhalb Minuten steht. Am 1. August:
09:24:23 Unbound unhealthy -> Neustart (reprime).Und am 20. August:
18:37:43 Unbound unhealthy -> Neustart (reprime).Zweimal von zwei Updates. Genau der Namensauflöser, der im Juli die ganze Kette umgeworfen hat, kippt bei jedem Update weg. Das ist kein Zufall, das ist systematisch.
Nur merke ich es nicht mehr. Es steht vierzig Sekunden lang im Protokoll, dann läuft es weiter. Der Fehler, der mich zwölf Stunden gekostet hat, ist zu einer Zeile geworden.
Das ist für mich die eigentliche Definition davon, dass Automatisierung funktioniert: nicht, dass nichts mehr schiefgeht. Sondern dass dasselbe Problem beim zweiten Mal keine Nacht mehr kostet.
Warum der automatische Neustart trotzdem anbleibt
Beide Totalausfälle wurden von einem automatischen Update ausgelöst, das nachts um sechs den Rechner durchstartet. Ich könnte das abschalten und hätte Ruhe.
Ich lasse es an.
Ein ungepatchter Kernel ist heute ein anderes Risiko als vor fünf Jahren. Es werden nicht mehr einzelne Server von Hand durchprobiert — es wird automatisiert im großen Stil gescannt, und zwischen „Lücke ist öffentlich” und „jemand klopft an” liegen inzwischen Stunden statt Wochen.
Dagegen ist ein überraschender Neustart um sechs Uhr morgens ein Preis, den ich zahle. Er darf mich nur nicht mehr zwölf Stunden kosten. Genau dafür ist das Skript da.
Der ehrliche Schluss
Ich bin der einzige Nutzer dieses Servers. Zwölf Stunden ohne Mailabruf haben mich also nichts gekostet außer Nerven. Niemand hat sich beschwert, weil es niemanden gibt, der sich beschweren könnte.
Trotzdem hat mich dieser eine Abend mehr gestört als jeder andere Serverkram in diesem Jahr — weil ich das Gefühl hatte, mein eigenes System nicht zu verstehen.
Genau das war der Fehler. Ich habe die Software verdächtigt, die am lautesten war, statt nachzusehen, was tatsächlich passiert ist. Es lag nie an der Mail. Es lag jedes Mal am Unterbau: einmal an der Container-Software, einmal am Kernel.
Wenn du das Gefühl hast, irgendetwas fällt „alle paar Monate” aus — sieh nach, statt dich zu erinnern. Die Erinnerung beschuldigt zuverlässig den Falschen.
