Einen VPS ohne Downtime zu einem neuen Host migrieren

Die meisten Migrationen scheitern nicht während der Kopie. Sie scheitern in den zwanzig Minuten nach der DNS-Änderung, wenn die eine Hälfte des Internets noch mit dem alten Server spricht und die andere Hälfte bereits umgezogen ist — und beide Maschinen Schreibvorgänge annehmen. Die Dateien sind vollständig angekommen, die Seite lädt, und trotzdem landen Bestellungen in zwei Datenbanken, die sich nie wieder zusammenführen lassen. Das zu vermeiden hat fast nichts mit der Übertragungsgeschwindigkeit zu tun und fast alles mit der Reihenfolge: was Sie zuerst ändern, was Sie einfrieren, und was Sie laufen lassen, bis Sie sich sicher sind.

Was keine Downtime wirklich bedeutet

Es lohnt sich, hier präzise zu sein, denn die Formulierung deckt zwei sehr unterschiedliche Versprechen ab, die sehr unterschiedlich viel Aufwand kosten. Zu entscheiden, welches davon Sie eigentlich wollen, ist die erste echte Entscheidung der Migration.

Wenn Sie eines von beiden opfern müssen, opfern Sie die Verfügbarkeit. Eine Wartungsseite für vier Minuten lässt sich erklären. Auseinanderlaufende Daten lassen sich nicht reparieren, weil es keine Instanz mehr gibt, die sagen kann, welche Kopie richtig war.

Machen Sie die Inventur, bevor Sie die Kopie machen

Ein Server sammelt im Lauf der Zeit Dinge an, die niemand dokumentiert hat: einen Cronjob, der während eines Vorfalls hinzugefügt wurde, eine Firewall-Regel für die Adresse eines Partners, einen API-Schlüssel, der in eine Service-Datei eingefügt wurde. Die Kopie nimmt das alles nicht mit, und Sie werden es in den folgenden zwei Wochen Stück für Stück entdecken. Eine halbe Stunde Inventur jetzt erspart Ihnen fast das Ganze.

Schreiben Sie es in eine Datei, die Sie in der Versionsverwaltung pflegen, nicht in den Terminal-Verlauf. Sie werden es während der Umschaltung dreimal lesen — einmal in einem Moment, in dem Sie nicht klar denken.

Wählen Sie das Ziel nach den Dingen, die Sie später nicht mehr ändern können

Specs lassen sich anpassen; ein paar Eigenschaften nicht, und die sind es wert, bewusst entschieden zu werden, solange Sie noch die freie Wahl haben. Da Sie ohnehin umziehen, ist dies der günstigste Moment, den Sie je bekommen werden, um eine Einschränkung zu beheben, mit der Sie bislang nur umgegangen sind.

• Standort, weil sowohl die Latenz zu Ihren Nutzern als auch das anwendbare Recht dadurch festgelegt werden. /locations listet die Regionen und ihre Round-Trip-Eigenschaften auf; wählen Sie eine, die unabhängig von der ausfällt, die Sie verlassen.
• Rechtliche Grundlage, falls der Grund für den Umzug ist, dass Ihr aktueller Anbieter Beschwerden schneller weiterleitet als Pakete. /offshore-hosting legt dar, was die Jurisdiktion wirklich kontrolliert und was nicht.
• Abrechnungsidentität, denn ein Host, der Dokumente verlangt, bevor er eine Zahlung akzeptiert, hat allein dadurch eine Akte über Sie. /no-kyc-vps und /pay-with beschreiben die Alternative — ein mit Krypto aufgeladenes Guthaben, keine Karte, kein Name, der mit der Maschine verknüpft ist.
• Reserven, denn zweimal migrieren zu müssen ist das Ergebnis, mit dem niemand plant. /vps listet die Stufen auf, und /guides enthält die Methode zur Dimensionierung, falls die aktuelle Maschine noch nie wirklich vermessen wurde.
• IPv6 und eine saubere IPv4, denn eine recycelte Adresse kann mit dem Ruf eines anderen im Gepäck ankommen — prüfen Sie das, bevor es zu einem Mail-Problem wird.

Senken Sie zuerst die DNS-TTL, Tage vorher

Das ist der eine Vorbereitungsschritt, den Sie am Ende nicht hastig nachholen können, weil seine Wirkung von einer Uhr abhängt, die Sie nicht kontrollieren. Die TTL Ihrer Einträge sagt Resolvern, wie lange sie eine Antwort cachen sollen. Steht sie auf einen Tag, schickt ein Resolver, der vor einer Stunde gefragt hat, Nutzer die nächsten dreiundzwanzig Stunden weiter zum alten Server — ganz gleich, was Sie inzwischen veröffentlichen.

1. 1

   Aktuelle TTL auslesen

   dig +noall +answer yourdomain.com zeigt die verbleibende Cache-Zeit; fragen Sie Ihren autoritativen Nameserver direkt mit dig @ns1.example.net yourdomain.com ab, um den konfigurierten Wert zu sehen. Notieren Sie ihn — er bestimmt die Länge Ihrer Wartezeit.

2. 2

   Auf 300 Sekunden senken

   Senken Sie die TTL bei jedem Eintrag, der sich ändern wird: A, AAAA und jeder MX- oder CNAME-Eintrag, der auf den Host zeigt. Fünf Minuten sind kurz genug, um die Umschaltung angenehm zu machen, und lang genug, um Ihre Nameserver nicht zu überlasten.

3. 3

   Die alte TTL aussitzen, dann noch einmal warten

   Die neue, kurze TTL erreicht einen Resolver erst, nachdem die alte, lange abgelaufen ist. Warten Sie mindestens eine volle alte TTL-Periode — einen Tag, wenn es ein Tag war —, bevor Sie die niedrige TTL als gültig betrachten. Früh damit anzufangen kostet nichts und verschafft der ganzen Umschaltung ihren Puffer.

Bauen Sie den neuen Server neu auf, klonen Sie nicht den alten

Der Instinkt sagt: die aktuelle Festplatte imagen und anderswo wiederherstellen. Das ist der falsche Schritt, aus demselben Grund, aus dem er bei einer Wiederherstellung falsch ist: Ein Klon auf Blockebene reproduziert originalgetreu die Config-Drift, die verwaisten Pakete, den halb konfigurierten Dienst, den jemand aufgegeben hat, und jede Persistenz, die ein früherer Eindringling hinterlassen hat. Außerdem bindet er Sie an das alte Distributions-Release.

Bauen Sie die neue Maschine aus einem aktuellen Basis-Image auf, installieren Sie die Dienste aus einem Skript, und kopieren Sie nur die Daten. Das Skript ist das eigentliche Ergebnis — es macht aus der nächsten Migration einen Nachmittag statt zwei Wochen, und es lässt Sie nach einem Vorfall neu aufbauen, ohne Archäologie betreiben zu müssen.

• Provisionieren, aktualisieren und härten, bevor irgendetwas anderes sie berührt: SSH nur mit Schlüsseln, eine Firewall mit Default-Deny, unbeaufsichtigte Sicherheitsupdates. /guides hat die einstündige Version dieser Checkliste.
• Installieren Sie dieselben Major-Versionen von Runtime und Datenbank wie in der Produktion. Eine Migration ist ein schlechter Zeitpunkt, um nebenbei auch noch PostgreSQL 14 auf 17 hochzuziehen — ändern Sie eine Sache nach der anderen, damit ein Fehlschlag genau eine Erklärung hat.
• Legen Sie Benutzer und Gruppen mit denselben numerischen IDs neu an, bevor Sie Dateien kopieren, oder korrigieren Sie die Besitzrechte hinterher von Hand. Die Übertragung mit --numeric-ids hält die Nummern intakt; sie den richtigen Namen wieder zuzuordnen ist Ihre Aufgabe.
• Tragen Sie die neue Adresse in jede Allowlist ein, die aktuell die alte nennt — Partner-APIs, verwaltete Datenbank-Firewalls, Zahlungs-Gateways, Ihr eigenes Monitoring — solange beide noch gültig sind.

Kopieren Sie die Dateien in zwei Durchgängen

Eine einzelne Übertragung eines laufenden Dateisystems ist eine Momentaufnahme eines bewegten Ziels. Zwei Durchgänge lösen das sauber: Der erste ist lang und läuft gegen ein laufendes System, der zweite ist kurz und läuft während der Schreibsperre, und nur der zweite muss schnell sein.

Führen Sie den ersten Durchgang aus, wann immer Sie wollen — Tage vorher ist völlig in Ordnung. Er trägt den Großteil: das Uploads-Verzeichnis, den Mail-Spool, die Container-Volumes, die über Jahre angesammelten Medien. Er wird bis zur Umschaltung veraltet sein, und genau dafür ist der zweite Durchgang da.

• Verwenden Sie rsync -aAXH --numeric-ids --info=progress2 über SSH: -a für die üblichen Attribute, -A für ACLs, -X für erweiterte Attribute, -H für Hardlinks, die wichtig sind, falls irgendetwas auf der Maschine dedupliziert.
• Schließen Sie aus, was nicht mitreisen sollte: /proc, /sys, /dev, /run, die temporären Verzeichnisse, den Paket-Cache und Logs, die Sie nicht brauchen. Kernel-Schnittstellen zu kopieren verschwendet bestenfalls Zeit und lässt die Übertragung schlimmstenfalls hängen bleiben.
• Fügen Sie --delete nur beim zweiten Durchgang hinzu. Beim ersten ist es harmlos; beim zweiten entfernt es Dateien, die seitdem an der Quelle gelöscht wurden — genau die Drift, die Sie beseitigen wollen.
• Kopieren Sie die Systemkonfiguration gezielt statt pauschal. Sie wollen Ihre Webserver-vhosts, Ihre Service-Units und Ihre Anwendungskonfiguration — nicht die Dateisystemtabelle, die Netzwerkkonfiguration oder die Maschinen-ID der alten Maschine.
• Erzeugen Sie für die Übertragung einen Wegwerf-SSH-Schlüssel, autorisieren Sie ihn auf dem Ziel, und entfernen Sie ihn, wenn die Migration abgeschlossen ist. Ein Migrationsschlüssel, der zwei Jahre lang liegen bleibt, ist eine Zugangsberechtigung, an deren Vergabe sich niemand mehr erinnert.

Prüfen Sie zwischen den Durchgängen nach, statt es anzunehmen. Der zweite Durchgang mit --dry-run gibt genau aus, was er ändern würde: Eine Liste von ein paar hundert aktuellen Dateien ist gesund, eine Liste von vierzigtausend bedeutet, dass ein Ausschluss falsch ist oder irgendetwas ohne Grund Zeitstempel neu schreibt.

Die Datenbank umziehen, ohne Schreibvorgänge zu verlieren

Hier wird das Budget der Schreibsperre verbraucht, und die richtige Technik ergibt sich vollständig aus der Zahl, die Sie zu Beginn notiert haben. Alle drei Optionen unten sind richtig — für unterschiedliche Zahlen.

Dumpen Sie Schema und Daten getrennt, wenn der Datenbestand groß ist. Das Schema zuerst wiederherzustellen lässt Sie Struktur, Indizes und Berechtigungen auf dem neuen Host frühzeitig prüfen, wodurch das Laden der Daten zu einer einzigen langen Operation wird, die Sie während der Schreibsperre schon im Vertrauen starten können, dass sie ankommt.

Stellen Sie das TLS-Zertifikat vor dem Wechsel aus, nicht danach

Das Zertifikat auf dem neuen Server muss in dem Moment gültig sein, in dem der erste Nutzer eintrifft. Andernfalls trifft jeder Besucher auf eine Browser-Warnseite, und wenn Sie HSTS-Header senden — was Sie tun sollten —, können sie sich nicht durchklicken. Es gibt zwei Wege, ein funktionierendes Zertifikat zu besitzen, bevor DNS irgendwohin Neues zeigt.

• Kopieren Sie das vorhandene. Das gesamte ACME-State-Verzeichnis, oder nur Zertifikat und Schlüssel von dort, wo Ihr Client sie aufbewahrt. Es ist sofort gültig, weil Gültigkeit nichts damit zu tun hat, welcher Server die Datei besitzt, und die Erneuerung läuft normal weiter, sobald DNS umgezogen ist.
• Stellen Sie ein neues mit einer DNS-01-Challenge aus, die die Kontrolle über die Domain über einen TXT-Eintrag statt über einen HTTP-Request an die aktuelle Adresse nachweist. Das funktioniert vor der Migration, vor der Umschaltung, und für Wildcards, was HTTP-01 überhaupt nicht kann.
• Versuchen Sie vor dem Wechsel keine HTTP-01-Validierung auf dem neuen Server. Die Challenge wird über Port 80 unter dem Domainnamen abgerufen, die Domain löst noch immer zur alten Maschine auf, und die Validierung schlägt jedes Mal fehl.

Prüfen Sie es, ohne DNS anzufassen, indem Sie den Hostnamen für einen einzelnen Befehl auf die neue Adresse auflösen: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — mit der echten Adresse anstelle der Platzhalter. Diese eine Zeile ist die wertvollste Prüfung der gesamten Migration. Sie durchläuft den echten vhost, das echte Zertifikat und den echten Anwendungsstack auf der neuen Maschine, und so finden Sie die Fehlkonfiguration, während das Finden noch nichts kostet.

Wenn der Server Mails versendet, fangen Sie früher an

Mail ist der Teil einer Migration, der erst Tage später ausfällt, leise, und auf etwas anderes geschoben wird. Eine neue Adresse hat keine eigene Versandreputation und hat möglicherweise die eines anderen geerbt, und jeder Authentifizierungseintrag, den Sie veröffentlichen, ist an die Adresse gebunden, die Sie verlassen.

• Prüfen Sie die neue Adresse gegen die wichtigsten Blocklists, bevor Sie sich auf sie festlegen. Eine recycelte IP mit Vorgeschichte lohnt es sich zu tauschen, solange der Tausch noch nichts kostet.
• Setzen Sie den Reverse-DNS-Eintrag der neuen Adresse auf Ihren Mail-Hostnamen. Empfangende Server prüfen, ob Forward- und Reverse-Auflösung übereinstimmen, und ein fehlender PTR allein reicht schon, um als Spam einsortiert zu werden.
• Fügen Sie die neue Adresse vor der Umschaltung zu SPF hinzu und entfernen Sie die alte danach — beide während der Überlappung gelistet, sodass Mail unabhängig davon authentifiziert, welcher Server sie tatsächlich versendet hat.
• Kopieren Sie die privaten DKIM-Schlüssel, statt neue zu erzeugen, damit der bereits in DNS veröffentlichte Selector weiter gültig bleibt. Neu erzeugen bedeutet neu veröffentlichen, und neu veröffentlichen hat seine eigene Propagationsverzögerung.
• Wärmen Sie die neue Adresse schrittweise auf, wenn Sie in nennenswertem Volumen versenden. Ein Server, der seine gesamte Existenz lang nichts verschickt hat und dann zehntausend Nachrichten ausstößt, ist für einen Empfänger nicht von einem kompromittierten Host zu unterscheiden.

Die Umschaltung

Alles oben war Vorbereitung dafür, dass dieser Teil kurz, geordnet und umkehrbar ist. Erledigen Sie ihn dann, wenn Ihr Traffic tatsächlich am niedrigsten ist, nicht aus Aberglauben um 3 Uhr nachts — prüfen Sie Ihre eigenen Analytics. Schreiben Sie den Rollback auf, bevor Sie anfangen, denn im Moment, in dem Sie ihn brauchen, werden Sie am wenigsten Lust haben, ihn erst zu verfassen.

1. 1

   Schreibvorgänge auf dem alten Server einfrieren

   Wartungsmodus, ein schreibgeschützter Datenbankbenutzer, oder ein Fehler auf Schreibpfaden am Reverse Proxy. Lesevorgänge werden die ganze Zeit weiter von der alten Maschine bedient — das hält die Seite oben, während die Daten umziehen.

2. 2

   Jeden Timer auf dem alten Server deaktivieren

   Kommentieren Sie die Crontabs aus, stoppen Sie die Timer, stoppen Sie die Queue-Worker. Ab diesem Punkt darf die alte Maschine nichts mehr verarbeiten, sonst laufen Jobs doppelt: zwei Rechnungen, zwei E-Mails, zwei Webhook-Zustellungen.

3. 3

   Das finale Delta ausführen

   Der zweite Datei-Durchgang mit --delete, dann der finale Datenbank-Dump oder das Aufholen des Replikats. Das ist der kurze — höchstens Minuten —, weil der erste Durchgang bereits das Volumen bewegt hat.

4. 4

   Den neuen Server gegen seinen echten Hostnamen prüfen

   Nutzen Sie den --resolve-Trick von oben, um eine Seite zu testen, die aus der Datenbank liest, einen Login und einen Schreibpfad. Bestätigen Sie, dass die Zeilenzahlen mit der Quelle übereinstimmen. Tun Sie das alles, bevor DNS sich ändert, solange ein Rollback noch überhaupt nichts kostet.

5. 5

   DNS umschalten und die Dienste starten

   Aktualisieren Sie A und AAAA auf die neue Adresse, dann aktivieren und starten Sie die Anwendung und ihre Timer auf dem neuen Server. Traffic beginnt innerhalb einer TTL einzutreffen und verlagert sich über die folgende Stunde weiter.

6. 6

   Den alten Server weiter Lesevorgänge bedienen lassen

   Lassen Sie ihn mindestens vierundzwanzig Stunden lang laufen, schreibgeschützt. Clients mit veralteten Caches landen weiterhin dort, und ein schreibgeschützter alter Server liefert leicht veraltete Seiten statt einer verweigerten Verbindung — der Unterschied zwischen einer unsichtbaren Migration und einer sichtbaren.

Die ersten 48 Stunden

Die Migration ist nicht fertig, wenn die Seite lädt. Sie ist fertig, wenn nichts mehr von der alten Maschine abhängt — und diese Abhängigkeiten zu finden ist eine aktive Übung, kein Abwarten.

• Beobachten Sie das Access-Log des alten Servers. Jeder Request, der dort noch ankommt, ist eine nicht migrierte Abhängigkeit — eine fest codierte Adresse in einer Partner-Integration, ein mobiler Client mit veraltetem Cache, eine Monitoring-Probe, die niemandem mehr gehört. Das Log ist die To-do-Liste.
• Bestätigen Sie, dass die Timer auf dem neuen Host tatsächlich gelaufen sind. Nicht, dass sie aktiviert sind — dass sie gelaufen sind, zur erwarteten Zeit, mit der erwarteten Ausgabe. Ein Cronjob, der still und leise nichts tut, sieht genauso aus wie ein Cronjob, der funktioniert.
• Testen Sie die Zertifikatserneuerung wirklich mit einem Dry Run, statt in sechzig Tagen zu entdecken, dass Ihr ACME-Client gegen einen Server erneuert hat, der die Challenge nicht mehr empfängt.
• Prüfen Sie den Mailfluss Ende zu Ende in beide Richtungen, einschließlich allem, was die Anwendung automatisch versendet. Passwort-Resets sind der klassische Ausfall, weil niemand sie testet, bis ein Nutzer einen braucht.
• Erstellen Sie ein Backup des neuen Servers und stellen Sie es irgendwo wieder her. Eine frische Maschine ohne geprüftes Backup ist eine schlechtere Position als die, die Sie verlassen haben; /guides hat die ausführliche Version dieses Arguments.
• Setzen Sie die DNS-TTL auf ihren normalen Wert zurück, sobald Sie sich sicher sind. Sie für immer bei 300 Sekunden zu belassen ist ein kleiner dauerhafter Preis in Form von Queries und Latenz, dem kein verbleibender Nutzen mehr gegenübersteht.

Den alten Server außer Dienst stellen

Der letzte Schritt ist der, der übersprungen wird, und es ist der einzige mit einer Konsequenz für die Privatsphäre. Die alte Festplatte enthält Ihre Schlüssel, Ihre Datenbank, Ihre Kundendaten und Ihre Logs, und den Dienst zu kündigen löscht nichts davon — es gibt das Volume zurück in einen Pool, aus dem der nächste Mieter bekommt, was auch immer die Löschrichtlinie des Anbieters übrig gelassen hat.

• Warten Sie, bis das alte Access-Log still wird, bevor Sie irgendetwas anfassen. Zu kündigen, während ein Zahlungsanbieter noch Webhooks an die alte Adresse sendet, ist der Weg, auf dem aus einer Migration eine Woche später ein Vorfall wird.
• Rotieren Sie, statt nur zu löschen: alle Zugangsdaten, die der alte Server hielt — API-Schlüssel, Datenbank-Passwörter, Deploy-Keys, den temporären Migrationsschlüssel. Gehen Sie davon aus, dass alles, was auf einer Maschine lag, die Sie nicht mehr kontrollieren, kompromittiert ist — irgendwann ist es das nämlich.
• Überschreiben Sie die Daten, bevor Sie das Volume freigeben. Schreddern Sie die sensiblen Verzeichnisse, oder füllen Sie den freien Speicherplatz mit einer großen Zufallsdatei und löschen Sie sie. Auf einer virtualisierten Festplatte unvollkommen, aber weitaus besser als nichts.
• Erstellen Sie ein letztes Archiv von allem, was Sie vielleicht noch zum Nachschlagen brauchen — Logs, Konfiguration, die Shell-History, die dokumentiert, was tatsächlich getan wurde — und bewahren Sie es verschlüsselt an einem Ort auf, der keiner der beiden Server ist.
• Kündigen Sie den Dienst erst, nachdem der neue einen vollen Abrechnungszyklus und einen vollständigen Backup-und-Restore-Test überstanden hat. Dieser Überlappungsmonat ist die billigste Versicherung im gesamten Prozess.

Ein Zeitplan zum Nachmachen

Nichts davon ist für sich genommen schwierig. Migrationen gehen schief, weil die Schritte auf einen einzigen Abend zusammengepresst werden, an dem die TTL noch nicht abgelaufen ist, das Zertifikat nicht getestet wurde und der Rollback nicht aufgeschrieben ist. Über eine Woche verteilt sind es pro Tag zwanzig Minuten Arbeit.

Wie Migrationen wirklich schiefgehen

Nicht durch die Kopie. Durch die Dinge, die nie auf der Festplatte waren, und die Dinge, die doppelt liefen.

• Beide Server schreiben gleichzeitig — das Split-Brain-Fenster, und der einzige Fehlschlag hier ohne saubere Lösung. Verhindert wird das durch Reihenfolge, nicht durch Werkzeuge: erst den alten stoppen, dann den neuen starten.
• Timer, die auf beiden Maschinen laufen — so bekommen Kunden von allem zweimal etwas. Deaktivieren Sie die alten vor der finalen Synchronisation, nicht danach.
• Eine TTL, die nie gesenkt wurde, macht aus einer Fünf-Minuten-Umschaltung einen tagelangen Schwanz, für den niemand Personal eingeplant hat.
• Dateibesitz, der falsch ankommt, weil die numerischen IDs zwischen den Maschinen abweichen — die Anwendung startet und kann dann nicht in ihr eigenes Upload-Verzeichnis schreiben.
• Ein Zertifikat, das nach dem Wechsel erledigt werden sollte, trifft auf einen HSTS-Header, der Besuchern keine Möglichkeit lässt fortzufahren.
• Eine Adresse, die irgendwo fest codiert ist, das Sie nicht kontrollieren — eine Partner-Integration, eine Firewall-Regel, ein DNS-Eintrag für eine Subdomain, von der Sie vergessen hatten, dass es sie gibt.
• Den alten Server am Tag des Umzugs zu kündigen — das nimmt den Rollback-Weg genau in dem Moment, in dem die Statistik sagt, dass Sie ihn am wahrscheinlichsten brauchen werden.