Eine Online-Community beginnt erst zu Beginn des Wartungsfensters mit der Kopie ihrer großen WordPress-Website. Die DNS-TTL beträgt noch einen Tag, das Ziel wurde nie mit produktionsnaher Datenmenge getestet und beide Websites nehmen neue Uploads an, während die Besucher nach und nach wechseln. Schnelleres Kopieren kann zwei aktive Datenstände nicht zusammenführen.
Geringe Ausfallzeit entsteht durch Vorbereitung: Ziel testen, stabile Daten früh übertragen, festlegen, ab welchem Zeitpunkt nur noch ein System Änderungen annimmt, und das letzte Zeitfenster auf die abschließende Synchronisierung und den kontrollierten Trafficwechsel beschränken.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS Backup Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Bei einer Migration mit geringer Ausfallzeit wird das Ziel vor dem Trafficwechsel vorbereitet. Die letzte Unterbrechung umfasst nur noch ein gemessenes Datendelta. Als Ausfallzeit zählt dabei auch die Zeit, in der Publizieren, Checkout, Formulare oder andere Schreibvorgänge pausieren müssen.
Zu jedem Zeitpunkt muss feststehen, welche Datenbank und welcher Dateispeicher verbindlich sind. DNS, CDN, Zertifikate, Queues, E-Mail, Webhooks, Caches und Hintergrundjobs benötigen klare Zuständigkeiten und Prüfkriterien.
Ein realistisches WordPress-Beispiel
Eine Mitglieder-Website kopiert ihre Mediathek bereits in der Vorwoche und stellt zum Test einen aktuellen Datenbankstand auf dem neuen Host wieder her. Vor dem Umzug senkt das Team die DNS-TTL, misst die Änderungsrate von Datenbank und Uploads und probt die abschließende Synchronisierung.
Beim eigentlichen Wechsel werden Schreibvorgänge kurz pausiert, Queues geleert und das letzte Datenbank- und Dateidelta übertragen. Die Quelle bleibt bis zum Ende der Abnahme unverändert und schreibgeschützt.
Warum es wichtig ist und wann es eingesetzt wird
Das Verfahren eignet sich, wenn ein langes Wartungsfenster nicht vertretbar ist und sich Änderungen pausieren, replizieren oder abgleichen lassen. Je weniger Änderungen bei der abschließenden Synchronisierung noch zu übertragen sind, desto kürzer und besser planbar ist die Schreibpause.
Nicht jede Website profitiert davon. Reicht die Zielkapazität nicht aus, wächst der Datenbestand schneller als die Synchronisierung oder müssen beide Systeme ohne zuverlässige Replikation schreibbar bleiben, ist eine längere geplante Unterbrechung oft sicherer.
Der einfache Weg für Einsteiger
- Richten Sie das Ziel mit kompatiblen Versionen von PHP, Datenbank, Webserver, Speicher und WordPress sowie den benötigten Zertifikaten ein.
- Stellen Sie einen aktuellen Stand wieder her und testen Sie Anmeldung, Publizieren, Medien, Formulare, Zeitjobs, E-Mail und Integrationen mit realistischer Datenmenge.
- Kopieren Sie stabile Dateien frühzeitig und senken Sie die DNS-TTL rechtzeitig. Messen Sie die Dauer des letzten Datenbank- und Upload-Deltas.
- Pausieren oder replizieren Sie beim Cutover die Schreibvorgänge, leeren Sie Queues, übertragen Sie die letzten Änderungen und vergleichen Sie die Bestände.
- Schalten Sie den Traffic über die zuständige DNS-, CDN- oder Proxy-Ebene um. Die Quelle bleibt bis zur Abnahme schreibgeschützt erhalten.
Der technische Weg
Je nach System eignen sich Datenbankreplikation oder Change Data Capture sowie eine Delta-Dateikopie mit kontrollierter Löschung. Markieren Sie Requests bei einem Canary nach Origin, überwachen Sie Fehler- und Latenzgrenzen und prüfen Sie, dass Testschreibvorgänge genau einmal ankommen.
Ein Rollback betrifft sowohl das Routing als auch die Daten seit dem Cutover. Führen Sie dafür ein Schreibprotokoll und proben Sie die Entscheidung. Eine niedrige TTL beeinflusst Resolver-Caches, beweist aber nicht, dass bereits alle Clients gewechselt haben.
Risiken, häufige Fehler, Backup und Rollback
Die Massenkopie erst im Wartungsfenster zu starten, DNS vor der Zielabnahme zu ändern, letzte Uploads oder Queues zu vergessen und beide Websites schreibbar zu lassen führt zu Split Brain und Datenverlust. Auch das Aufwärmen privater Caches ist riskant.
Löschen Sie die Quelle und ihr Wiederherstellungspaket erst nach dem vollständigen Abnahmefenster. Stoppen Sie, wenn Zertifikats- oder DNS-Zuständigkeit unklar ist, die Probe zu lange dauert, Bestände abweichen oder ein Rollback zwei konkurrierende Datenquellen erzeugen würde.
Wie AIOWS unterstützt:
AIOWS Backup Manager
Der AIOWS Backup Manager kann einen definierten WordPress-Datei- und Datenbankstand für Aufbau und Test des Ziels bereitstellen. Legen Sie den Umfang fest, speichern Sie das Paket unabhängig und stellen Sie es früh genug wieder her, um Kapazität, Kompatibilität und den Restoreweg zu prüfen.
Beim eigentlichen Umzug ist der Backup-Vorgang Teil eines umfassenderen Cutover-Plans. Stabile Daten sollten bereits am Ziel liegen; im kontrollierten Fenster folgen nur die letzten Datenbank- und Dateiänderungen, ausstehende Jobs und die Festlegung, ab wann nur noch das Ziel Änderungen annimmt. Vor dem Trafficwechsel werden Quelle und Ziel verglichen.
Der Backup Manager steuert weder DNS-Ausbreitung noch Datenbankreplikation, externe Webhooks oder den Umgang mit Schreibvorgängen nach dem Cutover. Bewahren Sie Quelle und letztes geprüftes Paket bis zur Abnahme auf. Dokumentieren Sie Wiederherstellungspunkt, letzte Synchronisierung, Routing-Verantwortung und Datenplan für den Rollback.
Passende AIOWS-Artikel
- WordPress-Umzug: Website sicher migrieren
- WordPress-Umzugscheckliste: vor und nach der Migration
- WordPress-Website sicher klonen und Live-Dienste isolieren
Fazit und empfohlener Weg
Testen Sie das Ziel mit realistischer Datenmenge, kopieren Sie stabile Dateien vorab, bereiten Sie DNS vor und bestimmen Sie genau ein schreibbares System. Nach dem letzten gemessenen Delta wird der Traffic kontrolliert umgeschaltet; die Quelle bleibt bis zur Abnahme schreibgeschützt verfügbar.
