Server-Umzug ohne Downtime: Ablauf mit TTL und Proxy

Die meisten Umzüge, die Ausfälle verursachen, scheitern nicht an der Technik auf dem neuen Server. Sie scheitern daran, dass DNS-Caches den alten Server noch stundenlang mit Besuchern versorgen, während der schon abgeschaltet ist. Oder daran, dass in dieser Zeit Bestellungen auf dem alten Server eingehen, die nie auf dem neuen ankommen. Beides lässt sich vorher planen.

Server-Umzug ohne Downtime: die Idee

Zwei Server laufen eine Weile parallel. Der neue übernimmt, sobald DNS umgestellt ist. Der alte nimmt alles an, was noch von veralteten Caches zu ihm kommt, und reicht es an den neuen weiter. Damit gibt es zu keinem Zeitpunkt einen Server, der nicht antwortet, und alle Schreibzugriffe landen an einer Stelle.

Schritt 1: TTL rechtzeitig senken

Prüfe die aktuelle TTL beim autoritativen Server:

dig NS example.com +short
dig @ns1.example-dns.net example.com A +noall +answer

example.com.		86400	IN	A	198.51.100.7

Bei 86400 senkst du mindestens 24 Stunden vor dem Umzug auf 300. Das gilt für jeden Eintrag, der eine IP des alten Servers enthält: Hauptdomain, www (falls kein CNAME), Subdomains, mail. Warum es auf den alten Wert ankommt, steht im Artikel zur DNS-TTL. Bei betadomain stellst du die TTL im Kundenbereich pro Eintrag um.

Schritt 2 und 3: neuen Server aufbauen und Daten übertragen

Installiere auf dem neuen Server dieselben Versionen von Webserver, Laufzeit und Datenbank. Dann die Dateien:

rsync -aHAX --numeric-ids --info=progress2 \
  /var/www/ [email protected]:/var/www/
rsync -aHAX --numeric-ids \
  /etc/nginx/ [email protected]:/etc/nginx/
rsync -aHAX --numeric-ids \
  /etc/letsencrypt/ [email protected]:/etc/letsencrypt/

-H erhält Hardlinks, -A und -X ACLs und erweiterte Attribute, --numeric-ids verhindert, dass Dateien wegen abweichender Benutzernamen falsche Besitzer bekommen. Das Verzeichnis /etc/letsencrypt ziehst du komplett mit, damit Symlinks unter live/ und die Renewal-Konfiguration erhalten bleiben. Die Erneuerung funktioniert danach erst, wenn DNS auf den neuen Server zeigt. Bis dahin kann sie auf beiden Servern harmlos fehlschlagen, bei 90-Tage-Zertifikaten ist reichlich Puffer.

Die Datenbank kommt als erster Dump herüber, damit du testen kannst:

mysqldump --single-transaction --routines example_db | ssh [email protected] mysql example_db
pg_dump -Fc example_db | ssh [email protected] pg_restore -d example_db --clean --if-exists

Für große Datenbanken lohnt sich eine Replikation vom alten zum neuen Server. Dann ist die Schreibpause beim Umschalten nur wenige Sekunden lang.

Schritt 4: testen, ohne DNS anzufassen

curl -sI --resolve example.com:443:192.0.2.20 https://example.com
curl -s --resolve example.com:443:192.0.2.20 https://example.com/health

Damit sprichst du den neuen Server unter dem echten Namen an, mit gültigem Zertifikat. Klick dich zusätzlich im Browser durch, mit einem temporären Eintrag in /etc/hosts. Prüfe Logins, Uploads, Formulare, Cronjobs.

Schritt 5: letzter Abgleich und Umstellung

1. Anwendung auf dem alten Server in den Wartungs- oder Nur-Lesen-Modus setzen.
2. Letzter rsync mit --delete und letzter Datenbank-Dump.
3. A- und AAAA-Records auf die neue IP setzen.
4. Sofort mit Schritt 6 weitermachen.

Die Pause dauert bei kleinen Projekten wenige Minuten. Mit dig @1.1.1.1 example.com A +short siehst du, wann die großen Resolver die neue IP liefern. Mehr zum Verhalten der Caches unter DNS-Propagation.

Schritt 6: der alte Server wird zum Proxy

Das ist der Teil, der den Unterschied macht. Auf dem alten Server ersetzt du den location-Block durch eine Weiterleitung an die neue IP:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass https://192.0.2.20;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_ssl_server_name on;
        proxy_ssl_name $host;
    }
}

proxy_ssl_server_name on sorgt dafür, dass der neue Server beim TLS-Handshake den richtigen Namen per SNI bekommt. Jeder Besucher, der wegen eines alten Caches noch beim alten Server landet, wird transparent bedient, und alle Daten landen in der neuen Datenbank. Der Nachteil: Die Anwendung sieht diese Anfragen mit der IP des alten Servers, es sei denn, sie wertet X-Forwarded-For aus. Ein Muster mit mehreren Domains hinter einem Proxy zeigt Reverse Proxy für mehrere Domains.

Schritt 7: beobachten und abschalten

tail -f /var/log/nginx/access.log

Läuft auf dem alten Server ein, zwei Tage lang nichts mehr ein außer Bots, die direkt die IP ansprechen, schaltest du ihn ab. Danach die TTL wieder auf 3600 anheben.

Was beim Umzug gern vergessen wird

Die alte IP steckt an mehr Stellen als im A-Record. Vor dem Abschalten lohnt eine Suche:

grep -rn "198.51.100.7" /etc /var/www /opt 2>/dev/null

Typische Fundstellen und Nebenschauplätze:

• SPF-Record mit ip4:198.51.100.7 statt mx. Ohne Anpassung landen Mails vom neuen Server im Spam.
• Allowlists bei Dritten, etwa Zahlungsanbieter-Webhooks, externe Datenbanken oder APIs, die nur bestimmte Quell-IPs zulassen.
• Cronjobs und systemd-Timer, die auf dem alten Server weiterlaufen und doppelt Mails verschicken oder Daten verarbeiten. Auf dem alten Server nach der Umstellung deaktivieren.
• Backups, deren Ziel oder Quelle per IP konfiguriert ist.
• Monitoring, das noch die alte Adresse prüft und deshalb grün meldet, während der neue Server ausfällt.

Mailserver beim Umzug

Läuft Postfix mit um, kommen zwei Dinge dazu. Der PTR-Record der neuen IP muss vor der Umstellung beim Hoster gesetzt sein. Und der alte Server sollte bis zum Ablauf der MX-TTL weiter Mail annehmen, die du anschließend per imapsync überträgst. Absender, die zwischendurch eine temporäre Ablehnung bekommen, versuchen es später erneut. Details zu den Einträgen stehen unter MX-Record einrichten.

Nächster Schritt

Notier dir heute die TTLs aller Einträge, die auf deinen Server zeigen. Ziehst du dabei auf eine neue Domain um, kannst du die neue Adresse bei betadomain registrieren, zum Beispiel eine .com zum festen Jahrespreis von 14,99 €. Weitere Grundlagen zu Domains findest du im Ratgeber von betadomain.

Schritt für Schritt

1. TTL senkenMindestens eine alte TTL vor dem Umzug die TTL aller betroffenen A-, AAAA- und gegebenenfalls MX-Records auf 300 Sekunden setzen.
2. Neuen Server aufsetzenPakete, Webserver, Anwendung und Firewall auf dem neuen Server installieren und konfigurieren.
3. Daten und Zertifikate synchronisierenWebroot, Konfiguration und /etc/letsencrypt per rsync -aHAX übertragen, Datenbank per Dump oder Replikation.
4. Mit curl --resolve testenDen neuen Server mit curl --resolve example.com:443:Neue-IP https://example.com prüfen, ohne DNS zu ändern.
5. Letzter Abgleich und DNS umstellenKurze Schreibpause, finaler rsync und Datenbank-Abgleich, dann A- und AAAA-Records auf die neue IP setzen.
6. Alten Server als Proxy nutzenAuf dem alten Server nginx so umkonfigurieren, dass er alle Anfragen an die neue IP durchreicht.
7. AufräumenNach ein bis zwei Tagen ohne Traffic auf dem alten Server die TTL wieder auf 3600 setzen und den alten Server abschalten.