Website auf einen VPS umziehen: sicherer Ablauf

1. Abhängigkeiten und Grenzen des Umzugs erfassen

Notieren Sie Laufzeit, Datenbankversion, Erweiterungen, Webserverregeln und persistente Verzeichnisse. Ergänzen Sie Cronjobs, Warteschlangen, Upload-Ziele, externe APIs und die Ablage von Geheimnissen. Ein erfolgreicher Kopiervorgang nützt wenig, wenn die Zielsoftware die Daten nicht lesen kann oder ein benötigter Schlüssel fehlt. Prüfen Sie Export- und Importkompatibilität vor dem Wartungsfenster.

2. Einen gemeinsamen Datenstand herstellen

Eine erste Kopie bei laufender Quelle ist für die Vorbereitung hilfreich. Sie ist noch nicht die endgültige Übergabe. Für einen einfachen, kontrollierbaren Umzug stoppen Sie während der letzten Übertragung die schreibenden Anwendungsvorgänge. Dazu zählen neben Formularen auch Worker, geplante Aufgaben und eingehende Integrationen. Erstellen Sie dann den Datenbankexport und die passende letzte Dateikopie; prüfen Sie Fehlerstatus und Vollständigkeit.

Bei MariaDB erlaubt --single-transaction einen konsistenten Export transaktionaler Tabellen wie InnoDB. Das deckt weder nichttransaktionale Tabellen noch beliebige gleichzeitige Schemaänderungen ab. PostgreSQLs pg_dump liefert einen konsistenten Export einer Datenbank, erfasst aber keine separat veränderten Upload-Verzeichnisse und nicht automatisch globale Rollen. Wählen Sie das zur Datenbank passende Verfahren. Eine Pause nur im Webfrontend genügt nicht, wenn andere Prozesse weiter schreiben.

3. Das Ziel mit dem richtigen Hostnamen und TLS testen

Testen Sie die neue IP mit dem späteren Hostnamen, damit virtueller Host und TLS-Namensprüfung zum echten Aufruf passen. Ersetzen Sie im Beispiel Domain und Dokumentations-IP durch Ihre eigenen Werte. --noproxy umgeht konfigurierte HTTP-Proxys des Clients, damit diese den Zielnamen nicht selbst anders auflösen. Der Befehl fragt nur HTTP-Header ab und ändert weder DNS noch eine lokale Hosts-Datei. Er prüft noch keine Anmeldung, Upload-Funktion oder Datenbankkonsistenz.

curl --noproxy '*' --resolve 'www.example.com:443:203.0.113.10' \
  --connect-timeout 5 --max-time 15 --head \
  'https://www.example.com/'

Das Ziel braucht dafür bereits ein gültiges Zertifikat für den Hostnamen. Überspringen Sie Zertifikatsfehler nicht mit --insecure. Planen Sie die Ausstellung vorher: Bei Let’s Encrypt benötigt HTTP-01 eine erreichbare Challenge über Port 80; DNS-01 weist die Domainkontrolle über einen TXT-Eintrag nach. Ein lokal erzwungenes curl-Ziel ändert den Prüfweg der Zertifizierungsstelle nicht. Prüfen Sie Weiterleitungsziele und zusätzliche Hostnamen ebenfalls.

4. DNS vorbereiten und die Cache-Zeit berücksichtigen

Senken Sie eine anpassbare TTL rechtzeitig vor dem Termin. Bereits gespeicherte Antworten behalten ihre vorherige Gültigkeit; eine unmittelbar vor dem Umzug gesenkte TTL leert fremde Resolver-Caches nicht. Berücksichtigen Sie außerdem lokale Caches und gegebenenfalls einen vorgeschalteten Proxy. Es gibt keinen einzigen Zeitpunkt, an dem alle Besucher garantiert dieselbe Antwort verwenden.

Kontrollieren Sie IPv4 und IPv6. Ein aktualisierter A-Eintrag bei unverändertem AAAA-Eintrag kann einen Teil der Nutzer weiter zur alten Umgebung führen. Bei CNAMEs und CDN-Proxys prüfen Sie zusätzlich das konfigurierte Ursprungsziel. Die folgenden Abfragen zeigen die Antworten Ihres verwendeten Resolvers, nicht den Zustand aller Resolver weltweit.

dig +noall +answer www.example.com A
dig +noall +answer www.example.com AAAA
dig +noall +answer www.example.com CNAME

5. Die Schreibverantwortung ausdrücklich umschalten

Entscheiden Sie vorab, was Besucher mit alten DNS-Antworten sehen. Für einen einfachen Umzug kann die Quelle eine Wartungsseite anzeigen. Wer Anfragen weiterleiten möchte, muss diesen Weg einschließlich Uploads und TLS separat prüfen. Aktivieren Sie Hintergrundaufgaben erst nach der Freigabe und nur an der vorgesehenen Stelle. Prüfen Sie anschließend wichtige Anwendungsfunktionen mit kontrollierten Testdaten.

6. Ein Rückweg muss neue Änderungen mitnehmen

Vor der Freigabe neuer Schreibzugriffe kann ein Rückweg vergleichsweise einfach sein: Die Quelle enthält noch den maßgeblichen letzten Stand. Sobald das Ziel jedoch Bestellungen, Konten oder Uploads angenommen hat, reicht eine DNS-Rückstellung nicht mehr. Der alte Server kennt diese Daten möglicherweise nicht; ein alter Snapshot würde sie ebenfalls nicht enthalten.

Pausieren Sie für den Rückweg sämtliche Schreibzugriffe und sichern Sie beide Datenstände. Erfassen Sie alle seit der Umschaltung neu angelegten, geänderten und gelöschten Datensätze sowie die zugehörigen Dateiänderungen. Übernehmen Sie diese mit einem anwendungsgerechten Verfahren, das die referenzielle Integrität und die Zuordnung zwischen Datensätzen und Dateien erhält. Prüfen Sie vor Wiederherstellung oder erneuter Freigabe, ob die alten Anwendungs- und Datenbankversionen das Zielschema und die exportierten Daten unterstützen. Gleichen Sie außerdem Jobs, Zahlungen und Webhooks ab, um doppelte Vorgänge zu vermeiden. Vermeiden Sie improvisierte Zusammenführungen anhand von Dateidatum oder numerischen IDs. Sind Kompatibilität oder konsistenter Datenstand nicht nachgewiesen, bleiben Schreibzugriffe gesperrt; reparieren Sie dann das Ziel, statt die alte Umgebung wieder zu öffnen. Eine zuständige Person gibt den geprüften Datenstand und die einzige aktive Schreibstelle frei.

7. Die Quelle erst nach dem Nachlauf stilllegen

Beobachten Sie beide Umgebungen während des geplanten Nachlaufs: alte Anfragen, Fehler, Warteschlangen und fehlende Dateien. Halten Sie Umschaltzeit, Exportstand, DNS-Änderungen und Abnahme fest. Bewahren Sie die unabhängige Sicherung auf und prüfen Sie, dass Backups und Zertifikatserneuerung nun für das neue System funktionieren.

• Anmeldung, Medien und wichtige Geschäftsabläufe sind geprüft.
• Es gibt nur eine aktive Schreibstelle und keine doppelt laufenden Jobs.
• Der Rückweg berücksichtigt den neuesten Datenstand.
• Die Kündigung der Quelle gefährdet weder E-Mail noch andere weiter benötigte Dienste.