Ihren VPS ohne Ausfallzeit zu einem neuen Anbieter umziehen

Jede Umzugs-Horrorgeschichte hat denselben Mittelteil: Jemand hat zuerst das DNS geändert und dann mit dem Kopieren angefangen. Ausfallzeit bei einem Umzug liegt fast nie daran, dass das Kopieren langsam ist. Sie liegt an der falschen Reihenfolge der Schritte.

Hier ist die Reihenfolge, die funktioniert, egal ob Sie einen anderen Anbieter verlassen oder zwischen zwei unserer Tarife wechseln.

1. Zwei Tage vorher: die TTL senken

Suchen Sie die DNS-Einträge, die Sie ändern werden (meist A, AAAA und alle CNAME, die darauf zeigen), und senken Sie ihre TTL auf 300 Sekunden. Warten Sie dann mindestens so lange, wie die alte TTL war. Ein Eintrag mit einer TTL von einem Tag bedeutet, dass manche Resolver die alte Adresse noch einen Tag nach der Änderung ausliefern, und nichts, was Sie auf dem Server tun, beschleunigt das.

Diesen Schritt lassen die Leute aus, und genau er macht aus einem Fünf-Minuten-Wechsel einen Tag, an dem die Hälfte der Nutzer den alten Server sieht.

2. Bestandsaufnahme des alten Servers

Sie werden diese Maschine anderswo neu aufbauen, also schreiben Sie auf, was sie tatsächlich tut. Nicht, was Sie in Erinnerung haben. Was sie tut:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Ergänzen Sie die Liste: die TLS-Zertifikate und wie sie erneuert werden, Umgebungsdateien mit Geheimnissen, Firewall-Regeln, Benutzer und ihre SSH-Schlüssel, die Datenbank und ihre Größe, und alles, was den Server per IP-Adresse anspricht. Die letzte Gruppe ist die heimtückische: die Allowlist eines Partners, die Webhook-Einstellungen eines Zahlungsanbieters, ein Monitoring-Check.

3. Den neuen Server neben dem alten aufbauen

Bestellen Sie den neuen Server und lassen Sie den alten in Ruhe. Wählen Sie einen Tarif aus der VPS-Liste mit gleich viel oder mehr Festplatte, als Sie tatsächlich nutzen, nicht als Ihnen verkauft wurde. Bekommt die alte Maschine überhaupt eingehenden Traffic (eine Website, Webhooks, eine API), braucht die neue eine eigene IPv4. Ein NAT-Tarif nimmt eingehende Verbindungen nur auf seinem SSH-Port an, und was ein weitergeleiteter Port kann und was nicht erklärt, warum das wichtig ist.

Verbinden Sie sich, installieren Sie dieselben Pakete, legen Sie Benutzer und Firewall neu an. Der Verbindungsleitfaden behandelt Schlüssel und die erste Anmeldung.

4. Die Dateien zweimal synchronisieren

Die erste Synchronisation kopiert alles, während der alte Server weiterarbeitet. Sie kann Stunden dauern; das ist in Ordnung.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids behält die Dateibesitzer nach Nummer bei, was die klassische Überraschung „alles gehört dem falschen Benutzer“ vermeidet, wenn die beiden Systeme Benutzer in unterschiedlicher Reihenfolge angelegt haben. Wenn Sie rsync über SSH noch nie benutzt haben, führt Dateien auf einen VPS übertragen Schritt für Schritt durch.

Die zweite Synchronisation, direkt vor dem Wechsel, kopiert nur, was sich seit der ersten geändert hat. Meist dauert sie Sekunden.

5. Die Datenbank bewusst umziehen

Dateien sind einfach. Eine Datenbank, die Schreibzugriffe annimmt, ist der eine Teil, bei dem „ohne Ausfallzeit“ entweder einen kleinen Kompromiss oder mehr Arbeit erfordert.

Der einfache Weg: einmal zum Testen dumpen und wiederherstellen, dann beim Wechsel für eine Minute die Schreibzugriffe stoppen (die App in den Nur-Lese-Modus versetzen oder anhalten), einen frischen Dump ziehen, ihn auf dem neuen Server einspielen und die App dort starten. Für die meisten kleinen Projekte ist das eine Pause von ein, zwei Minuten, vorher angekündigt.

Der Weg ohne Pause: eine Replikation von der alten zur neuen Datenbank einrichten, aufholen lassen und beim Wechsel die neue zur primären machen. Mehr Einrichtung, und es lohnt sich, wenn selbst eine Minute verlorener Schreibzugriffe nicht akzeptabel ist.

6. Den neuen Server testen, bevor ihn jemand anderes sieht

Das DNS zeigt noch auf den alten Server, Sie können den neuen also ungestört testen. Schicken Sie eine Anfrage für Ihre echte Domain an die neue Adresse:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Ist das Zertifikat noch nicht da, testen Sie auf dieselbe Weise über HTTP, oder fügen Sie eine vorübergehende Zeile in Ihre hosts-Datei ein und klicken sich im Browser durch die Seite. Prüfen Sie Logins, Uploads, Hintergrund-Jobs und ausgehende E-Mails. Billiger lässt sich eine fehlende PHP-Erweiterung nicht finden.

7. Umschalten und den alten Server weiterlaufen lassen

Machen Sie die letzte Dateisynchronisation und den Datenbankschritt, dann ändern Sie die DNS-Einträge. Mit einer TTL von 300 Sekunden wandert der Großteil des Traffics innerhalb von Minuten. Beobachten Sie das Access-Log des alten Servers: Von Resolvern und Clients, die die TTL ignorieren, kommt dort noch ein Rinnsal an. Lassen Sie ihn ein paar Tage unverändert laufen. Aktualisieren Sie danach alles, was auf die alte IP zeigt: Partner-Allowlists, Webhook-URLs und für E-Mail den Reverse DNS der neuen Adresse (bei unseren Tarifen mit dedizierter IP setzen Sie ihn selbst, siehe Reverse DNS) sowie Ihren SPF-Eintrag.

Was am häufigsten kaputtgeht

Ungefähr in der Reihenfolge, wie oft wir es sehen: ein systemd-Timer, den niemand aufgelistet hat, eine Konfigurationsdatei mit fest eingetragener alter IP, Dateien, die dem falschen Benutzer gehören, eine Firewall, die den eigenen Port der App blockiert, ein Zertifikat, das auf dem alten Server erneuert wird, aber nicht auf dem neuen, und E-Mails, die im Spam landen, weil die neue Adresse noch keinen Reverse DNS hat.

Wo diese Checkliste nicht passt

Eine stark beschriebene Datenbank, die keine Pause verträgt, braucht eine richtige Replikation und eine Generalprobe, keine Blog-Checkliste. Windows-Server ziehen mit anderen Werkzeugen um als rsync. Und wenn es beim Umzug eigentlich um die Größe geht, lesen Sie zuerst das: Tarife wachsen hier direkt. Der Wechsel auf einen größeren Tarif desselben Netzwerktyps fügt vCPU, RAM und Festplatte mit einem Neustart hinzu, ganz ohne Umzug. Nur zum Verkleinern braucht es einen neuen Server. Wenn Sie umziehen, weil Sie nicht sicher sind, ob die Maschine groß genug ist, erspart Ihnen Wann Sie wirklich 64 GB RAM brauchen vielleicht die Reise, und VPS, Shared Hosting, dedizierter Server oder Cloud hilft, wenn Sie unsicher sind, ob ein VPS überhaupt das richtige Zuhause ist.