Zum Inhalt springen
clausvb.de

Hosting-Umzug: Checkliste ohne Ausfallzeit

Die richtige Reihenfolge von DNS, Datenbank und Mailkonten, die TTL-Vorbereitung und der Punkt, an dem die meisten Umzüge tatsächlich scheitern.

Zuletzt geprüft: Gedacht für: Anbieterwechsel mit laufender Seite

Das Wichtigste

  • TTL der DNS-Einträge mindestens 24 Stunden vor dem Umzug senken – sonst sehen Besucher tagelang den alten Server.
  • Die neue Umgebung vollständig testen, bevor DNS umgestellt wird. Die hosts-Datei erlaubt das ohne öffentliche Änderung.
  • Mailkonten sind der aufwändigste Teil und werden regelmässig unterschätzt.
  • Alten Server nach der Umstellung mindestens eine Woche weiterlaufen lassen – sonst gehen Nachzügler verloren.

Ein Hosting-Umzug ist keine schwierige, aber eine reihenfolgeabhängige Aufgabe. Wer die Schritte in der richtigen Ordnung abarbeitet, schafft ihn ohne Ausfall.

Vorbereitung, eine Woche vorher

Bestandsaufnahme. Was läuft alles auf dem alten Hosting? Erfahrungsgemäss mehr, als in der Erinnerung steht:

  • Webseiten und Subdomains
  • Datenbanken
  • Mailkonten, Weiterleitungen, Verteiler
  • Cronjobs
  • FTP- und SSH-Zugänge
  • DNS-Einträge, die nicht zum Webhosting gehören: Verifizierungsschlüssel, SPF, DKIM, DMARC, MX
  • SSL-Zertifikate und deren Erneuerungsmechanismus
  • IP-Freigaben bei Dritten (Zahlungsdienste, APIs, Monitoring)

Der letzte Punkt ist der stille Störer. Ein Zahlungsdienstleister, der nur Anfragen von der alten Server-IP annimmt, fällt erst bei der ersten Bestellung nach dem Umzug auf.

TTL senken. Mindestens 24 Stunden vorher, besser 48:

dig +noall +answer example.com A
# example.com. 86400 IN A 203.0.113.10   <- 86400 = 24 Stunden

Setze die TTL für A-, AAAA- und MX-Einträge auf 300 Sekunden. Die alte, lange TTL muss zuerst ablaufen, bevor die neue kurze überhaupt wirkt – deshalb der zeitliche Vorlauf.

Aufbau der neuen Umgebung

  1. Konto einrichten, PHP-Version und Grenzwerte an die alte Umgebung angleichen.

  2. Dateien übertragen: rsync über SSH, sonst FTP.

  3. Datenbank übertragen:

    mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u alt_user -p alt_db | gzip > umzug.sql.gz

  4. Konfiguration anpassen: Datenbankzugang, Pfade, Mailversand.

  5. Cronjobs anlegen.

  6. TLS-Zertifikat ausstellen – die meisten Anbieter können das vor der DNS-Umstellung über eine DNS-Validierung.

Testen, bevor irgendetwas öffentlich wird

Die hosts-Datei deines Rechners lässt dich die neue Umgebung unter der echten Domain aufrufen, ohne dass sich für Besucher etwas ändert:

# /etc/hosts (macOS, Linux) bzw. C:\Windows\System32\drivers\etc\hosts
203.0.113.99  example.com www.example.com

Jetzt durchgehen:

  • Startseite und mehrere Unterseiten
  • Kontaktformular tatsächlich absenden, Empfang prüfen
  • Login und geschützte Bereiche
  • Bilder, Downloads, Uploads
  • Bei Shops: eine Testbestellung bis zur Zahlung
  • Weiterleitungen aus der .htaccess gegen die echte Alt-URL-Liste

Erst wenn das alles funktioniert, wird DNS angefasst.

Umstellung

  1. Datenbank ein letztes Mal übertragen. Bei laufenden Bestellungen dafür ein kurzes Wartungsfenster setzen.

  2. A- und AAAA-Eintrag auf die neue IP ändern.

  3. MX-Eintrag ändern, falls Mail mit umzieht.

  4. Direkt danach prüfen:

    dig +short example.com A
curl -sI https://example.com/ | head -3

  5. Alten Server nicht abschalten. Er beantwortet weiter Anfragen von Resolvern mit altem Eintrag.

Nacharbeit

Erste Stunde: Erreichbarkeit über einen externen Dienst prüfen, Fehlerlog des neuen Servers beobachten, eine Testmail an eine externe Adresse senden und im Quelltext prüfen, ob SPF und DKIM bestehen.

Erster Tag: Cronjobs kontrollieren, ob sie gelaufen sind. Formulare erneut testen. Bei Shops eine echte Bestellung durchführen.

Erste Woche: Logfile des alten Servers ansehen – kommen dort noch Anfragen an? Solange ja, muss er stehen bleiben. Suchmaschinen-Fehlerberichte auf neue 404 prüfen.

Nach einer Woche: TTL wieder auf einen normalen Wert erhöhen. Alten Vertrag kündigen, aber erst nach einer vollständigen, geprüften Sicherung der alten Umgebung.

Die Fallen, die wirklich zuschlagen

Vergessene Cronjobs. Ein nächtlicher Export, den vor drei Jahren jemand eingerichtet hat und der nirgends dokumentiert ist. Fällt erst auf, wenn ihn jemand vermisst.

Hart kodierte Pfade. /var/www/vhosts/alt/httpdocs/ steht in einer Konfigurationsdatei und existiert auf dem neuen Server nicht.

Mailversand über die Anwendung. Der alte Server hatte eine eingerichtete Absenderdomain, der neue nicht. Die Mails gehen raus und landen im Spam, weil SPF und DKIM nicht mehr passen.

IP-Freigaben bei Dritten. API, Zahlungsdienst, Monitoring – überall dort, wo die alte Server-IP hinterlegt ist, muss die neue nachgetragen werden.

Zertifikatserneuerung. Läuft die ACME-Validierung noch? Wenn der neue Server einen Verzeichnisschutz hat, der auch /.well-known/ abdeckt, schlägt die erste Erneuerung in 60 Tagen fehl – lange nachdem alle den Umzug abgehakt haben.

Häufige Fragen

Wie lange dauert eine DNS-Umstellung?

Die Änderung ist bei der Registry in Minuten sichtbar. Wie schnell Besucher sie sehen, hängt an der TTL des alten Eintrags – Resolver halten ihn bis zum Ablauf. Bei einer TTL von 24 Stunden kann es entsprechend lange dauern.

Was passiert mit Mails während des Umzugs?

Sendende Server versuchen die Zustellung an den MX-Eintrag, den sie gerade sehen. Während der Übergangszeit können das beide Server sein. Deshalb muss das alte Postfach erreichbar bleiben, bis sichergestellt ist, dass nichts mehr dort ankommt.

Kann ich die Datenbank vorab übertragen?

Ja, für den Test. Vor der endgültigen Umstellung muss sie aber erneut übertragen werden, sonst fehlen alle Änderungen aus der Zwischenzeit. Bei Shops mit laufenden Bestellungen plant man dafür ein kurzes Wartungsfenster ein.

Woran scheitern Umzüge am häufigsten?

An vergessenen Nebensachen: Cronjobs, die niemand kannte, ein Zahlungsdienst mit IP-Freigabe auf die alte Adresse, hart kodierte Pfade in der Konfiguration und Mailversand, der plötzlich über einen anderen Absender läuft und im Spam landet.

Weiterlesen