Website oder App auf einen neuen Cloud-Server migrieren
Wer sicher auf einen Cloud-Server migrieren will, lässt den alten Server unangetastet, bis der neue echten Traffic bedient hat. Dieser Leitfaden ist ein Plan für eine Website, einen Shop oder eine Anwendung: drei Checklisten (vorher, Umschalten, Rollback), anpassbare Befehle und ehrliche Grenzen beim Thema Ausfallzeit. Dimensionieren Sie das Ziel zuerst mit dem Sizing-Leitfaden für Cloud-Server und wählen Sie die Region mit dem Leitfaden zu europäischen Standorten.
Die Migrationsmethode wählen
Vier Methoden decken fast jeden Umzug ab. Oft kombiniert man zwei davon.
| Methode | Geeignet für | Hauptrisiko |
|---|---|---|
| rsync der Dateien | Statische Seiten, Uploads, Anwendungscode | Daten ändern sich während des Kopierens, ein finaler Abgleich ist nötig |
| Image- oder Backup-Wiederherstellung | Gleiches Betriebssystem und Layout, getestete Wiederherstellung | Alte Treiber und Netzwerknamen, größere Datenmenge |
| Anwendung neu ausrollen | Container und Code in git | Versteckter Zustand auf der alten Platte wird vergessen |
| Datenbank-Replikation | Große oder stark genutzte Datenbanken | Einrichtungsaufwand und Versionsgrenzen |
Starten Sie mit einem Cloud-Server ab EUR 15.00/Monat, geprüft 2026-10 und proben Sie dort den ganzen Plan.
Checkliste vor der Migration
- Inventur - Dienste, Ports, Cronjobs, Mail-Einstellungen, Zertifikate, Firewall-Regeln und jeden Hostnamen auflisten, der auf die alte IP zeigt.
- Versteckter Zustand - Dateien außerhalb des Web-Roots suchen: Uploads, Warteschlangen, Sessions, Lizenzdateien, Secrets in Umgebungsvariablen.
- Backups - ein vollständiges Backup des alten Servers anlegen und einmal woanders wiederherstellen, denn ein ungetestetes Backup ist nur eine Hoffnung.
- Zugang - nur SSH-Schlüssel, eine Firewall und ein Deploy-Benutzer ohne Root-Rechte auf dem neuen Server.
- Snapshot - vor dem ersten echten Abgleich einen Snapshot des neuen Servers erstellen, damit ein Fehler nur Minuten kostet.
Dateien und Daten kopieren
Die Beispiele nutzen die Dokumentationsadresse 203.0.113.10 als neuen Server. Ersetzen Sie Namen und Pfade durch Ihre. Schritt 1 und 2 lassen sich gefahrlos wiederholen, Schritt 5 läuft erst, wenn die alte Seite schreibgeschützt ist.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
Die Option --delete löscht auf dem Ziel Dateien, die auf der Quelle nicht mehr existieren. Nutzen Sie sie nur im letzten Lauf und nur, wenn klar ist, welche Seite die führende ist.
Zuerst mit der hosts-Datei testen
Bevor sich DNS ändert, lassen Sie Ihren eigenen Rechner die Seite auf dem neuen Server auflösen. Tragen Sie eine Zeile in die hosts-Datei ein (/etc/hosts oder unter Windows C:\Windows\System32\drivers\etc\hosts): 203.0.113.10 example.com www.example.com. Die curl-Option --resolve in Schritt 3 macht dasselbe für eine einzelne Anfrage. Entfernen Sie die Zeile danach wieder, sonst testen Sie wochenlang den neuen Server, ohne es zu merken.
DNS-TTL senken und umschalten
Senken Sie die TTL der A- und AAAA-Einträge auf etwa 300 Sekunden, mindestens eine volle alte TTL vor dem Umzug. Sonst behalten Resolver die alte Adresse so lange, wie die alte TTL erlaubt. Manche Resolver ignorieren kurze TTLs, rechnen Sie also über Stunden mit Besuchern auf der alten IP (eine Schätzung, keine Messung).
Checkliste zum Umschalten:
- TTL - der gesenkte Wert gilt, der alte ist abgelaufen.
- Schreibschutz - die alte Seite läuft im Wartungs- oder Nur-Lese-Modus.
- Finaler Abgleich - letzter Datenbank-Dump und Schritt 5 aus dem Code oben sind erledigt.
- DNS - A- und AAAA-Einträge zeigen auf die neue IP; Mail-Einträge bleiben, solange die Mail nicht mitzieht.
- Smoke-Test - Login, Bestellung, Upload, E-Mail, Cron und Zertifikat unter dem öffentlichen Namen geprüft.
- Alter Server - weiterlaufen lassen, erreichbar und unverändert.
Rollback-Checkliste
- Schwelle - vorab festlegen, was als Fehlschlag gilt, etwa fehlgeschlagene Zahlungen oder eine 5xx-Rate, und wer entscheidet.
- DNS zurück - Einträge auf die alte IP setzen; bei niedriger TTL kehren die meisten Besucher innerhalb von Minuten bis Stunden zurück.
- Schreibzugriffe - die alte Seite wieder öffnen. Hat die neue seit dem Umschalten Bestellungen oder Uploads angenommen, zuerst exportieren und auf der alten Seite nachspielen.
Was echte Zero-Downtime voraussetzt
Zero Downtime hängt von der Architektur Ihrer Anwendung ab und wird für kein Projekt versprochen. Nötig sind eine zustandslose Anwendung, eine Datenbank, die repliziert oder auf beiden Seiten Schreibzugriffe annimmt, geteilter oder replizierter Speicher und ein getestetes Umschalten. Eine klassische Seite mit einer Datenbank hat meist ein kurzes Nur-Lese-Fenster von Minuten.
Nach dem Umzug
Beobachten Sie mindestens eine Woche Fehlerlogs, Platte, Arbeitsspeicher, Antwortzeiten und Mailzustellung. Erhöhen Sie die DNS-TTL wieder, sobald alles stabil läuft. Schalten Sie den alten Server erst ab, wenn auf dem neuen ein voller Backup-Zyklus vergangen ist; ein wöchentliches Backup ist in jedem Preset enthalten. Testen Sie vor der Bestellung mit der Checkliste für die Testphase; ein kurzer Test lässt sich per Nachricht an sales@dcxv.com anfragen, nach Ermessen von DCXV und ohne Garantie.
Den Ziel-Cloud-Server konfigurieren oder einen Ingenieur zur Migration fragen.
