#Hetzner

Wenn der Fehler beim Hosting-Anbieter liegt, hilft vor allem eines: ihn schnell zu erkennen und dann die Finger vom eigenen System zu lassen. Innerhalb von drei Wochen fielen bei uns zweimal Dokumentenarchiv, OpenProject und Fotoarchiv gleichzeitig aus, weil das interne Netz bei Hetzner gestört war, einmal für achtundsechzig Minuten, einmal für zwölf. Mein Netzwerk-Kniff, um die Verbindung schneller zurückzuholen, brachte nichts, also prüfen wir jetzt die Statusseite, pausieren das Scannen und warten. Zu wissen, dass man nichts tun kann, ist auch eine Diagnose, und sie spart die Stunde am falschen Ende.

Eine Störung ist nicht vorbei, nur weil der Anbieter sie für behoben erklärt, sie klingt oft noch eine Weile nach. Nach der Netzstörung bei Hetzner Anfang Oktober bekam unser Paperless-Archiv noch eine gute Dreiviertelstunde lang Fehlermeldungen, obwohl die Störung offiziell schon beendet war. Drei Belege landeten dabei im Ordner für Fehlversuche. Ich hatte ihn nur bis zum gemeldeten Ende geprüft und fand die drei erst knapp drei Wochen später bei der Nachkontrolle. Das Ende einer Störung steht im eigenen Protokoll, nicht auf der Statusseite.

Das Handy bekommt bei mir nicht denselben Zugangsschlüssel wie der Rechner, sondern einen eigenen. Als ich das iPhone als Fernzugang zu unserem Cloud-Arbeitsplatz bei Hetzner eingerichtet habe, bekam es einen eigenen Schlüssel. Genauso hat vorher schon der Arbeitsplatz selbst einen eigenen für seine dreizehn Server bekommen. Wenn das Handy auf Reisen verloren geht, lösche ich eine einzige Zeile, und alle anderen Geräte arbeiten weiter. Wer jedem Gerät einen eigenen Schlüssel gibt, muss im Ernstfall nur ein Schloss tauschen, nicht alle.

Wenn die Statusseite des Anbieters zur selben Zeit eine Störung meldet, ist er deshalb noch lange nicht schuld. Bei uns fielen an einem Morgen drei Dienste immer wieder aus, darunter unser zentraler Login Authentik. Auf der Statusseite von Hetzner stand gleichzeitig eine DNS-Störung. Unsere eigenen Protokolle zeigten aber eine ganz andere Ursache: Ein Zwischenspeicher von 64 Megabyte war nach fünf Monaten Laufzeit vollgelaufen. Seit wir ihn auf 512 Megabyte vergrößert haben, laufen die Dienste wieder. Ein Ausfall, der zeitgleich passiert, ist ein Verdacht und noch kein Beweis.

Wenn mehrere Programme gleichzeitig ausfallen und die Störung beim Rechenzentrum liegt, repariert man selbst gar nichts, man wartet und schützt die Arbeit, die gerade läuft. Bei uns standen an einem Vormittag Dokumentenarchiv, OpenProject und Fotoarchiv zugleich still, achtundsechzig Minuten lang, während die Datenbank dahinter die ganze Zeit gesund war. Die Statusseite von Hetzner meldete eine gestörte Netzverbindung zwischen unseren Servern. Ich habe nur die Anmeldung gebeten, das Scannen zu pausieren. Fallen mehrere Dinge zugleich aus, liegt der Fehler selten in ihnen, sondern in dem, was sie verbindet.

Wenn der Laptop auf Reisen gestohlen wird, passiert mit der Arbeit wenig, sofern der eigentliche Arbeitsplatz gar nicht im Laptop steckt. Vor meiner Reise nach Thailand habe ich meinen täglichen Arbeitsplatz auf einen gemieteten Server bei Hetzner gelegt, für rund sechzehn Euro im Monat, dazu eine Sicherung mit sieben Tagesständen, die sich per Klick zurückspielen lassen. Erreichbar ist er nur über unser eigenes VPN, aus dem offenen Internet sieht man ihn nicht. Ein Gerät, das man verlieren kann, sollte nur das Fenster sein, nicht der Tresor.

Wer alle Zugänge auf einen neuen Rechner umzieht, lernt vor allem, welche davon längst nicht mehr stimmen. Beim Umzug meines Arbeitsplatzes auf einen Cloud-Server bei Hetzner habe ich einen eigenen Schlüssel auf dreizehn Server verteilt, bei sieben alten Einträgen ging nichts: zwei antworteten nicht, bei vieren hatte sich die Kennung des Servers geändert, einer existierte gar nicht mehr. Erzwungen habe ich nichts, denn eine geänderte Kennung will erst geklärt werden. Ein Umzug ist die ehrlichste Inventur, die man umsonst bekommt.

Ein Ersatz-Arbeitsplatz in der Cloud braucht nicht strengere Regeln als der Rechner im Büro, sondern dieselben, solange derselbe Mensch davor sitzt. Ich plane gerade einen Linux-Rechner bei Hetzner für rund sechzehn Euro im Monat, der einspringt, falls mein Mac ausfällt oder gestohlen wird. Der erste Entwurf schottete ihn vom übrigen Betrieb komplett ab, bis mir auffiel, dass der Mac längst überall hinkommt. Streng eingesperrt wird nur, was unbeaufsichtigt läuft. Wie gut man einen Rechner absichert, hängt davon ab, wer ihn bedient, nicht davon, wo er steht.

Wie lange der Umzug eines Fotoarchivs auf den eigenen Server dauert, entscheidet nicht der Server, sondern die eigene Internetleitung. Unser Speicher bei Hetzner schreibt gut hundert Megabyte pro Sekunde, unsere DSL-Leitung schafft beim Hochladen aber nur 4,3. Für die knapp dreihundert Gigabyte meines privaten Archivs heißt das rund zwanzig Stunden reine Übertragung, also ein Wochenende statt einer Mittagspause. Wer so einen Umzug plant, misst zuerst den Upload und erst dann die Festplatte.

Eine Domain kann offline sein, obwohl der Server einwandfrei läuft. Bei einer unserer Domains zeigte der Delegationseintrag bei Hetzner auf drei Namensserver, die diese Domain gar nicht kannten, und jede Anfrage von außen lief ins Leere. Der Webserver war gesund, die Seite fertig ausgeliefert, nur fand kein Besucher den Weg dorthin. Aufgefallen ist es erst zwei Monate später, als ich alle Domains einzeln von außen durchprüfte. Ein gesunder Server sagt nichts darüber, ob jemand bei ihm ankommt.

Ein geplanter Ausfall steht nicht auf der Störungsseite, weil er dort gar nicht als Störung geführt wird, sondern unter angekündigter Wartung. Hetzner hatte die Arbeiten an einem Netzwerkverteiler im Rechenzentrum für eine Stunde angekündigt, samt Anweisung, die angehängten Speicher vorher abzutrennen. Die Mail lag ungelesen, und vier Minuten nach Beginn des Fensters standen unsere Seiten. Eine Ankündigung, die niemand liest, ist für den Betrieb dasselbe wie keine.

Eine Website kann monatelang offline sein, obwohl der Server einwandfrei läuft, wenn der Weg zu ihm abgeschnitten ist. Ende Juni habe ich bei Hetzner die Namensauflösung für fünf unserer Domains umgestellt und eine davon vergessen. Ab da war diese Website für jeden Besucher unerreichbar, während der Server fehlerfrei lief. Aufgefallen ist es erst nach gut zwei Monaten. Seitdem gleiche ich jede Sammel-Umstellung mit der vollständigen Liste ab und prüfe von außen, nicht vom Server aus. Wer nur von innen schaut, sieht immer ein gesundes Haus.

Wenn eine Website gar nicht mehr antwortet statt eine Fehlerseite zu zeigen, ist meist nicht das Programm kaputt, sondern etwas abgeschnitten. Bei uns standen an einem Dienstagmorgen alle Seiten still, der Server selbst war erreichbar, die Last lag bei vierzehn bei freiem Arbeitsspeicher und die Rechenleistung wartete zu siebzig Prozent auf die Platte. Der Speicher war ein Cloud-Volume bei Hetzner, das über das Rechenzentrumsnetz hängt, und genau dieses Netz war gerade in Wartung. Ein defektes Gerät meldet einen Fehler, ein abgeschnittenes schweigt.

Ein stärkerer Server hilft nicht, wenn der angebundene Speicher der Flaschenhals ist. Bei unserer Nextcloud habe ich erst gemessen, bevor ich über neue Hardware nachdachte: 8,4 Megabyte pro Sekunde beim Schreiben in den Objektspeicher, 67 beim Lesen, während das Netz selbst in unter einer Millisekunde antwortete. Die Maschine hatte nie Not, die Leitung dahinter schon. Bevor man aufrüstet, misst man, wo die Zeit wirklich verlorengeht.

Nach einer DNS-Änderung muss man in aller Regel keine zwei Tage warten, das ist ein Überbleibsel aus alten Zeiten. Als ich einen Bestätigungseintrag für eine Domain gesetzt habe, hatten die drei ausgelagerten Nameserver ihn nach rund zwanzig Sekunden. Entscheidend ist die Gültigkeitsdauer, die man selbst vorgibt, nicht ein pauschaler Erfahrungswert aus dem Internet. Wer die eigenen Einstellungen kennt, muss nicht auf eine Faustregel hoffen.

Wenn eine Übertragung mittendrin abbricht, bleibt eine unbrauchbare Datei liegen, die von außen aussieht wie eine fertige Sicherung. Bei uns scheiterte der nächtliche Offsite-Lauf beim Schreiben eines 3,4 Gigabyte großen Archivs auf die Storage Box am Arbeitsspeicher, und danach lag die Datei dort mit falscher Prüfsumme und einem Änderungsdatum aus dem Jahr 1970. Seitdem vergleicht das Skript nach jedem Lauf die Prüfsummen auf dem Ziel und meldet sich, wenn eine nicht passt. Eine halbe Kopie ist gefährlicher als keine, weil sie den Platz der ganzen einnimmt.

Auf den neuen Server muss nur, was sich nicht wiederherstellen lässt. Als wir unser Dokumentenarchiv Paperless auf eine eigene Maschine umgezogen haben, sind die zwölf Gigabyte Originaldateien in gut zwei Minuten mitgegangen. Den dreiundzwanzig Gigabyte großen Suchindex habe ich bewusst zurückgelassen, weil die neue Version ihn ohnehin selbst neu aufbaut. Ein Umzug wird leicht, wenn man vorher trennt, was Original ist und was nur Abbild.

Alles auf den einen großen Server zu ziehen wäre billiger gewesen, und trotzdem bleiben wir verteilt. Wir haben bei Hetzner ein gebrauchtes Blech mit 256 GB Arbeitsspeicher für hundertneun Euro im Monat gemietet, ein Vielfaches unserer kleinen Cloud-Maschine fürs gleiche Geld. Aber ein einzelner Rechner ist ein einzelner Ausfallpunkt, fällt er, fällt alles. Also bleibt der Zugang zur Außenwelt auf der Cloud, das Blech trägt nur die schweren Lasten. Der günstigste Server wird teuer, wenn an ihm allein der ganze Betrieb hängt.

Ob eine Firewall wirklich dicht ist, prüft man von einem fremden Rechner aus, nicht aus dem eigenen Netz. Beim Absichern unseres neuen Hetzner-Servers zeigte mein Port-Scan hinter dem VPN einen offenen Port 80, der von außen gar nicht offen war. Erst die Prüfung von einem neutralen Host ergab das echte Bild: öffentlich erreichbar ist nur noch der Fernzugang. Eine Tür testet man von der Seite, von der ein Einbrecher kommen würde.

Ein überlasteter Server braucht nicht automatisch mehr Rechenleistung, oft fehlt nur Arbeitsspeicher. Unser cpx42 bei Hetzner lahmte, doch die CPU lag zu 62 Prozent im Leerlauf, während 4,3 Gigabyte in den langsamen Swap ausgelagert waren. Ein größerer Cloud-Server hätte teure Rechenkerne mitbezahlt, die wir nie gebraucht hätten, also nahmen wir stattdessen eine gebrauchte Maschine mit 256 Gigabyte RAM. Wer erst nachmisst, welcher Teil wirklich klemmt, kauft nicht den falschen Motor für ein Getriebeproblem.

Bevor man einen größeren Server mietet, sollte man den vorhandenen entlasten. Unserem Server ging der Arbeitsspeicher aus, und die nächstgrößere Maschine bei Hetzner hätte statt sechsundzwanzig gut hundert Euro im Monat gekostet, weil der alte Bestandspreis beim Wechsel unwiderruflich verfällt. Stattdessen habe ich zwei Diensten überflüssige Arbeitsprozesse abgedreht und den Reservespeicher vergrößert: sechs Gigabyte wieder frei, Kosten null Euro. Die günstigste Kapazität ist die, die man schon bezahlt und nur schlecht nutzt.

Ein Erpressungstrojaner kann unsere Datensicherung nicht verschlüsseln, weil sich die Kopie selbst gegen jeden Zugriff sperrt, auch gegen meinen. Unsere Belege liegen zusätzlich im Hetzner Object Storage mit echtem Object-Lock: 14.138 Dokumente, zehn Jahre unveränderbar, unlöschbar selbst mit gestohlenen Administrator-Rechten. Als sich ein lokales Original änderte, verweigerte der Speicher die Überschreibung, genau wie er soll. Ein Backup, das ich selbst noch löschen kann, kann auch ein Angreifer löschen.

Meine eigenen Belege nicht löschen zu können, ist kein Mangel, sondern der ganze Sinn eines revisionssicheren Archivs. Unsere Dokumente wandern jede Nacht in einen Hetzner Object Storage mit echtem Object-Lock, Modus Compliance und zehn Jahren Aufbewahrung, aktuell 14.138 Objekte, die auch ich als Administrator oder ein Angreifer mit gestohlenen Zugängen nicht mehr überschreiben kann. Als der Lauf Fehler meldete, weil sich lokale Originale geändert hatten, war das kein Defekt, sondern die Sperre, die ihre Arbeit tat. Ein Archiv, das der Besitzer selbst überschreiben kann, kann auch ein Angreifer überschreiben.

Die ganze Cloud lag lahm, weil eine einzige Festplatte zu hundert Prozent voll war. Docker konnte für die Gesundheitsprüfungen keinen Prozess mehr starten, also warf der vorgeschaltete Router alle Container als ungesund aus dem Verkehr, und jede Seite die dort hing gab nur noch einen Fehler zurück. Mein erster Verdacht fiel auf die Namensauflösung, dabei genügte ein Blick auf den freien Speicher. Elf Gigabyte Zwischenspeicher gelöscht, und die Dienste kamen von selbst zurück. Das Kleinste, das man übersieht, legt das Größte lahm.

Fällt der eigene Server aus, bleibt die Website trotzdem erreichbar, wenn man die Namensauflösung vorher entkoppelt hat. Bei uns liegt der Master für alle Domains auf einer Maschine bei Hetzner, aber drei kostenlose externe Nameserver halten je eine Kopie und liefern noch vierzehn Tage weiter aus, falls der Master schweigt. Genau das habe ich diese Woche fertig gemacht, kein einzelner Server entscheidet mehr darüber, ob wir im Netz auffindbar sind. Ein Dienst, der den Ausfall eines einzelnen Teils übersteht, ist mehr wert als einer, der nur im Normalfall läuft.

Auf einem laufenden Produktivsystem fragt man, wenn man nicht weiterkommt, statt zu raten. Als ich kürzlich Matrix als Chat-Dienst neben den rund zwanzig Containern unserer Hetzner-Cloud einrichten wollte, war an einer Stelle unklar, wie sich die Anbindung sauber ins bestehende Muster fügt. Früher hätte ich eine plausible Variante einfach ausprobiert; heute halte ich an und kläre die Frage, bevor ich an Mail, Passwörter und Dokumente rühre, an denen der ganze Betrieb hängt. Ein geratener Eingriff am Produktivsystem ist billig im Moment und teuer in der Woche danach.

Angreifer, die fuer jeden Login-Versuch die Adresse wechseln, sperrt man nicht einzeln, sondern als ganzes Netz. Unser Mailserver Stalwart bannt eine Adresse erst nach hundert Fehlversuchen, doch die Probierversuche kamen aus einem ganzen Adressblock, jede Adresse genau einmal, alle dreissig Sekunden eine neue. So lief der Zaehler nie voll. Erst die Sperre des kompletten Blocks in der Hetzner-Firewall brachte Ruhe. Wer nur das einzelne Tuerschloss zaehlt, uebersieht, dass der Angreifer die ganze Strasse hat.

Sehr. Wir haben neun Server auf vier verdichtet und die Datenhaltung auf einen zentralen PostgreSQL-Server zusammengeführt. Die Kosten sind von rund einundachtzig auf sechsundvierzig Euro im Monat gesunken, und statt fünf Backup-Skripten gibt es eins. Weniger Teile heißt vor allem weniger, das nachts schweigend kaputtgehen kann.