Einen VPS ohne Ausfallzeit auf einen neuen Host migrieren

Die drei Uhren, und warum „null Ausfallzeit“ das falsche Ziel ist#

Was der alte Host behält, nachdem Sie gegangen sind#

Die TTL-Uhr beginnt eine Woche vor dem Umzug#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

Die neue Box dimensionieren, und was Sie prüfen sollten, bevor Sie sich festlegen#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

Schritt für Schritt#

1. Jede TTL senken, Tage bevor Sie den Umzug planen

   Das steht an erster Stelle, weil es der einzige Schritt mit einer zwingenden Wartezeit ist. Alles andere lässt sich an einem Nachmittag erledigen; dieser hier lässt sich nicht beschleunigen, und ihn zu überspringen ist es, was aus einer Fünf-Minuten-Umschaltung eine Zwei-Tage-Umschaltung macht.

   Loggen Sie sich dort ein, wo Ihre Zone liegt, und setzen Sie die TTL auf 300 bei jedem Record, der sich ändern wird: das Apex-A, das AAAA, www, mail, und alles andere, was auf ein IP-Literal zeigt. Bestätigen Sie es dann von außen, denn Kontrollpanels und Realität sind sich manchmal uneinig:

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   Die Zahl vor IN ist die verbleibende TTL. Fragen Sie eine Minute später erneut ab: Sie sollte von 300 herunterzählen, nicht von etwas Größerem. Zählt sie immer noch von 3600 herunter, ist der alte Wert zwischengespeichert und Sie müssen es aussitzen — genau deshalb passiert das an Tag minus sieben und nicht am Morgen des Umzugs.

   Lassen Sie die TTL während der Migration und eine Woche danach auf 300, damit Ihr Rollback ebenfalls schnell ist. Setzen Sie sie wieder auf etwas Vernünftiges zurück — 3600 ist in Ordnung —, sobald die alte Box weg ist.

2. Den alten Server inventarisieren, bevor Sie irgendetwas kopieren

   Sie migrieren keine Festplatte, Sie migrieren ein laufendes System, und die Teile, die man vergisst, liegen nie in /var/www. Es sind der Cronjob, der am vierten des Monats läuft, die Firewall-Regel, die während eines Vorfalls hinzugefügt wurde, das Paket, das vor zwei Jahren aus einem Drittanbieter-Repository installiert wurde. Erfassen Sie den Zustand der Maschine als Text, und kopieren Sie diesen Text mit allem anderen hinüber:

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   Lesen Sie nun listening.txt Zeile für Zeile und klären Sie jeden Port. Diese Datei ist die endgültige Antwort auf „was macht dieser Server eigentlich“, und sie hält routinemäßig eine Überraschung bereit — ein Metrics-Exporter, eine vergessene Staging-Kopie, eine Datenbank, die auf einem öffentlichen Interface lauscht, was sie nie hätte tun sollen.

   Schreiben Sie gleichzeitig Ihre Exclude-Liste, damit der erste Sync nicht eine Stunde mit Daten verbringt, die Sie gar nicht wollen:

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   Beachten Sie, dass die Datenbankverzeichnisse absichtlich ausgeschlossen sind. Sie bekommen ihren eigenen Schritt, und sie hier mit hineinzukopieren ist genau der Fehler, den Schritt sechs verhindern soll.

3. Den neuen Server aufsetzen und härten, bevor er irgendetwas enthält

   Bestellen Sie die Box, wählen Sie den Standort und nehmen Sie, wenn möglich, dieselbe OS-Hauptversion wie beim alten Server. Gleichzeitig den Host zu wechseln und von Debian 12 auf Debian 13 zu wechseln bedeutet, dass Sie nicht wissen, welche Änderung schuld war, wenn etwas kaputtgeht. Erst umziehen, später upgraden.

   Bevor irgendetwas Sensibles darauf landet, geben Sie der Maschine den zehnminütigen Härtungsdurchgang: ausschließlich Schlüssel-SSH, Root-Login deaktiviert, eine Default-Deny-Firewall, unbeaufsichtigte Sicherheitsupdates. Das dauert jetzt zehn Minuten und ist später, rund um einen laufenden Dienst herum, echt mühsam nachzuholen.

   Erstellen Sie dann einen Schlüssel, der nur für diese Migration existiert, auf dem alten Server, sodass der spätere Entzug des Migrationszugriffs nie bedeutet, Ihren eigenen Login anzufassen:

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   Legen Sie diesen öffentlichen Schlüssel in /root/.ssh/authorized_keys auf dem neuen Server ab, und bestätigen Sie dann die Reiserichtung — alt drückt zu neu, sodass das Credential auf der Maschine lebt, die Sie verlassen, und mit ihr stirbt:

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   Tragen Sie schließlich die neue IP in die /etc/hosts des alten Servers ein, unter einem Namen wie newbox. Jeder folgende Befehl wird kürzer und, nützlicherweise, schwerer um ein Uhr nachts auf die falsche Maschine zu richten.

4. Die neue IP prüfen, bevor Sie ihr irgendetwas anvertrauen

   Sie haben jetzt eine Adresse, die noch nie jemand für Ihren Dienst benutzt hat, und das ist der letzte Moment, in dem ein Problem damit zu finden nichts kostet. Drei Checks, fünf Minuten:

   Blocklisten. Prüfen Sie die Adresse gegen die Multi-RBL-Checks — das vollständige Verfahren und wie man die Ergebnisse liest, steht hier. Ein Treffer auf einer Policy-Liste wie der Spamhaus PBL ist normal für eine Rechenzentrums-IP und bedeutet wenig für Web-Traffic. Ein Treffer auf SBL oder XBL ist ein echter, und der richtige Zeitpunkt, ihn zu melden, ist jetzt, nicht nachdem Ihre Nutzer schon darauf sind.

   Reverse-DNS. Prüfen Sie, worauf die Adresse heute antwortet:

   dig +short -x NEW_IP

   Wenn die Box Mail versenden wird, fordern Sie den gewünschten PTR-Record an und stellen Sie sicher, dass er zu einem Hostnamen passt, dessen A-Record wieder zurück auf dieselbe IP zeigt. Vorwärts und Rückwärts müssen übereinstimmen; ein Mismatch ist schlimmer als ein generischer Name.

   Erreichbarkeit und Route. Bestätigen Sie, dass die benötigten Ports tatsächlich durchgängig offen sind, von außen, statt anzunehmen, dass Ihre Firewall das Einzige auf dem Weg ist:

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   Die mtr-Ausgabe ist die, die es aufzuheben lohnt. Verlust am letzten Hop zählt; Verlust an einem Zwischen-Hop ist meist ein Router, der ICMP herabstuft, und bedeutet nichts. Wenn die Latenz aus der Weltgegend Ihrer Nutzer spürbar schlechter ist als beim alten Host, besser jetzt herausfinden, solange es Sie, Ihre Meinung zu ändern, nur eine Bestellung kostet und keine Daten.

5. Das Dateisystem mit rsync kopieren — und zuerst einen Dry-Run machen

   Jetzt die Massenübertragung. Machen Sie es in zwei Durchgängen: eine erste vollständige Kopie Tage vorher, die so lange dauert, wie sie eben dauert, dann später kurze Delta-Durchgänge, die nur bewegen, was sich geändert hat. Immer zuerst einen Dry-Run machen — die Ausgabe ist eine Liste von genau dem, was gleich passieren wird, und sie einmal zu lesen hat mehr Migrationen gerettet als jede andere Gewohnheit hier.

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   Dann derselbe Befehl ohne --dry-run. Wiederholen Sie ihn für jedes Verzeichnis, das wichtig ist: /etc selektiv statt vollständig, /home, /srv, /opt, und wo auch immer Ihre Anwendung tatsächlich ihre Uploads aufbewahrt.

   Die Flags verdienen ihren Platz. -a erhält Rechte, Eigentümerschaft, Zeitstempel und Symlinks; -H behält Hardlinks bei; -A und -X übertragen ACLs und erweiterte Attribute, was Ihr Upload-Verzeichnis braucht, falls dort je welche gesetzt wurden; -x hindert rsync daran, in andere eingehängte Dateisysteme abzudriften. --numeric-ids ist das, was Leute weglassen und bereuen: Ohne es ordnet rsync Eigentümerschaft per Name zu, und wenn www-data auf den beiden Boxen eine unterschiedliche UID hat, landet jede Datei beim falschen Benutzer, auf eine Weise, die mühsam zu entwirren ist.

   Zwei Warnungen. /etc vollständig auf ein laufendes System zu kopieren, überschreibt die Netzwerkkonfiguration der neuen Maschine, ihre fstab und ihre SSH-Host-Keys — kopieren Sie die konkrete Konfiguration, die Sie brauchen, nicht das Verzeichnis. Und heben Sie sich --delete für den letzten Durchgang auf: Es ist richtig, um die neue Box exakt an die alte anzugleichen, und destruktiv, wenn Sie auf dem Ziel schon etwas angelegt haben.

   Wenn der erste vollständige Durchgang fertig ist, vergleichen Sie beide Seiten, damit Sie wissen, dass er getan hat, was Sie denken:

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. Die Datenbank per Dump verschieben, nie per Dateikopie

   Das ist der Schritt, der entscheidet, ob Ihre Migration langweilig oder unvergesslich wird. Das Datenverzeichnis einer Datenbank ist nur konsistent, wenn der Server gestoppt ist. Kopieren Sie es live, bekommen Sie einen Satz Dateien, die gut aussehen, sich gut übertragen lassen und sich zu einer Datenbank wiederherstellen, die subtil und dauerhaft beschädigt ist — oft ohne Fehlermeldung, bis Wochen später.

   Dumpen Sie sie richtig. Für MySQL oder MariaDB gibt Ihnen --single-transaction einen konsistenten Snapshot, ohne das Ganze zu sperren:

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   Für PostgreSQL lohnt sich das Custom-Format — es komprimiert, und es erlaubt Ihnen, bei Bedarf selektiv wiederherzustellen:

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   Übertragen Sie es und stellen Sie wieder her:

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   Verifizieren Sie dann, denn „die Wiederherstellung ist fertig“ und „die Daten sind da“ sind unterschiedliche Aussagen. Vergleichen Sie die Zeilenzahlen der wichtigen Tabellen auf beiden Seiten:

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   Zwei Dinge, die sich in Dumps verstecken: der Zeichensatz und die Collation, woher verstümmelte Umlaute und Akzentzeichen kommen — wenn die alte Datenbank auf utf8 statt utf8mb4 läuft, entscheiden Sie bewusst, ob der Umzug auch der Moment ist, das zu reparieren; und die Datenbank-Nutzer und -Rechte, die mysqldump --databases nicht einschließt. Legen Sie den Nutzer und das Passwort der Anwendung auf der neuen Box explizit neu an, und denken Sie dann daran, dass der Connection-String in Ihrer Konfiguration dazu passen muss.

   Wenn Ihre Anwendung SQLite verwendet, ist die Datei die Datenbank, und dieselbe Regel gilt — kopieren Sie sie nicht live. Verwenden Sie sqlite3 app.db ".backup /root/mig/app.db", was sicher eine konsistente Kopie erstellt.

7. Den Stack hochfahren und ihn hinter einem Hosts-Datei-Override proben

   Der neue Server hat jetzt die Dateien und die Daten. Starten Sie alles und testen Sie es unter seinem echten Hostnamen — während der Rest der Welt weiterhin munter die alte Box benutzt. Das ist der wertvollste Trick im ganzen Verfahren, und er kostet eine Zeile.

   Fügen Sie auf Ihrem eigenen Laptop die IP des neuen Servers zu /etc/hosts hinzu (oder C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10   example.com www.example.com

   Ihr Browser löst die echte Domain jetzt zum neuen Server auf, und der von sonst niemandem tut das. Jede URL stimmt, jede Cookie-Domain passt, jeder Redirect- und Callback-Pfad verhält sich so, wie er es nach der Umschaltung tun wird — genau das, was ein Test gegen eine temporäre new.example.com-Subdomain nicht erfassen kann, weil die Hälfte dessen, was bei einer Migration kaputtgeht, hostnamenabhängig ist.

   Für einen einzelnen schnellen Check, ohne irgendetwas zu bearbeiten, kann curl dasselbe inline erledigen:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   Gehen Sie die gesamte Anwendung durch, nicht nur die Startseite: einloggen, ein Formular abschicken, eine Datei hochladen, eine Passwort-Reset-Mail auslösen, eine Admin-Seite laden, den Endpunkt treffen, den ein Zahlungsdienstleister aufruft. Lesen Sie dann die Error-Logs, selbst wenn alles gut aussah — fehlende PHP-Erweiterungen, ein falscher Dateimodus auf einem Cache-Verzeichnis und ein Datenbank-Nutzer, den es noch nicht gibt, tauchen dort alle auf, bevor sie auf dem Bildschirm auftauchen.

   Denken Sie daran, die Hosts-Zeile hinterher zu entfernen. Jeder vergisst es einmal und verbringt dann zwanzig Minuten damit, sich zu fragen, warum der Rollback offenbar nicht funktioniert hat.

8. TLS auf der neuen Box zum Laufen bringen, bevor Sie irgendetwas umstellen

   Zertifikate sind an Namen gebunden, nicht an IP-Adressen, also macht nichts an einer Migration ein Zertifikat ungültig, das Sie bereits besitzen. Was kaputtgeht, ist die Ausstellung: Die übliche HTTP-01-Challenge bittet Let's Encrypt, eine Datei über Port 80 beim zu zertifizierenden Namen abzurufen, und dieser Name zeigt noch auf den alten Server. Das Henne-Ei-Problem ist die ganze Schwierigkeit, und es gibt drei saubere Wege heraus.

   Die bestehenden Zertifikate kopieren. Am einfachsten und meist richtig. Der private Schlüssel und die Kette wandern wie jede andere Datei:

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   Der neue Server kann sofort gültiges TLS ausliefern, und die Erneuerung fängt von selbst an zu funktionieren, sobald DNS auf ihn zeigt. Bestätigen Sie, dass der Timer dort aktiviert ist: systemctl list-timers | grep certbot.

   Eine DNS-01-Challenge verwenden. Beweist die Kontrolle über die Domain per TXT-Record statt per HTTP-Anfrage, funktioniert also von einem Server aus, auf den noch nichts zeigt. Ideal, wenn Sie vor der Umschaltung ein echt unabhängiges Zertifikat auf der neuen Box wollen, und die einzige Option für ein Wildcard.

   Nach der Umstellung ausstellen. Gültig, hinterlässt aber eine Lücke, in der die Seite live auf der neuen IP steht, ohne Zertifikat, was bei allem mit HSTS keine Warnung ist, die Ihre Besucher wegklicken können. Nur sinnvoll für eine brandneue Domain, die noch niemand besucht hat.

   Für welchen Weg Sie sich auch entscheiden, verifizieren Sie direkt gegen die neue IP vor der Umschaltung, mit demselben --resolve-Trick:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   Prüfen Sie die Daten und dass der Subject jeden Namen abdeckt, den Sie bedienen, www eingeschlossen. Und wenn Sie HSTS mit einer langen Max-Age nutzen, behandeln Sie das Zertifikat als das eine, das vor der Umstellung stimmen muss statt danach — dieser Header ist ein Versprechen, das Sie jedem wiederkehrenden Besucher schon gegeben haben.

9. Die Umschaltung: Schreibvorgänge einfrieren, letztes Delta, den Record umstellen

   Zehn Minuten tatsächliche Arbeit, und der einzige Teil mit einer Uhr darauf. Erledigen Sie es morgens, in Ihrer eigenen Zeitzone, an einem Tag, an dem Sie sonst nicht beschäftigt sind. Nie an einem Freitag.

   Einfrieren. Versetzen Sie die alte Anwendung in den Wartungs- oder Read-only-Modus. Stoppen Sie die Worker, die Queue-Consumer und die Cronjobs — alles, was ohne angeschlossenen Browser schreibt. Ab hier wird nichts Neues mehr auf der alten Box geschrieben, was alles danach sicher macht:

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   Letztes Delta. Noch ein rsync, jetzt mit --delete, damit das Ziel exakt übereinstimmt, und noch ein Dump. Da der erste Durchgang schon Tage zurückliegt, bewegt das sehr wenig und dauert Sekunden:

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   Prüfen. Zeilenzahlen auf beiden Seiten, noch ein Durchgang durch die Anwendung über den Hosts-Datei-Override, und die Wartungs-Flag von der neuen Box entfernen.

   Umstellen. Ändern Sie den A-Record auf die neue IP. Ändern Sie auch den AAAA-Record — das ist mit Abstand die häufigste Art, wie eine Umschaltung nur halb funktioniert. Bestätigen Sie es über einen Resolver, den Sie nicht kontrollieren:

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   Beobachten Sie dann beide Maschinen. Traffic sollte innerhalb ein bis zwei Minuten auf der neuen erscheinen und über die nächsten fünf von der alten abklingen:

   tail -f /var/log/nginx/access.log        # on both, side by side

   Lassen Sie die alte Anwendung im Wartungsmodus, statt sie abzuschalten. Ein Nachzügler, der sie erreicht, sieht eine höfliche Seite statt eines Verbindungsfehlers, und Sie behalten die Maschine verfügbar für den Rollback, den Sie vermutlich nicht brauchen werden.

10. Eine Woche beobachten, dann richtig außer Betrieb nehmen

    Die Migration ist nicht fertig, wenn DNS auflöst. Sie ist fertig, wenn ein vollständiger Abrechnungs- und Cron-Zyklus ohne Überraschung vergangen ist.

    Beobachten Sie in den ersten Stunden Fehlerraten statt Uptime — ein Server kann perfekt erreichbar sein und trotzdem einem Drittel der Anfragen ein 500 zurückgeben:

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    Arbeiten Sie sich dann eine kurze Liste entlang, denn das ist es, was nach einem Umzug tatsächlich kaputtgeht, und nichts davon kündigt sich an: Cronjobs und systemd-Timer, die auf der neuen Box laufen (systemctl list-timers gegen das Inventar, das Sie in Schritt zwei erstellt haben); ausgehende Mail, die ankommt und nicht im Spam landet; geplante Backups, die auf den neuen Server zeigen, statt weiterhin den alten zu archivieren; jeder Dritte mit Ihrer IP-Adresse auf einer Allowlist — ein Zahlungsdienstleister, eine API, die Firewall eines Partners; und der monatliche Job, der sich erst am Ersten des Monats beweist.

    Lassen Sie den alten Server laufen, im Wartungsmodus, unangetastet, für mindestens eine Woche. Er ist Ihr Rollback und Ihre Referenzkopie, und er ist die paar Dollar, die er kostet, allemal wert. Schließen Sie ihn dann der Reihe nach ab: Rotieren Sie jedes Secret, das er lesen konnte, erstellen Sie ein letztes verschlüsseltes Archiv an einem dritten Ort, überschreiben Sie die Anwendungs- und Datenbankverzeichnisse, lassen Sie die Vernichtungs- oder Neuinstallationsroutine des Anbieters laufen, und kündigen Sie erst dann — nachdem Sie das Verlängerungsdatum geprüft haben, denn ein zusätzlicher Monat Rollback-Versicherung ist meist der bessere Tausch.

    Setzen Sie zuletzt die TTL wieder auf 3600 hoch, jetzt, wo Sie die Fünf-Minuten-Umkehrbarkeit nicht mehr brauchen, und aktualisieren Sie, welche Dokumentation Sie auch führen, mit der neuen Adresse. Ihr zukünftiges Ich wird es, irgendwann später um 2 Uhr nachts, extrem zu schätzen wissen, dass das Runbook zum Server passt.

Mail migriert nicht mit dem Rest#

Zurückrollen, ohne es schlimmer zu machen#

Außerbetriebnahme: rotieren, löschen, verifizieren, dann kündigen#

Ein Zeitplan, der funktioniert#

Häufige Fragen#