Bereiten Sie den neuen Server zuerst vor und testen Sie ihn, kopieren Sie Daten mit einer von der Anwendung unterstützten Konsistenzmethode, definieren Sie ein Cutover-Fenster und bewahren Sie die alte Umgebung auf. Rollback muss Schreibvorgänge berücksichtigen, die auf dem neuen Server akzeptiert wurden, nicht nur eine DNS-Änderung.
Bestandsaufnahme des Dienstes vor dem Umzug der Maschine
Eine Migration umfasst mehr als die Anwendungsdateien. Listen Sie Datenbanken, Uploads, geplante Jobs, Queue-Worker, Zertifikate, Domains, Secrets und ausgehende Integrationen auf. Erfassen Sie Softwareversionen und die relevanten Betriebsannahmen wie Dateiberechtigungen und Speicherpfade. Ein frischer dedizierter Server kann eine vergessene Abhängigkeit offenlegen, die vor Jahren still in der alten Umgebung installiert wurde.
Weisen Sie einen Verantwortlichen für die Cutover-Entscheidung zu und definieren Sie, wie Erfolg aussieht. Beziehen Sie für Nutzer sichtbare Prüfungen, Datenkonsistenz und die Fähigkeit zur Wiederherstellung des Zugangs ein. Bestätigen Sie, dass die neue Konfiguration geliefert und nutzbar ist, bevor Sie ein Migrationsdatum ankündigen. Eine Auftragsbestätigung oder eine aufgeführte Hardwarespezifikation ist nicht dasselbe wie ein funktionierendes Ziel, das bereit ist, Produktionsdaten zu empfangen.
Das Ziel als separate Umgebung aufbauen
Installieren Sie den erforderlichen Stack, richten Sie die Administration ein und konfigurieren Sie die vorgesehene Firewall. Halten Sie Secrets privat und setzen Sie Dienstberechtigungen bewusst. Verifizieren Sie den erwarteten Hostnamen und das Zertifikatsverhalten der Anwendung, bevor öffentlicher Traffic umzieht. Die Virtual-Host-Dokumentation von Apache veranschaulicht, warum Hostname-Routing eine separate Konfigurationsentscheidung von der Adresse des Servers ist. Eine funktionierende Standardseite beweist nicht, dass der richtige Anwendungs-Host konfiguriert ist.
Verwenden Sie für die Probe einen repräsentativen wiederhergestellten Datensatz, wobei ausgehende E-Mails, Zahlungen und geplante Jobs deaktiviert oder auf sichere Testsysteme umgeleitet sind. So verhindern Sie, dass die Testumgebung auf echte Nutzer einwirkt. Üben Sie Anmeldung, Uploads, Hintergrundarbeit und Wiederherstellung. Dokumentieren Sie das Verfahren und seine Dauer, damit das echte Fenster auf einem beobachteten Prozess statt auf Optimismus basiert.
Eine konsistente Datengrenze wählen
Verwenden Sie eine von Datenbank und Anwendung unterstützte Backup- oder Replikationsmethode. PostgreSQL unterscheidet SQL-Dumps, Dateisystem-Backups und kontinuierliche Archivierung, jeweils mit eigenen Annahmen. Die Dump-Anleitung weist darauf hin, dass Datenbank-Dumps intern konsistent sein können, während clusterweite Rollen und andere Details separat behandelt werden müssen. Lesen Sie die Anforderungen für das exakte System, das Sie betreiben, statt offene Datendateien wahllos zu kopieren.
Planen Sie, wie die Datenbank mit Uploads und Queue-Status zusammenhängt. Wenn ein Datensatz auf eine Datei verweist, die zu einem anderen Zeitpunkt kopiert wurde, kann die wiederhergestellte Anwendung unvollständig sein, selbst wenn beide Kopien einzeln erfolgreich waren. Entscheiden Sie, ob Schreibvorgänge kurz pausiert, eine getestete Replikationsanordnung verwendet oder ein anwendungsspezifischer Export durchgeführt wird. Halten Sie diese Konsistenzentscheidung im Runbook ausdrücklich fest.
| Phase | Erforderlicher Nachweis | Entscheidung |
|---|---|---|
| Probe | Anwendung und wiederhergestellte Daten bestehen die Prüfungen | Ziel kann für Cutover in Betracht gezogen werden |
| Abschließende Synchronisierung | Definierter konsistenter Wiederherstellungspunkt | Nur mit verstandenen verbleibenden Änderungen fortfahren |
| Traffic-Umschaltung | Korrektes Routing und Zertifikatsverhalten | Beide Ziele überwachen |
| Rollback | Speicherort aller neu akzeptierten Schreibvorgänge | Daten abgleichen, bevor Traffic zurückgeführt wird |
Traffic-Routing vorbereiten, ohne sofortige Änderungen zu versprechen
DNS Time-to-Live steuert, wie lange Datensätze zwischengespeichert werden dürfen, wie in der DNS-Dokumentation von Cloudflare erläutert. Prüfen Sie die TTL frühzeitig, wenn DNS Teil der Migration ist, und lassen Sie vorhandene zwischengespeicherte Datensätze unter ihrer vorherigen Einstellung auslaufen. Eine Änderung des Werts im Moment des Cutovers kann nicht jede zwischengespeicherte Antwort rückwirkend verkürzen. Verschiedene Clients können während der Übergangsphase unterschiedliche Ziele erreichen.
Halten Sie die alte Umgebung verfügbar, während sich Routing-Änderungen setzen, mit einer bewussten Richtlinie dazu, ob sie noch Schreibvorgänge akzeptieren darf. Vermeiden Sie doppelte Queue-Consumer oder geplante Jobs, es sei denn, die Anwendung ist dafür ausgelegt. Überwachen Sie Anfragen auf beiden Seiten und bestätigen Sie den vorgesehenen Hostnamen, das TLS-Zertifikat und die Anwendungsversion von unabhängigen Clients aus.
Rollback definieren, nachdem Schreibvorgänge beginnen
Bevor das neue System Änderungen akzeptiert, kann die Rückführung des Traffics relativ einfach sein. Danach kann eine bloße DNS-Umkehrung Arbeit verlieren oder zwei widersprüchliche Historien erzeugen. Definieren Sie, wie neu erstellte Datensätze und Uploads erhalten oder abgeglichen werden. Wenn die Anwendung sie nicht sicher zusammenführen kann, ist ein kontrollierter Wartungszeitraum möglicherweise einer improvisierten Rückkehr zur alten Kopie vorzuziehen.
Legen Sie die Bedingungen fest, die ein Pausieren der Migration erfordern, und halten Sie den Entscheidungsverantwortlichen erreichbar. Bewahren Sie Logs und nützliche Nachweise gemäß den Aufbewahrungsregeln des Projekts auf. Löschen Sie die alte Maschine oder ihre unabhängige Wiederherstellungskopie nicht allein deshalb, weil die Startseite einmal geladen wurde. Der Aufbewahrungszeitraum sollte die vereinbarten Verifizierungs- und Rollback-Anforderungen abdecken.
Die Migration mit operativen Prüfungen abschließen
Verifizieren Sie nach dem Cutover Backups, Alarme, Zertifikatserneuerung, geplante Arbeiten und Wiederherstellung des Zugangs. Bestätigen Sie, dass der überwachte Host das neue Ziel ist und keine Testintegrationen in der Produktion verbleiben. Prüfen Sie Anwendungsfehler und für Nutzer sichtbare Zeiten unter normalem Traffic. Aktualisieren Sie Inventar und Runbook, damit der nächste Administrator nicht erraten muss, was sich geändert hat.
Die dedizierten Familien von SwissOctet bieten unterschiedliche physische Konfigurationen, aber Migrationsarbeit und verwaltete Unterstützung müssen für den gewählten Dienst bestätigt werden. Nutzen Sie den Katalog, um geeignete Ressourcen auszuwählen, und bauen Sie dann einen getesteten Umzug rund um die Daten Ihrer Anwendung auf. Eine Migration ist abgeschlossen, wenn der Dienst und sein Wiederherstellungsprozess am Ziel funktionieren, nicht erst, wenn Dateien übertragen wurden.
Ihre praktische Checkliste.
- Daten, Jobs, Secrets und Integrationen inventarisieren.
- Das gelieferte Ziel vor der Terminplanung verifizieren.
- Mit sicheren externen Integrationen proben.
- Konsistenz von Datenbank und Uploads definieren.
- Routing-Übergang und Vermeidung doppelter Jobs planen.
- Rollback für neue Schreibvorgänge festlegen.
- Backups und Monitoring nach dem Cutover verifizieren.
Die Details, die zählen.
Kann ich migrieren, indem ich das Anwendungsverzeichnis kopiere?+
Nur wenn damit alles erfasst wird, was der Dienst benötigt, und die Konsistenz erhalten bleibt. Datenbanken, Uploads, Jobs, Secrets und Konfiguration erfordern üblicherweise separate Aufmerksamkeit.
Macht ein niedrigerer DNS-TTL den Cutover sofort wirksam?+
Nein. Zuvor zwischengespeicherte Antworten können bis zum Ende ihrer früheren Lebensdauer bestehen bleiben, und Clients können zu unterschiedlichen Zeiten aktualisieren.
Besteht Rollback nur darin, DNS auf den alten Server zu zeigen?+
Nicht, nachdem der neue Server Schreibvorgänge akzeptiert hat. Sie müssen diese Datensätze und Dateien berücksichtigen, bevor Sie Traffic zurückführen.
Gehen Sie zur Quelle.
Diese Referenzen unterstützen die technischen Konzepte in diesem Leitfaden. Folgen Sie der aktuellen Dokumentation, bevor Sie ein Produktionssystem ändern.
- PostgreSQL: Backup und Wiederherstellung www.postgresql.org
- PostgreSQL: Konsistenz und Wiederherstellung von SQL-Dumps www.postgresql.org
- Apache: Virtual-Host-Dokumentation httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Redaktionelle Beratung durch SwissOctet. Beispiele sind illustrativ. Servicespezifikationen, verfügbare Optionen und vertragliche Bedingungen müssen separat überprüft werden.