VPS umziehen, ohne dass es jemand merkt

Ein Serverumzug scheitert selten am Kopieren. Er scheitert daran, dass ein Dienst eine feste IP-Adresse in einer Konfigurationsdatei stehen hatte, dass ein Zertifikat nicht mitkam oder dass die DNS-Änderung bei einem Teil der Besucher zwei Tage brauchte.

Der folgende Ablauf verhindert das. Er kostet etwa eine Woche Vorlauf, davon zehn Minuten Arbeit.

Eine Woche vorher: TTL senken#

Die Zeit, die eine DNS-Änderung braucht, ist keine Naturkonstante: Sie steht in deiner Zone. Ein Eintrag mit 86400 Sekunden TTL liegt bei den Auflösern der Welt einen ganzen Tag im Zwischenspeicher, und der Zähler beginnt erst, wenn sie ihn geholt haben.

# Aktuellen Wert ansehen
dig +noall +answer +ttlid example.com A

Also: mindestens einen alten TTL-Zeitraum vor dem Umzug den Wert auf 300 Sekunden senken. Nach dem Umzug wieder hochsetzen, ein dauerhaft niedriger TTL kostet Antwortzeit bei jedem Besuch.

Bestandsaufnahme: was läuft hier eigentlich?#

Der Teil, den alle unterschätzen. Drei Befehle, deren Ausgabe du dir wegspeicherst:

systemctl list-units --type=service --state=running
ss -tlnp                       # wer lauscht auf welchem Port
crontab -l; ls /etc/cron.*     # was läuft zeitgesteuert

Dazu die Dinge, die in keiner Prozessliste stehen:

Zertifikate und wie sie erneuert werden
Mailversand, SPF-Einträge, die die alte IP nennen, Absender-Freigaben beim Anbieter
Feste IP-Adressen in Konfigurationen, Firewall-Regeln fremder Systeme, API-Freigaben
Reverse-DNS der alten Adresse
Überwachung, die auf die alte IP zeigt

# Wo steht die alte IP überall?
grep -rn "203.0.113.10" /etc /opt /srv /home 2>/dev/null | grep -v Binary

Die IP-Adresse hängt an mehr als am DNS

Firewall-Freigaben bei Partnern, Zahlungsdienstleistern, APIs mit IP-Beschränkung, Mail-Reputation: All das hängt an der Adresse, nicht am Namen. Diese Freischaltungen brauchen Vorlauf, teils Tage. Sie sind der häufigste Grund, warum ein technisch fertiger Umzug trotzdem warten muss.

Zweimal synchronisieren#

Der erste Durchlauf dauert lange und passiert im laufenden Betrieb. Der zweite dauert Minuten und passiert im Wartungsfenster.

# Durchgang 1, Tage vorher — alles außer Datenbanken
rsync -aHAX --numeric-ids --info=progress2 \
  --exclude=/proc --exclude=/sys --exclude=/dev \
  /srv/ neu:/srv/

# Durchgang 2, im Fenster — nur noch die Unterschiede
rsync -aHAX --numeric-ids --delete /srv/ neu:/srv/

-H (harte Verweise), -A (ACLs), -X (erweiterte Attribute) und --numeric-ids sind kein Zierrat: Ohne sie kommen Rechte und Eigentümer verschoben an, und das fällt erst auf, wenn ein Dienst nicht startet.

Datenbanken werden nicht mit rsync kopiert. Entweder Dump im Fenster oder, bei großen Beständen, vorher eine Nachbildung aufsetzen und im Fenster nur umschalten. Die Verfahren stehen in Datenbank sichern und wirklich zurückspielen.

Vor dem Umschalten: den neuen Server testen, ohne DNS#

Der neue Server lässt sich vollständig prüfen, bevor irgendein Besucher darauf landet. Trage die neue IP lokal in /etc/hosts ein:

198.51.100.20  example.com www.example.com

Dann durchklicken wie ein Kunde: Anmeldung, Bezahlvorgang, Datei-Upload, Mailversand. Was hier auffällt, kostet nichts. Dasselbe eine Stunde später zu finden, kostet Kunden.

# Zertifikat schon da? (ohne DNS-Änderung prüfbar)
curl -sv --resolve example.com:443:198.51.100.20 https://example.com/ 2>&1 | grep -E "subject|expire"

Das Fenster#

Ankündigen, falls jemand betroffen ist.
Schreibzugriffe stoppen, Dienst auf dem alten Server anhalten oder in einen Lesemodus schalten. Solange beide Server schreiben, entstehen zwei Wahrheiten, und das ist die einzige Sorte Fehler, die sich nachher nicht mehr sauber zusammenführen lässt.
Letzter rsync-Durchlauf, letzter Datenbank-Dump.
DNS umstellen (A und AAAA, nicht nur A).
Neuen Server starten, Protokolle beobachten.
Alten Server laufen lassen, nicht abschalten.

# Kommt schon Verkehr an?
journalctl -u caddy -f
tail -f /var/log/nginx/access.log

Danach#

Reverse-DNS für die neue Adresse setzen, besonders bei Mailversand.
TTL wieder hochsetzen, wenn alles läuft.
Alten Server 7 bis 14 Tage behalten. Er ist der Rückweg, und er zeigt in seinen Protokollen, wer noch die alte Adresse benutzt.
Erst danach löschen und vorher prüfen, dass nichts mehr ankommt.

Der Rückweg ist Teil des Plans

Ein Umzug ohne Rückweg ist ein Sprung. Solange der alte Server steht und die Daten dort noch vollständig sind, kostet ein Zurück eine DNS-Änderung. Ist er abgeschaltet, kostet es eine Wiederherstellung, deshalb steht das Löschen am Ende und nicht in der Mitte.

Häufige Fragen#

Wie lange dauert die DNS-Umstellung wirklich?#

Bei sauber gesenkter TTL sind die meisten Auflöser in Minuten umgestellt. Ein Rest hält sich länger, manche Zwischenspeicher ignorieren kurze TTLs. Deshalb der alte Server als Auffangnetz.

Kann ich die alte IP mitnehmen?#

Innerhalb eines Anbieters manchmal, zwischen Anbietern praktisch nie. Plane damit, dass sich die Adresse ändert.

Was ist mit Mail?#

Der empfindlichste Teil. Neue IP heißt neue Reputation, und SPF-Einträge, die die alte Adresse nennen, gehören angepasst. Wer selbst zustellt, plant dafür einen eigenen Abschnitt ein, eigener Mailserver erklärt, was daran hängt.

Geht das auch ohne Wartungsfenster?#

Für lesende Dienste ja: beide Server parallel betreiben, DNS langsam umstellen. Sobald geschrieben wird, brauchst du entweder ein Fenster oder eine gemeinsame Datenbank, sonst hast du zwei Datenstände.

Und wenn ich die ganze Maschine kopieren will?#

Bei gleichem Virtualisierer geht ein Abbild-Umzug. Er nimmt aber alles mit, auch die alten Fehler. Ein Neuaufbau mit gezielt kopierten Daten ist mehr Arbeit und danach sauberer, der gute Zeitpunkt für die erste Stunde auf frischer Maschine.

Kurz gesagt#

TTL eine Woche vorher senken, danach wieder hoch.
Bestandsaufnahme inklusive Zertifikate, Cron, SPF und fremder IP-Freigaben.
rsync -aHAX --numeric-ids zweimal, Datenbanken getrennt.
Mit /etc/hosts testen, bevor DNS umgestellt wird.
Alten Server ein bis zwei Wochen stehen lassen, er ist der Rückweg.