Staging, Backup und Rollback als Performance-Werkzeug

Cookbook: Ziel und Ergebnis

Jede relevante Performanceänderung besitzt Ausgangswert, reproduzierbaren Test, gemeinsam konsistentes Datei-/Datenbank-Backup und einen zeitlich realistischen Rückkehrweg.

Rezept: Schritt für Schritt

1. Änderung mit Hypothese, Verantwortlichem, betroffenen Ebenen und erwarteter Wirkung dokumentieren.
2. Dateien und Datenbank aus demselben Zeitpunkt sichern; Restore auf isolierter Umgebung prüfen und Dauer messen.
3. Staging auf gleiche PHP-/Server-/Plugin-Versionen und repräsentative Datenmenge bringen; Kundendaten anonymisieren.
4. Eine Variable ändern, technische Messreihe und Funktionsmatrix durchführen, dann kontrolliert live ausrollen und beobachten.

Rechenweg oder Entscheidungsregel

RTO = maximal akzeptable Wiederherstellungsdauer\nRPO = maximal akzeptabler Datenverlustzeitraum\nRollback-Budget = Erkennungszeit + Entscheidungszeit + Wiederherstellungszeit + Verifikation

Praxisbeispiel

Shop erlaubt RTO 30 min und RPO 5 min. Ein tägliches Backup mit 90-min-Restore erfüllt beides nicht. Vor Cache-/DB-Änderung braucht es aktuelles konsistentes Backup, getesteten 20-min-Restore und klaren Schwellwert, etwa Checkout-Fehler > 1 %.

Prüfen, ob es funktioniert

• Backup lässt sich tatsächlich öffnen/wiederherstellen; Checksums oder Testrestore bestätigen Vollständigkeit.
• Funktionsmatrix enthält Login, Formulare, Cron, Mail, Suche, Upload, Mobil und ggf. Checkout.
• Monitoring hat klare Abbruchwerte und Beobachtungsdauer.

Rollback

Nicht „irgendwie zurückbauen“, sondern dokumentierte Konfiguration/Dateien und – nur wenn nötig – dazu konsistente Datenbank wiederherstellen. Bei laufenden Bestellungen niemals eine alte DB blind einspielen; zunächst reversible Konfigurationsänderung zurücknehmen.

Vor jeder riskanten Änderung

Sichere Dateien und Datenbank zusammen und prüfe, wie lange eine Wiederherstellung dauert. Staging sollte PHP-, Server- und Plugin-Versionen sowie relevante Datenmengen abbilden; sensible Kundendaten müssen geschützt oder anonymisiert werden.

Änderungsprotokoll

Dokumentiere Ausgangswert, Hypothese, genaue Einstellung/Codeänderung, Zeitpunkt, Cache-Zustand, Testergebnis und Rollback. Ändere eine Variable pro Test. So lässt sich Ursache statt Korrelation feststellen.

Funktionsmatrix

Neben Startseite gehören Login, Suche, Formulare, Medien, Cron, Mails, Checkout und mobile Darstellung in den Testplan. Cache-, Datenbank- und PHP-Änderungen können Fehler nur in seltenen Pfaden erzeugen.

Erfolgskontrolle

Eine Änderung wird nur übernommen, wenn Nutzen reproduzierbar, Nebenwirkungen akzeptabel und Rollback erprobt sind. Beobachtung nach Live-Schaltung gehört zur Maßnahme.

Quellen und Prüfstand

• WordPress: Performance-Optimierung
• Google: Web-Vitals-Workflow

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.