Wissenszentrum

Hosting-Migrations-Checkliste mit Tests und Rollback

Planen Sie einen Hosting-Umzug mit Datei- und Datenbankkopien, privaten Anmeldedaten, Zieltests, DNS-Umstellung und einem verifizierten Rollback-Fenster.

3 Min. LesezeitDeutsch

Inhalt überarbeitet · Deutsch

Auf einen Blick
Leitfaden-Typ
Verschieben & wiederherstellen
Beispiele
Illustrativ, umgebungsspezifisch
Integrationsumfang
Keine Remote-Maschine verbunden
01

Inventarisieren Sie die vollständige Anwendung

Erfassen Sie Webdateien, Datenbanken, Uploads, geplante Jobs, Mail, Zertifikate, DNS, Drittanbieter-Integrationen und Secrets. Prüfen Sie Laufzeitversionen und Lizenzen am Ziel. Ein Image-Export ist nur nützlich, wenn das Ziel sein Format und Netzworking unterstützt.

02

Erstellen Sie die erste Kopie, bevor Sie DNS ändern

Verwenden Sie einen privaten Transport und ein Zielverzeichnis, das Sie kontrollieren. Das Beispiel kopiert Inhalte, anstatt den Quellordner zu verschachteln, und beginnt mit einem Probelauf. Es lässt absichtlich eine Löschoption weg. Überprüfen Sie Eigentümerschaft und Berechtigungen am Ziel.

Erstmalige Dateikopie · DokumentationszielFür Ihre Umgebung überprüfen
rsync -avzn -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/
# After reviewing the dry run and destination:
rsync -avz -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/
03

Exportieren Sie die Datenbank mit ihrer nativen Methode

Das Kopieren der Dateien einer laufenden Datenbank ersetzt keinen anwendungskonsistenten Datenbankexport. Der Einzeltransaktionsansatz von MySQL ist für transaktionale Tabellen geeignet und erfordert weiterhin Sorgfalt bei Schemaänderungen oder nicht transaktionalen Tabellen. Verwenden Sie ein geschütztes Ziel für den Export und fordern Sie das Passwort ab, anstatt es in ein Argument einzubetten.

MySQL-Beispiel · Speicher-Engine und Zugriffsberechtigungen prüfenFür Ihre Umgebung überprüfen
mysqldump --single-transaction --routines --triggers --events \
  -u app_user -p app_database > /private-backup/app-database.sql

Der Ausgabepfad ist exemplarisch und muss privat, beschreibbar und außerhalb des Web-Roots liegen. Verwenden Sie für PostgreSQL stattdessen dessen pg_dump-/pg_restore-Workflow.

04

Das Ziel vor der Umschaltung testen

Verwenden Sie einen temporären Hostnamen oder eine kontrollierte lokale DNS-Überschreibung. Testen Sie Anmeldung, Schreibvorgänge, Uploads, Hintergrundjobs, ausgehende Nachrichten und HTTPS. Kopieren Sie Geheimnisse über einen privaten Kanal und vermeiden Sie, dass die geplanten Jobs beider Seiten gegen denselben externen Dienst laufen.

05

Erstellen Sie eine letzte konsistente Kopie und verschieben Sie die Route

Senken Sie die TTL im Voraus, pausieren Sie Schreibvorgänge, wo nötig, exportieren Sie die letzten Änderungen und schließen Sie die endgültige Dateisynchronisierung ab. Aktualisieren Sie DNS erst, nachdem Zielprüfungen bestanden sind. Behalten Sie den alten Host und ein unabhängiges Backup während des Rollback-Fensters bei; DNS-Caches können weiterhin einige Besucher an den vorherigen Origin senden.

06

Den alten Dienst erst nach Abnahme außer Betrieb nehmen

Überwachen Sie Fehler und vergleichen Sie kritische Datensätze nach dem Umzug. Gleichen Sie alle Schreibvorgänge ab, die den alten Ursprung erreicht haben. Bestätigen Sie Mail und externe Callbacks und schließen Sie dann den alten Dienst gemäß seinen Abrechnungs- und Datenaufbewahrungsregeln. Es wird keine Null-Ausfallzeit oder automatische Migration zugesagt.

VOR DEM NÄCHSTEN SCHRITT

Mit einem überprüfbaren Ergebnis gehen.

  • Inventarisieren Sie Dateien, Datenbank, Laufzeitumgebung, geplante Jobs, E-Mail, DNS und Integrationsabhängigkeiten.
  • Halten Sie Exporte, Anmeldeinformationen und Wiederherstellungsschlüssel außerhalb des öffentlichen Web-Roots.
  • Anmeldung, Schreibvorgänge, Uploads, HTTPS und Hintergrundjobs am Ziel testen.
  • Schreibvorgänge während der finalen Kopie pausieren oder abgleichen, dann DNS ändern.
  • Akzeptieren Sie die Anwendung und stellen Sie die Prüfungen wieder her, bevor Sie den alten Dienst außer Betrieb nehmen.
ETWAS MEHR KONTEXT

Fragen, beantwortet.

Kopiert das Ändern von DNS meine Website?

Nein. DNS ändert, wohin Besucher weitergeleitet werden; es überträgt keine Dateien, Datenbanken, Postfächer, geplanten Aufgaben oder Anmeldedaten. Testen Sie das vollständige Ziel, bevor Sie die Route verschieben.

Können beide Hosts während einer Verschiebung weiterhin Schreibvorgänge annehmen?

Nur mit einem bewussten Synchronisations- und Abgleichsdesign. Andernfalls verwende ein geeignetes Wartungsfenster für die letzte konsistente Kopie. DNS-Caches können nach einer Änderung weiterhin Anfragen an den vorherigen Origin senden.

Wird die Migration automatisch von OmbraHost durchgeführt?

In der Anwendung läuft keine Migration oder Verbindung zu einem Remote-Anbieter. Vorbereitete Migrationsoptionen benötigen einen bestätigten Umfang, Zugriff, Cutover und Rollback-Plan, bevor echte Arbeit angeboten wird.

ZUR PRIMÄRQUELLE GEHENrsync · offizielles HandbuchMySQL · konsistenter ExportPostgreSQL · pg_dump