2 Posts getaggt mit "Backup-Wiederherstellung"

Veröffentlicht am 6. August 2026

Eine fehlgeschlagene Plugin-Bereitstellung legte den Checkout eines kleinen Onlinehändlers um 09:13 lahm. Dieses Beispiel zur Wiederherstellung eines Ecommerce-Backups zeigt, was das Betriebsteam wiederherstellte, was es nicht wiederherstellte und warum der Shop bis 10:00 wieder Bestellungen annahm, ohne dabei stillschweigend gültige Kundenkäufe zu löschen.

Das unmittelbare Symptom war ein 502-Fehler im Checkout, während Kategorieseiten weiterhin aus dem Cache geladen wurden. Das Server-Monitoring zeigte eine normale CPU-, Speicher- und Festplattenauslastung. Die Logs deuteten stattdessen auf einen schwerwiegenden PHP-Fehler hin, der durch die neuen Dateien des Zahlungs-Plugins eingeführt wurde. Diese Unterscheidung ist wichtig. Ein Server-Neustart oder die Wiederherstellung aus einem Backup kann eine schlechte Situation verschlimmern, wenn die Live-Datenbank weiterhin Bestellungen erfasst.

Veröffentlicht am 10. Juli 2026

Um 02:14 UTC schrieb der Shop keine Bestellungen mehr in die Datenbank. Um 02:19 lieferte die Website zwar noch gecachte Seiten aus, aber der Checkout war bereits zur Fiktion geworden. Diese Fallstudie zur Backup-Wiederherstellung beschreibt, was danach auf einem Produktions-VPS für ein kleines E-Commerce-Unternehmen geschah, was wir wiederhergestellt haben, was wir nicht blind wiederhergestellt haben und warum der Dienst noch vor Sonnenaufgang wieder stabil war.

Der Kunde betrieb einen ziemlich standardmäßigen Stack für einen wachsenden Onlineshop - Nginx, PHP-FPM, MariaDB, Redis und ein Control Panel, das von zwei Mitarbeitenden ohne Sysadmin-Hintergrund genutzt wurde. Der Traffic war nicht riesig, aber das Timing war schmerzhaft. Eine Verkaufsaktion hatte das Bestellvolumen erhöht, die Datenbankschreibvorgänge erreichten Spitzenwerte, und ein Speicherproblem auf der Dateisystemebene begann, aktive Datenbanktabellen zu beschädigen. Nicht dramatisch im Hollywood-Stil, aber ernst genug, dass jede Minute zählte.

Die erste Aufgabe war nicht die Wiederherstellung. Die erste Aufgabe war, die Ausbreitung des Schadens zu stoppen. Wir versetzten die Anwendung in den Wartungsmodus, bewahrten den aktuellen Festplattenzustand zur Überprüfung auf und prüften, ob Replikation, Snapshots oder logische Dumps uns den saubersten Wiederherstellungspunkt lieferten. Das ist wichtiger, als die Leute gern zugeben. Schnelle Wiederherstellung ist gut. Eine schnelle Wiederherstellung beschädigter Daten ist nur eine schnelle Enttäuschung.