Serverumzug ohne Bestellverlust: Ablauf für Shops

Ein Shop ist keine statische Website. Er schreibt ununterbrochen: Bestellungen, Warenkörbe, Kundenkonten, Lagerbestände, Zahlungsstatus, Protokolle. Jede Kopie seiner Datenbank ist in dem Moment veraltet, in dem sie fertig ist. Beim Umzug einer statischen Seite spielt das keine Rolle - ob ein Besucher die alte oder die neue Maschine erreicht, er sieht dieselben Inhalte. Bei einem Shop entscheidet genau diese Frage darüber, in welcher Datenbank eine Bestellung landet. Und solange beide Maschinen erreichbar sind und beide Bestellungen annehmen, gibt es zwei Wahrheiten, die niemand zusammenführt.

Die Folgen zeigen sich selten am Umzugstag selbst. Sie tauchen Tage später auf: als Kundin, die eine Bestellbestätigung vorweisen kann, zu der es im System keinen Auftrag gibt. Als Zahlung, die beim Zahlungsdienstleister als erfolgreich gilt, während die Bestellung im neuen Shop auf „offen“ steht. Als Versandetikett, das zweimal gedruckt wurde, weil der Export auf beiden Servern lief. Wer den Umzug nur als DNS-Aufgabe plant, sieht keinen dieser Fehler kommen. Die DNS-Ebene selbst beschreibt der Beitrag zur DNS-Wartung mit DNSSEC und Registrar-Lock; hier geht es um die Anwendung darüber.

Die Datenbank ist der Teil des Umzugs, der Bestellungen verliert, wenn er als einmalige Kopie behandelt wird. Das belastbare Verfahren hat drei Schritte. Der Erstabzug läuft Tage vor dem Termin im laufenden Betrieb: Er befüllt den neuen Server, dient als Probelauf und misst, wie lange Export, Übertragung und Import tatsächlich dauern. Mit diesem Bestand wird der neue Shop durchgespielt - Katalog, Suche, Warenkorb, Checkout im Testmodus, Rechnungserstellung. Fehler aus diesem Probelauf kosten nichts, weil noch kein Kunde den neuen Server sieht.

Am Umzugstag folgt der Schreibstopp. Der alte Shop nimmt ab diesem Moment keine Bestellungen mehr an: Checkout und Kundenkonto zeigen eine Wartungsseite, der Katalog bleibt auf Wunsch lesbar. Die Verwaltung wird gesperrt, damit niemand im Hintergrund Preise, Bestände oder Aufträge ändert. Dann läuft der Endabgleich: entweder ein zweiter vollständiger Abzug, wenn der Probelauf gezeigt hat, dass er schnell genug ist, oder die Übernahme aller Änderungen seit dem Erstabzug. Welche Variante passt, entscheidet die im Probelauf gemessene Dauer, nicht die Hoffnung. Vor dem Schreibstopp gehört ein geprüfter Sicherungsstand dazu, wie ihn der Backup-Service vorsieht - er ist der Rückweg, falls der Endabgleich scheitert.

Neben der Datenbank ziehen Dateien mit: Produktbilder, hochgeladene Dokumente, erzeugte Rechnungen und Lieferscheine. Auch sie werden zweimal übertragen - einmal vollständig beim Erstabzug, einmal als Differenz im Schreibstopp. Eine Rechnung, die nach dem Erstabzug erzeugt wurde, existiert sonst nur auf dem alten Server. Dasselbe gilt für Sitzungen: Liegen sie in Dateien statt in der Datenbank, verlieren Kunden beim Umschalten ihren Warenkorb. Das ist kein Datenverlust im engeren Sinn, aber ein abgebrochener Kauf, der sich durch die Ankündigung des Fensters vermeiden lässt. Zuletzt gehören Suchindex und Zwischenspeicher auf dem neuen Server nach dem Endabgleich neu aufgebaut, damit Katalog und Preise dem übertragenen Stand entsprechen.

Mit dem Server wird alles kopiert, was zeitgesteuert läuft: Crontab-Einträge, Systemtimer, die geplanten Aufgaben des Shopsystems und die Worker, die Warteschlangen abarbeiten. Nach dem Kopieren sind sie auf beiden Maschinen aktiv - und arbeiten gegen zwei Datenbanken oder, schlimmer, gegen dieselben externen Ziele. Der Bestellexport geht zweimal an die Warenwirtschaft, der Newsletter zweimal an die Liste, die Zahlungsabstimmung läuft doppelt. Die Regel ist einfach und geht im Umzugsstress leicht unter: Hintergrundaufgaben laufen zu jedem Zeitpunkt auf höchstens einer Maschine. Auf dem neuen Server bleiben sie bis zum Umschalten aus, auf dem alten werden sie mit dem Schreibstopp abgestellt. Wie sich stille Ausfälle solcher Aufgaben erkennen lassen, beschreibt der Beitrag zu Cronjobs und Hintergrundjobs im Shop.

Zahlungs- und Versanddienstleister melden Statusänderungen an eine hinterlegte Adresse. Sie lösen diesen Namen selbst auf, mit eigenen Resolvern und eigenen Caches. Erreicht eine Rückmeldung den alten Server und nimmt dieser sie an, gilt sie beim Dienstleister als zugestellt - der Zahlungsstatus steht dann aber in der alten Datenbank. Lehnt der alte Server sie dagegen mit einem Fehler ab, wiederholen Dienstleister die Zustellung in der Regel nach ihren eigenen Regeln. Die Weiterleitung aus dem vorigen Abschnitt löst beides. Zusätzlich gehört jede hinterlegte Rückmeldeadresse auf den Prüfstand, ebenso jede Freigabe nach IP-Adresse: Schnittstellen von Warenwirtschaft, Versand oder Marktplätzen lassen Anfragen oft nur von bekannten Adressen zu, und der neue Server hat eine neue. Wie diese Schnittstellen gepflegt werden, steht im Beitrag zu Zahlungs-APIs und Webhook-Fehlern.

Beim Mailversand verschiebt der Umzug die Absenderadresse. Versendet der Shop Bestellbestätigungen direkt vom Server, muss dessen neue IP-Adresse im SPF-Eintrag der Domain stehen, bevor die erste Mail hinausgeht, und der DKIM-Schlüssel muss mit umziehen. Beim SPF-Eintrag lauert eine harte Grenze: Die Auswertung darf höchstens 10 DNS-Abfragen (RFC 7208) auslösen, sonst endet sie mit einem dauerhaften Fehler. Wer für den Umzug einfach einen weiteren include-Eintrag ergänzt, kann diese Grenze überschreiten und damit die Prüfung aller Mails der Domain scheitern lassen. Liegen auch Postfächer beim alten Hoster, gilt für eingehende Mails dieselbe Logik wie bei Rückmeldungen: Ist der alte Mailserver nicht erreichbar, geht zunächst nichts verloren, denn ein sendender Server stellt die Mail zurück und versucht es später erneut. RFC 5321 empfiehlt dafür einen Abstand von mindestens 30 Minuten (RFC 5321) zwischen zwei Versuchen und eine Frist bis zum Aufgeben von mindestens 4 bis 5 Tagen (RFC 5321). Nimmt der alte Server dagegen weiter an, landen die Mails im alten Postfach und müssen dort abgeholt werden, bevor es gelöscht wird. Mehr zur Zustellbarkeit steht im Beitrag zu DMARC und Shop-Mails.

Das Zertifikat muss auf dem neuen Server gültig sein, bevor der erste Besucher ihn erreicht. Hier steckt eine Falle im Ablauf: Bei der verbreiteten HTTP-Prüfung nach dem ACME-Verfahren ruft die Zertifizierungsstelle eine Prüfdatei unter der Domain ab, und diese Anfrage geht an Port 80 (RFC 8555) des Servers, auf den die Domain gerade zeigt - vor dem Umschalten also an den alten. Ein neues Zertifikat lässt sich auf diesem Weg erst nach dem Umschalten ausstellen, und bis dahin sehen die ersten Besucher eine Zertifikatswarnung. Drei Auswege: das bestehende Zertifikat samt Schlüssel übernehmen, die Prüfung über einen DNS-Eintrag führen oder den Prüfpfad auf dem alten Server an den neuen weiterreichen. Nach dem Umzug läuft die automatische Erneuerung nur noch auf dem neuen Server; wie die Zertifikatsverwaltung das überwacht, ist Teil der laufenden Betreuung.

Das Skript beantwortet die drei Fragen, die nach dem Umschalten zählen: Gibt es Bestellungen, die nur auf dem alten Server existieren? Laufen irgendwo noch Cronjobs doppelt? Welche Resolver liefern noch die alte Adresse? Im Nachlauf läuft es mehrmals täglich, bis die erste Liste leer ist, nur noch ein Server aktive Cron-Zeilen meldet und alle geprüften Resolver die neue Adresse liefern.

Ein Umzug ist abgeschlossen, wenn sich das nachweisen lässt, nicht wenn die Startseite lädt. Die Startseite lädt auch dann, wenn der Checkout auf eine veraltete Schnittstelle zeigt, der Bestellexport nicht läuft und die Bestätigungsmails im Spamordner landen. Die Abnahme prüft deshalb die Wege, auf denen Umsatz entsteht, und die Stellen, an denen er verloren gehen kann.

Die Testbestellung ist der wichtigste Punkt der Liste, weil sie fast alle anderen berührt. Sie zeigt, ob die Zahlungsrückmeldung den richtigen Server erreicht, ob der Export läuft und ob die Mail ankommt. Wie sich der Bestellweg danach dauerhaft beobachten lässt, beschreibt der Beitrag zum Checkout-Monitoring.