„Zero Downtime“ bei Cloud-Migration heißt nicht, dass jedes Byte ohne jede Sekunde Freeze wandert. Es heißt: Nutzer sehen keinen Ausfall – oder nur ein kurzes, kontrolliertes Cutover – während Production auf neuer Infrastruktur landet. Dieser Leitfaden behandelt Blue-Green, phasenweise Migration und DNS-Cutover Richtung EuroVDC-Cloud-Server / KVM.
Ziel Sofia (EU)? Zusätzlich den Bulgarien-KVM-VPS-Leitfaden lesen. Zur Tarifwahl den KVM-Mietleitfaden. Hier geht es um Unterbrechungsrisiko.
Was „Zero Downtime“ wirklich bedeutet
- Leseintensive Sites: Alt und Neu parallel; DNS oder Load Balancer schwenkt; Writes mit kurzem Freeze synchronisieren.
- Schreibintensive Apps: Kurzes Maintenance-Fenster (Minuten) oder Freeze gegen Replication-Lag ist normal; „wirklich null Sekunden“ ist oft Marketing.
- Metrik: HTTP 5xx, fehlgeschlagene Checkouts, „Site down“ – Ihre SLA definiert Erfolg.
Inventar vor dem Umzug
- App-Stack (PHP, Node, Docker…), Webserver, Reverse Proxy.
- Datenbankgröße, Engine (MySQL/PostgreSQL), vorhandene Replication.
- Dateispeicher (Uploads, Media); Object Storage möglich?
- Cron, Queues, Websockets, ausgehende E-Mail.
- SSL, DNS-TTL, abhängige Subdomains.
- Secrets und API-Keys – auf dem Ziel bereit, nicht nur in Git.
Fehlendes Inventar erzeugt Cutover-Überraschungen. Zuerst dasselbe Image auf Staging starten.
Strategie A: Blue-Green (parallele Welten)
Alte Umgebung „blue“, EuroVDC-Cloud „green“. Green läuft mit App plus DB-Snapshot/Replica; Smoke-Tests ok; Traffic auf green. Bei Problemen DNS/LB zurück auf blue.
- Ziel-VM (Sofia) provisionieren, OS/Firewall härten.
- Code deployen; Production-Secrets anbinden.
- DB per Replica oder Dump + Binlog/WAL annähern.
- Green health-checken (Login, Warenkorb, kritische APIs).
- TTL früh senken; beim Cutover A/AAAA oder LB-Backends wechseln.
- Blue ~48 Stunden behalten (Rollback).
Strategie B: Phasenweise Migration
Zuerst Statik/CDN, dann Read-Replicas, dann Write-Master. Teilt Risiko bei Shops und großen DBs. Jede Phase braucht schriftliches Rollback.
- Phase 1: Media/Object Storage oder CDN-Origin aktualisieren.
- Phase 2: Anteil des Lesetraffic auf neue App-Server.
- Phase 3: DB-Promote / Final Sync + kurzer Write-Freeze.
- Phase 4: Alten Host beobachten, dann außer Betrieb nehmen.
DNS, SSL und Cutover-Fenster
TTL 24–48 Stunden vorher auf 300 (oder weniger). SSL auf neuer IP vorher mit Let’s Encrypt oder bestehendem Zertifikat validieren. Cutover in verkehrsarmer Zeit; Payment-Webhooks auf neue IP-Allowlist setzen.
Domain bei EuroVDC: A-Records im Panel über Domainanfrage / DNS; dieselbe Logik gilt bei externem Registrar.
Datenbank-Sync: praxisnahe Optionen
- Kleine DB (<5–10 GB): Dump/Restore im Maintenance-Fenster mit App-Freeze.
- Mittel/groß: Replication aufbauen, bei Lag ≈ 0 promoten; kurzer Freeze.
- Datei-lastig: rsync Dry-Run, dann finales Delta beim Cutover.
Nach dem Cutover Integrität prüfen: Zeilenzahlen, letzte Order-IDs, kritische Crons nur einmal.
Häufige Migrationsfehler
- Cutover ohne TTL-Senkung – stundenlanger Split-Brain.
- Production-DNS ohne Staging-Probe drehen.
- Crons auf beiden Hosts (Doppelbuchungen / Doppel-Mails).
- Dateien migrieren, .env und Queue-Worker vergessen.
- Blue sofort löschen ohne Rollback-Plan.
- Jeden Write-Freeze im Namen von „Zero Downtime“ ablehnen und Datenverlust riskieren.
Beispiel-Timeline (mittelgroßes SaaS)
- T-7 Tage: Inventar, Ziel-VM, Staging-Probe.
- T-2 Tage: TTL senken, SSL vorbereiten, Replication starten.
- T-0 (60–90 Min.): Writes freezen → Final Sync → DNS/LB → Smoke → Unfreeze.
- T+2 Tage: Bei stabilen Metriken Blue abschalten entscheiden.
Praxis-Hinweise bei EuroVDC
Auf Sofia-KVM installieren Sie mit Root Ihren Reverse Proxy (Nginx/Caddy); die Panel-IP kommt in DNS. Domain + SSL im selben Konto verkürzt die Cutover-Checkliste. Am Umzugstag Staging-Smoke dokumentieren (Screenshot + curl), bevor Tickets fliegen – das beschleunigt die Diagnose.
Payment- und E-Mail-Allowlists am T-1 auf die neue Server-IP setzen. 24 Stunden 5xx und Queue-Länge beobachten; stille Fehler sitzen meist in Cron und Webhooks, nicht auf der Homepage.
Häufig gestellte Fragen
Ist echtes Zero Downtime möglich?
Bei leselastigen Systemen lässt sich sichtbarer Ausfall oft vermeiden. Bei starken Writes und Single-Master-DB ist ein kurzes geplantes Freeze sicherer; „wirklich null Sekunden“ ist meist übertrieben.
Was ist typisches EuroVDC-Ziel?
Ein KVM-Cloud-Server in Sofia mit Root, NVMe und EU-Standort. Tarif an den Workload anpassen und dasselbe Image auf Staging proben.
Blue-Green oder phasenweise?
Blue-Green ist schnell für kleine/mittlere Apps. Phasenweise Migration teilt Risiko bei großen DBs oder vielen Komponenten. Beides kombinieren ist üblich.
Wann TTL senken?
Mindestens 24–48 Stunden vor dem Cutover. Sonst cachen Resolver die alte IP und Traffic splittet sich.
Wie funktioniert Rollback?
Blue mindestens 48 Stunden behalten. DNS/LB zurück; schriftlichen Plan für Sync der Post-Cutover-Writes nach Blue bereithalten.
E-Mail und Cron während der Migration?
Cron so sperren, dass er nur auf einer Seite läuft. SMTP-/Webhook-Allowlists auf dem neuen Host setzen, sonst stille Zustellfehler.
Jetzt planen
Sofia-Tarife: Cloud Server. Starke Single-Tenant-Anforderungen: Dedicated Server; Standortkontext: Sofia-VPS-Leitfaden.