VPS migrieren ohne Ausfallzeit: Umschaltung, DNS und Rollback

Die Kopie ist der leichte Teil — was die Ausfallzeit wirklich verursacht

Fragen Sie jemanden, wie lange seine Migration dauern wird, und die Antwort ist eine Schätzung der Übertragung. Zweihundert Gigabyte über eine Gigabit-Leitung, sagen wir vierzig Minuten, plus eine Stunde Puffer. Diese Zahl stimmt meistens – und fast nie ist sie die Zahl, auf die es ankommt, denn die Übertragung läuft, während der alte Server noch immer Anfragen beantwortet. Niemand ist während der Kopie down. Man ist down in dem Intervall zwischen die neue Maschine ist korrekt und das Internet stimmt dem zu, und wie lang dieses Intervall ist, bestimmen Caches, die Sie nicht kontrollieren.

Vier Fehlerarten sind für die meisten echten Migrationsausfälle verantwortlich, und keine davon ist Bandbreite. Ein DNS-Eintrag, dessen Time-to-Live beim Ändern noch einen ganzen Tag betrug, sodass ein beachtlicher Teil der Welt weiterhin eine Maschine anspricht, die Sie bereits abgeschaltet haben. Eine Datenbank, die nach dem Dump noch Schreibzugriffe angenommen hat, sodass der neue Host sein Leben mit einer still veralteten Kopie beginnt und Sie erst durch eine Kundenbeschwerde entdecken, welche zwanzig Minuten fehlen. Ein TLS-Zertifikat samt ACME-Account-Schlüssel, das nur auf der alten Festplatte existierte, sodass der neue Host jedem Browser einen Namens-Mismatch präsentiert. Und eine ausgehende Integration — ein Zahlungsdienstleister, eine SFTP-Ablage einer Bank, eine Partner-API, eine Datenbank bei einem Drittanbieter —, die per IP-Adresse freigegeben war und still und leise versagt — an einer Stelle, die von der auslösenden Änderung denkbar weit entfernt liegt.

Es lohnt sich, bei der Phrase, die alle benutzen, unverblümt zu sein. „Zero-Downtime-Migration“ bedeutet fast immer ein paar Sekunden abgelehnter Verbindungen, die kein Mensch bemerkt hat, und das ist ein durchaus gutes Ziel. Wirklich null erfordert, dass beide Maschinen gleichzeitig korrekt bedienen, was wiederum eine Anwendung erfordert, die es verträgt, zwei Maschinen zu sein: kein lokaler Sitzungszustand, kein lokales Upload-Verzeichnis, das nur eine Seite besitzt, und eine Datenbank, die entweder repliziert oder komplett woanders lebt. Die meisten selbst gehosteten Stacks erreichen diese Messlatte nicht, und der ehrliche Plan ist eine kurze, kontrollierte, geprobte Schreibsperre statt eines Architekturprojekts, das Sie gar nicht starten wollten.

Die Form einer guten Migration ist also nicht raffiniert. Bauen Sie die neue Maschine früh und beweisen Sie, dass sie funktioniert, während die alte die Last trägt. Verkleinern Sie den unumkehrbaren Teil auf ein paar Minuten skriptgesteuerter Befehle. Ändern Sie jeweils nur eine Sache. Und behalten Sie die Möglichkeit zurückzugehen — mit einem Datum, ab dem Sie aufhören, dafür zu bezahlen.

Inventar: die Teile eines Servers, die nicht in Ihrem Repository stehen

Ihr Deployment-Repository beschreibt die Anwendung. Es beschreibt nicht die Maschine. Irgendwo zwischen dem ersten apt install und heute sammelt ein Server eine Schicht an, die keine Versionsverwaltung je zu Gesicht bekommen hat: von Hand installierte Pakete, die ein einzelnes Problem beheben sollten, eine systemd-Unit, die jemand in Eile geschrieben hat, ein Cron-Job unter einem Dienstkonto, Firewall-Regeln, sysctl-Tuning, eine Locale, eine Zeitzone, eine Swap-Datei, TLS-Zertifikate, SSH-Host-Keys, Datenbankrollen und -berechtigungen sowie ein Medienverzeichnis, das genau deshalb nicht im Repository steht, weil die Nutzer es dort abgelegt haben. Migrieren bedeutet, diese Schicht bewusst zu reproduzieren, und der einzige Weg, das bewusst zu tun, ist, sie vorher aufzuschreiben.

Fünf Befehle erfassen das meiste davon. dpkg --get-selections unter Debian und Ubuntu, oder dnf repoquery --userinstalled unter Rocky und Alma, liefert Ihnen die Paketmenge. systemctl list-unit-files --state=enabled liefert Ihnen alles, was für den Start beim Booten konfiguriert ist — eine bessere Frage als „was läuft gerade“, weil sie auch das einschließt, was gerade abgestürzt ist. crontab -l -u für jedes Konto in /etc/passwd, dazu der Inhalt von /etc/cron.d und jede .timer-Unit, liefert Ihnen die geplanten Aufgaben. nft list ruleset oder ufw status numbered liefert Ihnen die Firewall. Und ss -tulpn liefert Ihnen, was tatsächlich lauscht — so entdecken Sie den Dienst, von dem Sie vergessen hatten, dass es ihn gibt. Schreiben Sie alle fünf in Dateien und kopieren Sie diese von der Maschine herunter statt auf sie.

Dann gibt es noch das Inventar, das niemand aufschreibt und das einen Wochen später beißt: alles, überall, was Ihrer aktuellen IP-Adresse vertraut. Zahlungsgateways mit IP-Allowlists. Eine verwaltete Datenbank bei einem anderen Anbieter, deren Zugriffsregeln die alte Adresse nennen. Ein SMTP-Relay, das sich per Netzwerk authentifiziert. Ein Monitoring-Dienst, ein Webhook-Versender, der nur an bekannte Adressen postet, die Firewall eines Kollegen. Durchsuchen Sie Ihre eigene Konfiguration und Dokumentation mit grep nach der alten Adresse, und prüfen Sie dann die Verwaltungsoberfläche jedes Drittanbieter-Dienstes, für den Sie bezahlen. Diese brechen nach der Umschaltung, asynchron, in dem Moment, in dem die Integration das nächste Mal läuft — weshalb sie so oft als „irgendetwas anderes ist zur gleichen Zeit schiefgelaufen“ diagnostiziert werden.

Erfassen Sie schließlich die DNS-Zone selbst. Exportieren Sie sie, oder notieren Sie mindestens jeden Eintragstyp, Wert und TTL, denn eine Migration ist genau der Moment, in dem jemand einen Eintrag bemerkt, der seit zwei Jahren falsch ist, und ihn hilfsbereit mitten in allem anderen korrigiert.

Senken Sie zuerst den DNS-TTL — und verstehen Sie, warum das Tage vorher geschehen muss

Ein rekursiver Resolver cacht eine Antwort für die Time-to-Live, die ihm mitgeteilt wurde, und ist in keiner Weise verpflichtet, vor deren Ablauf erneut zu fragen. Das hat eine Konsequenz, die fast jeden beim ersten Mal stolpern lässt: Den TTL eines Eintrags von 86400 auf 300 zu senken, bewirkt rein gar nichts bei einem Resolver, der die alte Antwort vor zehn Minuten gecacht hat. Dieser Resolver hält die tageslange Antwort noch weitere dreiundzwanzig Stunden und fünfzig Minuten und erfährt erst dann von Ihrem neuen Fünf-Minuten-TTL. Der niedrige TTL muss deshalb mindestens einen vollen alten TTL im Voraus veröffentlicht werden, bevor Sie irgendetwas verschieben wollen. Liegen Ihre Einträge auf einem Ein-Tages-TTL, findet die erste Aktion der Migration zwei Tage vor der Umschaltung statt, und es ist eine Änderung in einer einzigen Zeile.

Tun Sie das für jeden Eintrag, der auf die Maschine zeigt, nicht nur für den einen, an den Sie gerade denken. Der A-Eintrag und der AAAA-Eintrag — eine IPv6-Adresse, die weiter auf den alten Host zeigt, ist ein herrlich verwirrender Bug, denn Dual-Stack-Clients bevorzugen sie stillschweigend, und nur ein Teil Ihrer Nutzer wird betroffen sein. Die MX-Einträge. Jedes CNAME davor, wobei zu bedenken ist, dass ein Client, der einer Kette folgt, dem TTL jedes einzelnen Glieds darin unterliegt, sodass ein Fünf-Minuten-A-Eintrag hinter einem tageslangen CNAME effektiv immer noch einen Tag dauert. Und falls Sie außerdem den DNS-Anbieter wechseln, tun Sie das nicht in derselben Woche: Nameserver-Delegation und Glue Records werden von der übergeordneten Zone nach ihrem eigenen Zeitplan gecacht, und wenn Sie beide Änderungen kombinieren, wissen Sie später nicht, welche davon etwas kaputtgemacht hat, wenn etwas kaputtgeht.

Verifizieren Sie, statt anzunehmen. dig +noall +answer example.com A zeigt Ihnen, was ein Resolver aktuell vorhält und wie viel Countdown ihm noch bleibt; eine direkte Abfrage Ihres autoritativen Servers mit dig @ns1.example.net example.com A zeigt, was Sie tatsächlich veröffentlicht haben. Weichen die beiden voneinander ab, blicken Sie auf den Cache, und die Zahl neben dem Eintrag ist genau die Zeit, die Sie noch warten müssen.

Zwei Feinheiten sind es wert, eingeplant zu werden. Manche Resolver klammern: Ein Teil der ISP- und Enterprise-Forwarder erzwingt einen Mindest-TTL, egal was Sie veröffentlichen — technisch unerwünscht, aber durchaus real. Und nach RFC 8767 darf ein Resolver bewusst eine veraltete Antwort ausliefern, wenn er Ihre autoritativen Server nicht erreichen kann — ausgezeichnetes Verhalten für Resilienz, unpraktisch an dem Tag, an dem Sie wollen, dass sich eine Änderung verbreitet. Zusammen bedeutet das: Planen Sie einen langen Nachlauf ein, gemessen in Stunden, gelegentlich einem Tag, nachdem der Großteil des Traffics bereits umgezogen ist. Der Nachlauf ist kein Problem, solange die alte Maschine weiterhin korrekt antwortet — und genau deshalb bleibt sie eingeschaltet. RFC 2181 ist die Referenz dafür, wie sich TTLs verhalten sollen, wenn Implementierungen sich uneinig sind.

Auf der neuen Maschine proben, solange die alte noch im Einsatz ist

Die mit Abstand wertvollste Angewohnheit im gesamten Prozess ist, dass die neue Maschine schon Tage bevor es darauf ankommt existiert und funktioniert. Ein VPS ist praktisch gesehen eine stundenweise Miete: Bei unseren Plänen ist ein Server etwa sechzig Sekunden nach Zahlungsbestätigung live, es gibt keine Einrichtungsgebühr und keinen Vertrag, sodass ein dreitägiger Probelauf auf einem $8.50-Tarif etwa einen Dollar kostet. Das ist eine bemerkenswert günstige Art, jede Unbekannte in Ihrer Migration in eine Bekannte zu verwandeln, bevor die Uhr läuft.

Testen Sie per Hostname, nicht per IP. Wenn Sie die Adresse des neuen Servers im Browser aufrufen, bekommen Sie den Standard-Virtual-Host, keinen SNI-Treffer, eine Zertifikatswarnung und ein Routing, das der Produktion überhaupt nicht ähneln muss — und das wird Sie bereitwillig davon überzeugen, dass etwas funktioniert, obwohl es das nicht tut. Das richtige Werkzeug ist ein Resolver-Override. curl --resolve bindet einen Hostnamen für einen einzelnen Befehl an eine Adresse, sodass curl --resolve example.com:443:203.0.113.10 https://example.com/ den echten Namen, den echten TLS-Handshake und den echten Virtual Host gegen die neue Maschine ausübt, während der Rest der Welt weiterhin die alte erreicht. Für interaktives Testen erledigt eine Zeile in der Hosts-Datei Ihrer Workstation dasselbe für einen Browser.

Was der Probelauf zuverlässig auffängt, ist die angesammelte undokumentierte Schicht aus dem vorigen Abschnitt. Ein Daemon, der schon seit vor dem letzten Neustart läuft und eigentlich gar nicht aktiviert ist. Ein Cron-Job, der für die Fehlermeldung auf einen lokalen Mailtransport angewiesen ist. Dateibesitz, der die Kopie als Zahlen überstanden hat, aber auf einer Maschine mit einer anderen /etc/passwd etwas anderes bedeutet. Eine fest codierte Adresse in einer Konfigurationsdatei. Eine Datenbank, die mit einem Zeichensatz angelegt wurde, auf einer Version, die einen anderen Standard hatte. Eine Python- oder PHP-Minor-Version, die etwas, das Sie verwenden, als veraltet markiert hat. Jedes davon kostet zehn Minuten zum Beheben während einer Probe und eine Stunde zum Diagnostizieren während einer Umschaltung.

Ein Test ist mehr wert als alle anderen: Bauen Sie die neue Maschine zweimal. Bauen Sie sie ganz neu auf, nur anhand Ihres Inventars und Ihres Backups, ohne auf den alten Server zu schauen. Kommt sie beim zweiten Mal korrekt hoch, ist Ihr Inventar echt und Ihr Runbook ausführbar. Kommt sie es nicht, haben Sie gerade die Lücke gefunden, in einer Situation, in der das Finden nichts kostet. Erstellen Sie einen Snapshot, sobald alles stimmt — stündliche Snapshots mit sieben Tagen Aufbewahrung sind in jedem Plan enthalten, und eine Wiederherstellung dauert etwa dreißig Sekunden —, damit auch jedes spätere Experiment auf der neuen Maschine reversibel ist.

rsync zweimal: ein langer Durchlauf im laufenden Betrieb, ein kurzer im Zeitfenster

Das Zwei-Durchlauf-Muster ist es, was das Wartungsfenster kurz hält. Der erste Durchlauf läuft, während der Dienst voll live ist, und darf so lange dauern, wie er dauert — Stunden, über Nacht, über ein ganzes Wochenende. Der zweite Durchlauf läuft während der Schreibsperre und überträgt nur, was sich seit dem ersten geändert hat, was bei einer normalen Last ein kleiner Bruchteil der Daten und eine vorhersehbare Anzahl Minuten ist. Sie tauschen eine lange unbeaufsichtigte Kopie gegen eine kurze beaufsichtigte, und dieser Tausch lohnt sich fast immer.

Die Flags spielen eine größere Rolle, als man denkt. rsync -aHAX --numeric-ids ist die Grundausstattung: -a für den Archivmodus, -H zum Erhalten von Hardlinks — was für Maildir-Speicher und für deduplizierte Backup-Bäume enorm wichtig ist, wo ein Weglassen die Festplattennutzung vervielfachen kann —, -A für POSIX-ACLs, -X für erweiterte Attribute wie SELinux-Labels und Dateifähigkeiten, sowie --numeric-ids, damit eine Benutzer-ID als Zahl kopiert wird, statt über die Benutzerdatenbank der Quelle aufgelöst und auf dem Ziel über eine andere erneut aufgelöst zu werden. Fügen Sie --info=progress2 für eine einzige, vernünftige Fortschrittszeile hinzu und --partial, damit eine unterbrochene Übertragung fortgesetzt statt neu gestartet wird. Lassen Sie -z weg, außer die Verbindung ist wirklich langsam: bereits komprimierte Medien und verschlüsselte Archive zu komprimieren, verschiebt den Engpass nur auf die CPU.

Verwenden Sie --delete nur beim zweiten Durchlauf. Beim ersten Durchlauf ist es ein Schuss ins eigene Knie ohne jeden Nutzen, weil es auf dem Ziel nichts gibt, das entfernt werden müsste. Beim zweiten Durchlauf ist es unverzichtbar: Ohne es lebt eine Datei, die Sie zwischen den beiden Durchläufen auf dem alten Server gelöscht haben, auf dem neuen für immer weiter — und so landet eine Migration dabei, Inhalte auszuliefern, die absichtlich entfernt wurden.

Was Sie nicht tun sollten, ist das gesamte Root-Dateisystem per rsync zu kopieren. Es ist eine beliebte Abkürzung, und sie erzeugt eine Maschine, über die niemand mehr Bescheid weiß. Selbst mit ausgeschlossenen /proc, /sys, /dev, /run und /tmp landen Sie bei einem System, dessen Kernel und initramfs von einem anderen Host stammen, dessen Netzwerkschnittstellen-Benennung von anderer Hardware abgeleitet wurde, dessen /etc/machine-id jetzt auf zwei aktiven Maschinen dupliziert ist, und dessen angesammelte fünf Jahre an Konfigurations-Drift Sie sich gerade erst erkauft haben zu bewahren. Migrieren Sie die Daten und die Konfiguration, die Sie inventarisiert haben; installieren Sie das Betriebssystem frisch aus einer Vorlage. Das kostet eine zusätzliche Stunde, gibt Ihnen eine saubere, moderne Basis, und es bedeutet, dass der neue Server eine Maschine ist, die Sie verstehen, statt eine Kopie von einer, die Sie nicht verstanden haben.

Verifizieren Sie die Kopie, statt dem Exit-Code zu vertrauen. Führen Sie nach beiden Durchläufen denselben Befehl erneut aus, mit -n --checksum --itemize-changes: ein Trockenlauf, der Inhalte statt Zeitstempel vergleicht und pro Unterschied eine Zeile ausgibt. Stille ist das Ergebnis, das Sie wollen, und das ist eine weitaus stärkere Aussage, als wenn du -s auf beiden Seiten übereinstimmt.

Die Datenbank ist der Teil, bei dem rsync Ihnen nicht helfen kann

Das dateibasierte Kopieren eines laufenden Datenbankverzeichnisses liefert Ihnen eine zerrissene Kopie: manche Seiten geschrieben, manche nicht, keine Garantie, dass irgendetwas davon eine konsistente Transaktionsgrenze bildet. InnoDB erholt sich davon womöglich und wirkt in Ordnung, was schlimmer ist als ein Fehlschlag, weil Sie es erst an dem Tag merken, an dem die Wiederherstellung nicht funktioniert. Es gibt genau zwei ehrliche Strategien — einen transaktional konsistenten Dump erstellen, oder replizieren —, und die Wahl zwischen beiden ist eine Wahl darüber, wie viel Ausfallzeit Sie sich erkaufen.

Für den Dump-Weg unter MySQL und MariaDB liefert mysqldump --single-transaction --routines --triggers --events einen konsistenten Snapshot, ohne den ganzen Server zu sperren, mit zwei Vorbehalten, die man kennen sollte: Er ist nur für transaktionale Tabellen konsistent, sodass eine einzige altmodische MyISAM-Tabelle die Garantie still und leise bricht, und jede während des Dumps ausgeführte DDL-Anweisung bricht sie ebenfalls. Unter PostgreSQL kümmert sich pg_dump -Fc um jede einzelne Datenbank, und pg_dumpall --globals-only um die Hälfte, die man vergisst — Rollen, Passwörter, Berechtigungen und Tablespaces leben auf Cluster-Ebene, nicht innerhalb einer einzelnen Datenbank, sodass eine Wiederherstellung ohne sie perfekte Daten liefert, bei denen sich die Anwendung nicht authentifizieren kann.

Die Zahl, die Ihr Zeitfenster bestimmt, ist nicht die Dump-Größe, sondern Dump plus Übertragung plus Wiederherstellung plus Indexneuaufbau, und Letzteres ist meist der größte Posten. Messen Sie ihn während der Probe am echten Datensatz, statt ihn zu schätzen. Ein paar Gigabyte sind Minuten; hundert Gigabyte mit umfangreicher Indizierung können Stunden sein, und an diesem Punkt hört der Dump-Weg auf, für einen Live-Dienst tragfähig zu sein, und Replikation wird zur Antwort statt zu einer Optimierung.

Der Replikationsweg kehrt die Kosten um: Sie leisten die Arbeit im Voraus, und die Umschaltung wird trivial. Richten Sie das Replikat Tage vorher auf dem neuen Host ein — GTID-basierte Replikation für MySQL und MariaDB, pg_basebackup und ein Streaming-Standby für PostgreSQL, oder logische Replikation, wenn Sie zusätzlich eine Hauptversion wechseln. Lassen Sie es aufholen und aufgeholt bleiben. Die Umschaltung ist dann: Schreibzugriffe auf dem Primärsystem stoppen, warten, bis das Replikat null Lag meldet, es befördern, die Anwendung darauf ausrichten. Das dauert Sekunden, und es ist der einzige Ansatz, der die Formulierung „nahezu keine Ausfallzeit“ ehrlich verdient.

Vergessen Sie nicht den Zustand, der nicht in der Datenbank steckt. Redis, Valkey und Memcached halten Sessions, Rate-Limit-Zähler und Queues; ein Suchindex in Elasticsearch, OpenSearch oder Meilisearch hält eine abgeleitete Kopie Ihrer Daten. Entscheiden Sie für jeden einzeln explizit, ob Sie ihn migrieren oder neu aufbauen. Eine Redis-Instanz, die Sessions hält, lohnt es, mit einem BGSAVE und einer Kopie der entstehenden Datei umzuziehen — es sei denn, Sie sind damit einverstanden, alle abzumelden. Ein Suchindex lässt sich fast immer schneller auf dem neuen Host neu indizieren als übertragen — aber die Neuindizierung braucht Zeit, also starten Sie sie während der Probe und nicht während der Schreibsperre.

TLS-Zertifikate, SSH-Host-Keys und die Identitäten, die Sie nicht einfach neu ausstellen können

Die Zertifikatsausstellung hat genau im falschen Moment ein Henne-Ei-Problem. Die HTTP-01-Challenge beweist die Kontrolle über einen Namen, indem sie eine Datei über diesen Namen abruft, was voraussetzt, dass der Name bereits auf die zu validierende Maschine auflöst — und vor der Umschaltung tut er das nicht. Es gibt drei Auswege, und Sie sollten sich bewusst für einen entscheiden. Das Zertifikatsverzeichnis hinüberkopieren, was sofort funktioniert und völlig legitim ist, weil es Ihr eigener Schlüssel ist. Stattdessen die DNS-01-Challenge verwenden, die per Veröffentlichung eines TXT-Eintrags validiert und daher auf einer Maschine funktioniert, auf die noch nichts zeigt, und die ohnehin die einzige Option für ein Wildcard-Zertifikat ist. Oder ein kurzes Zeitfenster nach der DNS-Umstellung akzeptieren, in dem der neue Host sein eigenes Zertifikat anfordert — in Ordnung für eine private Website, nicht in Ordnung für alles mit Nutzern.

Wenn Sie kopieren, kopieren Sie alles. Die Zertifikate und privaten Schlüssel sind der offensichtliche Teil; der ACME-Account-Schlüssel ist der Teil, der zurückbleibt, und ohne ihn registriert der Client auf dem neuen Host bei der ersten Erneuerung ein brandneues Konto. Alles wirkt, als würde es funktionieren, und Sie haben still und leise die Historie des Kontos und jeden kontogebundenen Zustand verloren. Bewahren Sie auch Eigentümerschaft und Berechtigungen: private Schlüssel mit 600, das Archivverzeichnis mit 700 — denn eine Kopie, die die Berechtigungen eines Schlüssels erweitert, ist ein schlimmeres Ergebnis als die Migration, vor der Sie sich fürchteten.

Planen Sie nicht, wiederholt neu auszustellen und zu sehen, was passiert. Die Rate-Limits von Let's Encrypt deckeln doppelte Zertifikate für einen identischen Satz Hostnamen pro Woche, und zwei fehlgeschlagene Proben plus eine echte Ausstellung sind eine überraschend leichte Art, die Obergrenze ausgerechnet an dem Tag zu erreichen, an dem Sie es sich nicht leisten können zu warten. Richten Sie Proben gegen die Staging-Umgebung; heben Sie den Produktions-Endpunkt für den echten Fall auf.

SSH-Host-Keys sind die andere Identität im Spiel, und hier hängt die richtige Antwort wirklich davon ab, warum Sie umziehen. Das Kopieren von /etc/ssh/ssh_host_* macht die Migration unsichtbar: Die known_hosts-Datei jedes Clients passt weiterhin, und keine Automatisierung bleibt mit einer Fingerabdruck-Warnung stehen. Das ist bequem, und es ist die richtige Wahl für einen Routineumzug zwischen Anbietern, denen Sie vertrauen. Es ist die falsche Wahl, wenn der Grund für Ihren Weggang ist, dass Sie dem alten Host oder dem alten Anbieter nicht mehr vertrauen — jeder mit Zugriff auf diese Festplatte hatte Ihren privaten Host-Schlüssel, und ihn auf den neuen Server mitzunehmen, trägt das Problem gleich mit. Generieren Sie in diesem Fall neue Schlüssel, veröffentlichen Sie den neuen Fingerabdruck über einen Kanal, der nicht der Server selbst ist, und lassen Sie Clients ssh-keygen -R gegen den alten Eintrag ausführen. Das OpenSSH-sshd-Manual zeigt, wo die Schlüssel liegen und wie sie ausgewählt werden.

Eine Regel ist so oder so absolut: Lassen Sie niemals beide Maschinen gleichzeitig mit demselben Host-Key laufen und demselben Hostnamen, der auf beide auflöst. Das ist eine Konfiguration, in der ein Client nicht erkennen kann, welchen Server er erreicht hat — genau das zu verhindern, ist der Zweck, für den Host-Keys existieren. Während des Überlappungsfensters behält der alte Host seine Identität und der neue hat seine eigene, oder der Name des alten Hosts wird stillgelegt, sobald der neue dessen Schlüssel übernimmt.

Die Umschaltung: die zehn Minuten, die eine schriftliche Reihenfolge brauchen

Alles bisher war umkehrbar und unter keinem Zeitdruck. Die Umschaltung ist keins von beidem, und genau das ist das ganze Argument dafür, sie vorher aufzuschreiben: Improvisation unter Zeitdruck ist es, was aus einem Fünf-Minuten-Fenster einen zweistündigen Vorfall macht. Das Runbook sollte wortwörtliche Befehle in Reihenfolge enthalten, mit der erwarteten Ausgabe neben jedem einzelnen, sodass die Ausführung Lesen statt Denken erfordert.

Die Reihenfolge, die funktioniert. Erstens: Schreibzugriffe auf dem alten Host stoppen — eine Wartungsseite, ein Schreibschutz-Flag, oder einfach die Anwendung stoppen, während der Webserver weiterhin mit einer Platzhalterseite antwortet. Zweitens: den letzten rsync-Durchlauf mit --delete ausführen. Drittens: den Datenbankschritt abschließen — entweder das von Ihnen gemessene Dump-Transfer-Restore, oder Schreibzugriffe auf dem Primärsystem stoppen, null Replikations-Lag bestätigen und das Replikat befördern. Viertens: die Dienste auf dem neuen Host starten und ihnen einen Moment zum Einpendeln geben — Connection-Pools, Queue-Worker und das Laden von Zertifikaten dauern bei einem Kaltstart alle länger, als man in Erinnerung hat. Fünftens: verifizieren. Sechstens, und erst nachdem die Verifizierung bestanden ist, die DNS-Einträge ändern. Siebtens: den alten Host weiterlaufen lassen.

Verifizierung muss etwas bedeuten. Die Startseite abzurufen beweist, dass der Webserver läuft, und sonst nichts. Verwenden Sie curl --resolve gegen den echten Hostnamen auf einem Pfad, der die Datenbank berührt und etwas zurückgibt, das Sie überprüfen können — ein Health-Endpoint, der Datenbankanbindung, Cache-Anbindung und freien Plattenplatz prüft, lohnt sich allein aus diesem Grund. Lesen Sie dann das Access-Log des neuen Hosts und bestätigen Sie, dass Ihre Anfrage darin steht. Dieser letzte Schritt klingt pedantisch, und es ist genau der Schritt, der den Fall auffängt, in dem Ihr Resolver-Override nicht gegriffen hat und Sie gerade sorgfältig den alten Server verifiziert haben.

Beobachten Sie nach der DNS-Umstellung beide Access-Logs nebeneinander. Der Traffic auf dem neuen Host steigt; der Traffic auf dem alten Host klingt ab, während Caches ablaufen, und diese Abklingkurve ist das einzige ehrliche Maß dafür, wie lang der Nachlauf tatsächlich ist. Wenn das Log des alten Hosts nahe null abflacht, ist die Migration abgeschlossen. Bis dahin muss die alte Maschine für die Nutzer, die sie noch erreichen, weiterhin korrekt funktionieren — weshalb sie eingeschaltet und schreibgeschützt bleibt, statt in einem Moment der Begeisterung abgeschaltet zu werden. Lässt sich die Anwendung nicht schreibgeschützt schalten, ist es meist ein kleinerer Schaden, wenn der alte Host veraltete Daten ausliefert, als wenn er die Verbindung verweigert — aber das ist eine Entscheidung, die man vorher treffen sollte, nicht im Moment selbst.

Ändern Sie eine Sache. Nicht die Hauptversion des Betriebssystems und den Host. Nicht den DNS-Anbieter und die Einträge. Nicht die PHP-Version und die Maschine. Jede gleichzeitige Änderung vervielfacht die Hypothesen, die Sie testen müssen, wenn um drei Uhr morgens etwas nicht so funktioniert, wie es soll — und das Upgrade, das mit hineinzunehmen Sie versucht waren, ist nächste Woche immer noch da, auf einer Maschine, zu der Sie jetzt zurückrollen können.

Mail, rDNS und die Reputation, die nicht mit Ihnen umzieht

Versendet der Server Mail, hat die Migration eine zweite Hälfte, die mit der Migration selbst gar nichts zu tun hat. Eine IP-Adresse trägt eine Versandreputation, diese Reputation wird über Wochen aufgebaut, und sie kommt nicht mit. Das ist die mit Abstand häufigste Art, wie eine technisch tadellose Migration eine Woche Kundenbeschwerden erzeugt, und die Gegenmaßnahmen müssen alle vor der Umschaltung beginnen, nicht danach.

Der Eintrag, der zuerst bricht, ist SPF. Eine Policy mit einem ip4:-Mechanismus, der die alte Adresse nennt, fängt in dem Moment an zu versagen, in dem Sie von der neuen aus versenden, und weil RFC 7208-Policys DNS-Einträge sind, haben sie ihren eigenen TTL, den man einplanen muss. Fügen Sie die neue Adresse vor der Umschaltung zu SPF hinzu, führen Sie während der Überlappung beide auf, und entfernen Sie die alte, wenn Sie außer Betrieb nehmen. DKIM übersteht den Umzug problemlos, solange Sie den privaten Schlüssel mit dem Rest der Konfiguration kopieren, da die öffentliche Hälfte bereits veröffentlicht ist. DMARC braucht keine Änderung, aber es lohnt sich zu bestätigen, dass die Berichtsadresse noch auf einer Maschine existiert, die gerade zerstört werden soll.

Reverse DNS ist für einen versendenden Host nicht optional. Der PTR-Eintrag auf der neuen Adresse muss existieren und muss zu dem Namen passen, den der Server in seinem HELO oder EHLO ankündigt, sonst weist ein großer Teil der Empfänger allein deswegen ab. Bei unseren Plänen ist PTR im Panel editierbar, also eine Checkbox statt eines Tickets — setzen Sie ihn während der Probe, verifizieren Sie, dass er auflöst, und bestätigen Sie, dass der Forward-Eintrag dazu passt. Prüfen Sie dann die neue Adresse gegen die wichtigsten Blocklisten, bevor Sie überhaupt irgendetwas versenden: Wiederverwendete Adressen tauchen gelegentlich bereits gelistet auf, und das über die eigene Testnachricht herauszufinden, kostet nichts, während es über einen Kunden herauszufinden viel kostet. Spamhaus ist die wichtigste davon.

Halten Sie für den Empfang beide Hosts erreichbar. Fügen Sie den neuen Server als MX mit Priorität 10 hinzu und lassen Sie den alten für eine Woche auf Priorität 20 stehen, statt ihn zu löschen: Absender wiederholen Versuche, manche von ihnen hatten Ihren MX-Eintrag gecacht, und ein Mailserver, der auf dem alten Host still und leise annimmt, ist weit besser als ein Bounce. Leeren und entleeren Sie dann, bevor Sie die alte Maschine zerstören, ihre Queue — postqueue -f, um einen Zustellversuch zu erzwingen, und mailq, um zu bestätigen, dass das Ergebnis leer ist. Nachrichten, die in einer Queue auf einem Server liegen, den Sie gleich löschen, sind nicht verzögert. Sie sind verloren. Der Leitfaden zum selbst gehosteten Mailserver behandelt die Zustellbarkeit ausführlich.

Wenn der alte Anbieter die Maschine bereits abgeschaltet hat

Nicht jede Migration ist geplant. Eine Sperrung nach einer Missbrauchsmeldung, eine abgelaufene Karte, ein Konto, das aus einem Grund gesperrt wurde, den niemand erklären will — der gemeinsame Nenner ist, dass Sie jetzt von einer Maschine migrieren, bei der Sie sich nicht mehr anmelden können, und die komfortable Reihenfolge von oben gilt nicht mehr. Es lohnt sich, im Voraus zu wissen, was normalerweise noch möglich ist, denn das Zeitfenster, in dem es möglich ist, ist oft kurz.

Solange eine Instanz gesperrt, aber noch nicht gelöscht ist, bleiben häufig drei Wege offen, in abnehmender Reihenfolge ihres Nutzens. Das Kontrollpanel bietet womöglich noch einen Snapshot- oder Backup-Download an, womit das gesamte Problem in einem Schritt gelöst wäre. Ein Rescue- oder Recovery-Modus bootet womöglich noch ein Live-Image mit angehängter Festplatte, sodass Sie das Dateisystem mounten und das Wichtige über das Netzwerk herauskopieren können. Und die Notfallkonsole lässt sich womöglich noch verbinden, selbst wenn das Netzwerk deaktiviert ist — genug, um Konfigurationsdateien zu lesen, einen Schlüssel zu retten oder zu notieren, was installiert war —, aber sie ist kein Weg für eine Datenbank, planen Sie also nicht damit. Probieren Sie sie in dieser Reihenfolge, und probieren Sie sie sofort: Die Aufbewahrung nach einer Sperrung ist eine Richtlinie, kein Recht, und sie wird häufig in Tagen gemessen.

Es gibt eine Grenze, die kein Support-Ticket auflöst, und es lohnt sich, das unverblümt auszusprechen, denn es ist eine direkte Konsequenz des Modells, das diese Seite verkauft. Bei einem Host, der nie eine Identität erfasst hat — auch dieser hier nicht —, gibt es keine Möglichkeit zu beweisen, dass Sie der Kontoinhaber sind, außer im Besitz der Kontozugangsdaten zu sein. Das ist der Sinn von No-KYC-Hosting, und es ist auch seine Rechnung: Niemand kann Ihren Zugang aufgrund eines Passfotos wiederherstellen, weil nie ein Pass an irgendetwas geheftet war. Der Leitfaden zum No-KYC-Hosting behandelt diesen Kompromiss ausführlich; die operative Konsequenz ist schlicht, dass Ihr Wiederherstellungsplan nicht über das Wohlwollen von irgendjemand anderem laufen kann.

Die Notfallsequenz ist die geplante Sequenz, nur ohne die Überlappung. Bringen Sie den neuen Host aus Ihrem Off-Machine-Backup hoch. Verifizieren Sie ihn ordentlich per Hostname, denn die Versuchung, die Verifizierung auszulassen, ist genau dann am größten, wenn Sie bereits down sind. Stellen Sie dann sofort DNS um — die TTL-Disziplin gilt weiterhin, nur dass Sie den Cache-Nachlauf jetzt als Ausfall bezahlen statt ihn als Überlappung auszugeben, was das mit Abstand klarste Argument dafür ist, TTLs als dauerhafte Politik niedrig zu halten statt nur als Migrationsschritt. Rechnen Sie eine Weile mit eingeschränkter Mail, und warnen Sie Leute frühzeitig, statt es später zu erklären.

Die Lehre daraus reicht über diesen einen schlechten Tag hinaus. Ein Backup, das auf dem Server liegt, ist kein Backup; es ist eine zweite Kopie der Sache, die Sie gerade zu verlieren drohen. Was zählt, ist die Eigenschaft, dass die Kopie woanders liegt, verschlüsselt wird, bevor sie den Server verlässt, nur anhängbar ist, sodass ein kompromittierter oder gesperrter Host seine eigene Historie nicht löschen kann, und — der Teil, den alle überspringen — tatsächlich einmal wiederhergestellt wurde, in eine Wegwerf-Instanz, damit Sie wissen, dass die Wiederherstellung funktioniert. Die Härtungs-Checkliste behandelt, wie man das auf einer neuen Maschine einrichtet; falls Sie diesen Abschnitt lesen, weil es bereits zu spät ist, richten Sie es noch heute auf der Maschine ein, zu der Sie migrieren, vor allem anderen.

Rollback: den Auslöser festlegen und ihm ein Verfallsdatum geben

Fast jeder sagt, er habe einen Rollback-Plan, und fast niemand hat aufgeschrieben, was ihn auslösen würde. Ohne Auslöser wird die Entscheidung im schlechtesten Moment getroffen, von wem auch immer gerade am müdesten ist, und das übliche Ergebnis ist, dass niemand zurückrollt, weil es sich immer so anfühlt, als sei das aktuelle Problem in fünf Minuten behoben. Legen Sie im Voraus fest: eine Fehlerrate oberhalb eines Schwellenwerts über eine bestimmte Dauer, eine bestimmte kaputte Funktion, oder schlicht eine Uhrzeit, nach der Sie das Debuggen einstellen und zurückgehen.

Die Randbedingung, die bestimmt, was Rollback überhaupt bedeutet, sind Schreibzugriffe. Ab dem Moment, in dem der neue Host seinen ersten Schreibzugriff annimmt, bedeutet Zurückgehen entweder, diese Schreibzugriffe zu verwerfen, oder sie auf die alte Maschine nachzuspielen. Sie wählen also eigentlich zwischen zwei völlig unterschiedlichen Dingen. Ein Rollback vor dem ersten Schreibzugriff ist eine DNS-Änderung und dauert Minuten. Ein Rollback nach einem Tag Produktionstraffic ist eine Migration in die Gegenrichtung, mit denselben Schritten, und dauert so lange, wie dieser Leitfaden es beschreibt. Wissen Sie zu jedem Zeitpunkt, welche der beiden Sie gerade vor sich haben, und beachten Sie, dass die zweite Art wesentlich leichter ist, wenn Sie die Datenbank der alten Maschine in der Lage gehalten haben, eine Wiederherstellung zu empfangen, statt die Maschine anderweitig zu verwenden.

Behalten Sie den alten Server etwa eine Woche lang: eingeschaltet, schreibgeschützt, DNS-TTL weiterhin niedrig, Monitoring weiterhin darauf gerichtet. Beim kleinsten Plan kostet diese Versicherung etwa zwei Dollar, und das ist keine Zahl, die in die Entscheidung einfließen sollte. Was einfließen sollte, ist, dass eine Woche lang genug ist, damit die wöchentlichen Cron-Jobs, die ungefähr monatlichen Berichte und die Integration, die nur freitags feuert, jeweils mindestens einmal auf dem neuen Host gelaufen sind — genau das sind die Fehler, die ein Zwei-Tage-Fenster komplett verpasst.

Nehmen Sie ihn dann bewusst außer Betrieb. Bestätigen Sie, dass das Access-Log des alten Hosts einen Tag lang flach war. Erstellen Sie ein letztes Backup davon und bewahren Sie es länger auf, als Sie meinen zu brauchen. Widerrufen Sie alles, was er hielt: API-Keys, Deploy-Keys, Datenbankbenutzer, seine Einträge in den IP-Allowlists anderer Leute, seine Monitoring-Checks, seinen SPF-Eintrag, seinen MX-Eintrag. Löschen Sie die Instanz. Und setzen Sie schließlich die DNS-TTLs auf etwas Vernünftiges zurück — ein dauerhafter 300-Sekunden-TTL bedeutet, dass Resolver für den Rest des Lebens der Seite zwanzigmal pro Stunde revalidieren, was Ihnen nichts mehr bringt, sobald die Migration vorbei ist, und bei jeder kalten Abfrage ein wenig Latenz kostet. Eine Stunde ist ein vernünftiger Dauerwert; ein Tag ist in Ordnung für Einträge, von denen Sie nie erwarten, dass sie sich schnell ändern.

Die Migration, in der Reihenfolge, in der Sie sie ausführen

Eine Woche vorher: die alte Maschine inventarisieren und das Runbook schreiben: Pakete, aktivierte Units, Crontabs, Firewall, lauschende Sockets, Datenbankrollen und jeder Drittanbieter, der die alte Adresse freigegeben hatte. Drei Tage vorher: den neuen VPS bereitstellen, darauf wiederherstellen, und das Ganze per Hostname mit Resolver-Override proben — dann einmal ausschließlich anhand des Inventars neu aufbauen, um zu beweisen, dass das Inventar echt ist. Zwei Tage vorher: die TTLs von A, AAAA und MX auf 300 senken, damit ein voller alter TTL verstreicht, bevor Sie sie niedrig brauchen.

Einen Tag vorher: den ersten rsync-Durchlauf mit -aHAX --numeric-ids ausführen, während die Produktion weiterläuft, und die Datenbankreplikation hochfahren oder das Dump-Zeitfenster am echten Datensatz messen. Erledigen Sie die Zertifikate im selben Zug — kopieren Sie das Zertifikatsverzeichnis samt ACME-Account-Schlüssel, oder wechseln Sie zu DNS-01 — und setzen Sie den PTR-Eintrag und den neuen SPF-Eintrag auf der neuen Adresse, bevor irgendetwas von dort Mail versendet.

Im Zeitfenster: Schreibzugriffe einfrieren, letztes rsync mit --delete, Datenbank abschließen, Dienste starten, gegen den echten Hostnamen auf einem Pfad verifizieren, der die Datenbank berührt, bestätigen, dass die Anfrage im Log des neuen Hosts gelandet ist, und erst dann DNS umstellen. Den alten Host eingeschaltet und schreibgeschützt lassen. Beide Access-Logs beobachten, bis das alte abflacht.

Eine Woche später: bestätigen, dass die wöchentlichen Jobs auf dem neuen Host gelaufen sind, ein letztes Backup des alten erstellen, seine Keys und Allowlist-Einträge überall widerrufen, ihn löschen und die TTLs zurücksetzen. Wenn Sie wollen, dass die neue Maschine besser ist als die, die Sie verlassen haben, statt nur neuer, sind die ersten fünfzehn Minuten der Härtung der naheliegende nächste Schritt, und das ist auf einem Server, der noch keine eigene undokumentierte Schicht angesammelt hat, wesentlich leichter zu erledigen. Falls Sie noch überlegen, wo Sie landen sollen, behandelt der Leitfaden zur Wahl der Rechtsordnung, was sich zwischen Island, den Niederlanden, Rumänien und der Schweiz tatsächlich unterscheidet — und Sie können die Zielmaschine in etwa einer Minute zum Laufen bringen, um den Probelauf noch heute zu starten.