Server-Migration: Warum notwendig?
Aktueller Dedicated Server unzureichend, neue Hardware erforderlich. Oder Hosting-Anbieter wechseln. Migration 1-Stunde Ausfallzeit → 20% Kundenverlust.
Zero-Downtime-Migration möglich? Ja, mit richtiger Strategie.
Migrationsstrategien: 1) Big Bang (Cold Migration): Alten Server herunterfahren, Daten kopieren, neuen Server starten. Ausfallzeit: 2-8 Stunden. Einfach aber riskant. 2) Phasenweise (Hot Migration): Parallel laufen lassen, schrittweiser Übergang. Ausfallzeit: 0-10 Minuten. Komplex aber sicher. 3) DNS-Cutover: DNS-TTL senken, auf neuen Server umleiten. Ausfallzeit: 0-5 Minuten (DNS-Propagierung).
Zero-Downtime-Migrationsschritte: Tag -7 Vorbereitung: Neuen Dedicated Server holen (gleiche oder höhere Config), OS installieren (gleiche Version: Ubuntu 22.04 → 22.04), DNS-TTL auf 300 Sekunden senken (24 Stunden vorher). Tag -3 Erste Synchronisierung: sync -avz --progress /var/www/ root@new-server:/var/www/. Erste Synchronisierung 2-6 Stunden (hängt von Datengröße ab). Tag -1 Test-Synchronisierung: Datenbank-Export mysqldump --single-transaction db > db.sql, neuer Server-Import mysql db < db.sql, Konfigurationsdateien kopieren (/etc/nginx, /etc/php), SSL-Zertifikat installieren (Let's Encrypt oder übertragen). Tag 0 Cutover (Niedrige Verkehrszeit): Nacht 03:00 (niedrigster Verkehr): 1) Alter Server Nur-Lese-Modus (Wartungsseite). 2) Finale rsync (Delta-Synchronisierung, 2-5 Minuten): sync -avz --delete /var/www/ root@new-server:/var/www/. 3) Datenbank finale Export + Import. 4) Neuer Server-Test (curl, Smoke-Test). 5) DNS-A-Eintrag-Update (alte IP → neue IP). 6) 5 Minuten warten (DNS-Propagierung). 7) Alter Server Wartung entfernen. Gesamtausfallzeit: 5-10 Minuten.
Datenbanksynchronisationsstrategie: Option 1 Master-Slave-Replikation: Alter Server Master, neuer Server Slave. Echtzeitsynchronisierung, Cutover-Moment Slave zu Master machen. Option 2 Application-Level Dual-Write: App schreibt in alte und neue DB. Nach Migration alte DB herunterfahren.
Rollback-Plan: Wenn neuer Server Problem: 1) DNS-A-Eintrag auf alte IP zurücksetzen. 2) 5 Minuten warten. 3) Alter Server muss 24 Stunden oben bleiben.
E-Mail-Server-Migration: Wenn Firmen-E-Mail-Server migriert wird: 1) MX-Eintrag-TTL senken (48 Stunden vorher). 2) Mailbox-Synchronisierung (IMAP → IMAP, imapsync-Tool). 3) MX-Eintrag aktualisieren. 4) Test-E-Mail senden/empfangen.
Dateispeicher: Rsync vs SCP: rsync: Inkrementell, Delta-Transfer, Resume-Unterstützung. Ideal für 100GB-Daten. SCP: Einmalige Übertragung, kein Resume. OK für kleine Dateien (<10GB).
Load Balancer Zero-Downtime: Wenn hinter Cloudflare/HAProxy: 1) Neuen Server zum Load-Balancer-Pool hinzufügen. 2) Gesundheitscheck bestanden → Verkehr fließt zu neuem Server. 3) Alten Server aus Pool entfernen. Echte Zero-Downtime (0 Sekunden).
Häufige Fehler: ❌ DNS-TTL vergessen: Wenn 86400 Sekunden (24 Stunden) TTL, muss 24 Stunden warten. ❌ SSL-Zertifikat vergessen: Wenn SSL auf neuem Server fehlt, funktioniert HTTPS nicht. ❌ Sitzungsdatenverlust: Redis/Memcached-Sitzungen migrieren.
Post-Migrations-Checkliste: 1) SSL Labs-Test (A+-Bewertung). 2) Google Search Console-Abruf. 3) Uptime-Monitor aktualisieren (neue IP). 4) Analytics-Spike-Prüfung (Verkehr gefallen?). 5) Alten Server 7 Tage oben halten (für Rollback).
Kosten: Migration läuft 2 Server parallel. Kosten: €120 × 2 × 1 Monat = €240. Aber Zero-Downtime → 0% Umsatzverlust.
Managed-Migration-Service: Wenn kein technisches Team, EuroVDC-Support-Team übernimmt Migration. Cloud-Server + Domain + SSL + E-Mail von einem Panel verwaltet. Migrationsunterstützung: €200-500 (einmalig), Zero-Downtime-Garantie.
Fazit: Server-Migrations-Ausfallzeit kann um 90% reduziert werden. DNS-TTL + rsync + phasenweiser Cutover = Zero-Downtime. Planung kritisch, Rollback-Plan obligatorisch.