Serverumzug ohne Ausfall: Wie Sie eine Migration planen, testen und umschalten

Ein Serverumzug steht selten aus reiner Lust an: Der Vertrag läuft aus, die Hardware ist am Limit, das Betriebssystem erreicht sein End of Life oder der bisherige Anbieter passt nicht mehr zu den Anforderungen. In allen Fällen gilt dieselbe Regel: Der eigentliche Umzug dauert Minuten, die Vorbereitung Wochen. Wer diese Reihenfolge umdreht, produziert genau die Ausfallzeit, die er vermeiden wollte.

Warum Migrationen scheitern

Das Kopieren von Daten ist technisch selten das Problem. Probleme entstehen an den Stellen, die niemand dokumentiert hat: ein Cronjob, der seit vier Jahren Rechnungen verschickt, eine feste IP-Adresse in der Firewall eines Zahlungsdienstleisters, ein SSH-Key, den nur ein externer Dienstleister besitzt, oder eine PHP-Extension, die es in der Zielversion nicht mehr gibt.

Der Aufwand einer Migration steckt nicht im Datentransfer, sondern in der vollständigen Inventur dessen, was auf dem alten System tatsächlich läuft. Diese Inventur lässt sich nicht aus einer Rechnung ableiten, sie muss auf dem laufenden System erhoben werden.

Inventur vor dem Umzug

Bevor eine Zielumgebung entsteht, sollte eine belastbare Liste vorliegen. Nützlich ist eine Erhebung entlang dieser Punkte:

• Alle Dienste, die beim Systemstart aktiviert sind, samt Versionsständen
• Geplante Aufgaben: Cronjobs, Timer, Queue-Worker, Backup-Skripte
• Datenbanken mit Größe, Engine, Zeichensatz und Benutzerrechten
• Ausgehende und eingehende Verbindungen zu Drittsystemen, insbesondere IP-basierte Freigaben
• Zertifikate mit Ablaufdatum und Ausstellungsverfahren
• DNS-Einträge in allen Zonen, auch bei fremden Providern
• Datenverzeichnisse außerhalb der Anwendung, etwa Uploads, Archive oder Logs mit Aufbewahrungspflicht

Besonders lohnt der Blick auf Abhängigkeiten in beide Richtungen. Ein Server ist nicht nur Konsument von Diensten, andere Systeme greifen auch auf ihn zu. Monitoring-Agents, Reverse Proxies, Backup-Server oder Partner-Schnittstellen müssen nach dem Umzug ebenfalls auf das neue Ziel zeigen.

Kopie oder Neuaufbau

Es gibt zwei grundsätzliche Wege. Die Eins-zu-eins-Kopie überträgt das bestehende System möglichst unverändert, inklusive Betriebssystemversion und Konfiguration. Das Risiko ist gering, die technischen Schulden ziehen aber mit um.

Der Neuaufbau setzt die Zielumgebung sauber auf, idealerweise automatisiert, und überträgt nur Daten und Konfiguration. Das Ergebnis ist deutlich wartbarer, der Testaufwand aber höher, weil sich Versionsstände ändern.

Eine Faustregel: Steht ohnehin ein Versionssprung beim Betriebssystem an, ist der Neuaufbau meist der ehrlichere Weg. Geht es nur um andere Hardware oder einen anderen Anbieter, reicht die Kopie. Was Sie in jedem Fall vermeiden sollten, ist die Kombination aus Umzug und größerem Anwendungsrelease am selben Tag. Wenn danach etwas nicht funktioniert, wissen Sie nicht, woran es liegt.

Daten synchronisieren

Die Kernfrage jeder Migration lautet: Wie kommen die Daten vom alten auf das neue System, ohne dass zwischendurch Änderungen verloren gehen?

Dateien

Bewährt hat sich ein mehrstufiges Vorgehen. Ein erster vollständiger Abgleich läuft Tage vor dem Umzug und darf beliebig lange dauern. Danach folgen inkrementelle Durchläufe, die nur Änderungen übertragen und entsprechend kurz sind. Der letzte Durchlauf findet unmittelbar vor der Umschaltung statt, wenn keine Schreibzugriffe mehr erfolgen.

Datenbanken

Bei kleinen Datenbanken genügt ein Dump im Wartungsfenster. Ab einer gewissen Größe wird das Einspielen zum Engpass, weil Indizes neu aufgebaut werden müssen. Dann ist Replikation der bessere Weg: Das neue System läuft als Replikat des alten mit und wird beim Cutover zum primären System befördert. Die verbleibende Ausfallzeit reduziert sich damit auf das Umschalten selbst.

Wichtig ist in beiden Fällen ein Konsistenzcheck. Zeilenzahlen je Tabelle, Prüfsummen zentraler Datensätze und ein Vergleich der Dateianzahl in großen Verzeichnissen kosten wenig Zeit und decken abgebrochene Transfers zuverlässig auf.

DNS und der Cutover

Die Umschaltung selbst erfolgt in den meisten Fällen über DNS. Damit sie schnell wirkt, muss die TTL der betroffenen Einträge rechtzeitig abgesenkt werden, üblicherweise 24 bis 48 Stunden vorher auf wenige Minuten. Wer die TTL erst am Umzugstag ändert, wartet noch den alten Wert ab, bevor die Änderung greift.

Verlassen Sie sich nicht darauf, dass alle Resolver die TTL respektieren. Ein Teil des Verkehrs erreicht das alte System noch Stunden nach der Umstellung. Deshalb sollte der alte Server nach dem Cutover nicht abgeschaltet, sondern in einen definierten Zustand gebracht werden: Schreibzugriffe deaktivieren, Anfragen auf das neue System weiterleiten oder eine Hinweisseite ausliefern. Ein alter Server, der noch fröhlich Bestellungen annimmt, erzeugt geteilte Datenbestände und damit den teuersten Fehlerfall überhaupt.

Nicht vergessen: Zertifikate müssen auf dem Zielsystem gültig sein, bevor umgeschaltet wird. Bei Verfahren mit automatischer Validierung über HTTP funktioniert die Ausstellung erst, wenn die Domain bereits zeigt. Ein Zertifikat per DNS-Validierung oder eine vorab manuell übertragene Kopie löst dieses Henne-Ei-Problem.

Testlauf und Rollback

Vor dem echten Termin sollte die neue Umgebung mit realen Daten getestet werden, erreichbar über einen temporären Hostnamen oder lokale Einträge in der hosts-Datei der Tester. Prüfen Sie dabei nicht nur die Startseite, sondern die kritischen Abläufe: Login, Zahlung, Dateiupload, Mailversand, Schnittstellen zu Drittsystemen, Suchfunktion, Druckausgabe.

Parallel entsteht ein Rollback-Plan. Er beantwortet drei Fragen: Woran erkennen wir, dass die Migration gescheitert ist? Wer entscheidet über den Rückfall? Und welche Schritte sind dafür in welcher Reihenfolge nötig? Diese Entscheidung braucht ein Zeitfenster. Solange der alte Server unverändert steht und noch keine Schreibzugriffe auf dem neuen System stattgefunden haben, ist ein Rollback trivial. Danach wird es aufwendig, weil neue Daten zurückgeführt werden müssten.

Nach dem Umschalten

Der Umzug endet nicht mit der DNS-Änderung. In den Tagen danach gehören folgende Punkte abgearbeitet:

1. Monitoring auf das neue System umstellen und alte Checks deaktivieren, damit keine Blindstellen entstehen
2. Backups auf dem Zielsystem einrichten und einen Wiederherstellungstest durchführen
3. Logs auf wiederkehrende Fehler prüfen, die im Test nicht auftraten
4. Ausgehende IP-Adresse bei Partnern und Mailversand hinterlegen, Reputation beobachten
5. TTL wieder auf normale Werte anheben
6. Alten Server erst nach einer vereinbarten Frist abschalten, vorher ein letztes vollständiges Abbild sichern

Diese letzte Frist ist keine Formalie. Erfahrungsgemäß fällt erst nach dem ersten Monatsabschluss oder dem ersten Quartalslauf auf, dass ein selten genutzter Job nie mitgezogen wurde.

Fazit

Eine Migration mit minimaler Ausfallzeit ist kein Kunststück, sondern das Ergebnis von drei Dingen: einer vollständigen Bestandsaufnahme, einem mehrstufigen Datenabgleich und einem klaren Zeitplan für Cutover und Rollback. Die Technik dahinter ist etabliert. Was Projekte zum Scheitern bringt, ist der unbekannte Cronjob und die zu spät gesenkte TTL.