Fallstudie zur Backup-Wiederherstellung: 6 Stunden zurück
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.