Ein Backup ist kein Wiederanlauf. Wer Magento- oder WordPress-Hosting betreibt, merkt das meist erst im Ernstfall: Die Daten liegen irgendwo, aber niemand weiss, wie lange die Rücksicherung dauert, welche Systeme zuerst hochkommen und wann der Shop wieder bestellfähig ist. Genau hier entscheidet sich, ob ein Incident kontrolliert verläuft oder zum langen Umsatzverlust wird.
Warum RPO und RTO im Alltag zählen
Für den Betrieb sind zwei Kennzahlen wichtiger als jede allgemeine Verfügbarkeitsfloskel: RPO beschreibt, wie viel Datenverlust im Ernstfall akzeptabel ist, RTO wie lange ein System maximal ausfallen darf. Ein Shop mit hohem Bestellvolumen braucht andere Ziele als eine Unternehmenswebsite mit Kontaktformular. Wer diese Werte nicht definiert, diskutiert im Notfall über Gefühle statt über Prioritäten.
Ein typischer Use Case aus dem E-Commerce: Das Frontend ist offline, Bestellungen laufen nicht mehr ein, Kundinnen und Kunden sehen Fehlerseiten. Wenn das Monitoring nur «Server erreichbar» prüft, wird der eigentliche Schaden zu spät entdeckt. Erst die Kombination aus Applikationschecks, Datenbank-Latenz und Queue-Längen zeigt, ob es sich um eine kurze Störung oder um einen echten Produktionsausfall handelt.
Vor dem Ausfall: Was Monitoring wirklich messen sollte
Viele Hosting-Setups überwachen CPU und RAM, aber nicht die Engpässe, die für Webshops und Content-Systeme entscheidend sind. In der Praxis braucht es eine deutlich schärfere Sicht auf den Betrieb. Bei Cytracon wird für Managed-Hosting-Setups deshalb auf eine beobachtbare Kette geachtet: Webserver, PHP-FPM, Datenbank, Cache-Schicht und externe Abhängigkeiten.
- PHP-FPM: Anzahl laufender Worker, Wartezeiten in der Queue und Prozess-Auslastung
- MariaDB: langsame Queries, Locks, Buffer-Pool-Trefferquote und Verbindungen
- Redis: Latenz, Speicherverbrauch und Fehlerrate beim Lesen und Schreiben
- nginx: 5xx-Rate, Upstream-Timeouts und Header-Fehler
- SSL/TLS: Zertifikatslaufzeiten und fehlerhafte Handshakes
- DDoS-Schutz: auffällige Request-Spitzen, Verbindungsflut und Rate-Limits
Der Punkt ist nicht, möglichst viele Metriken zu sammeln. Entscheidend ist, dass aus dem Alarm eine klare Entscheidung folgt: drosseln, umleiten, reparieren oder zurückrollen.
Incident-Response statt Improvisation
Ein guter Wiederanlauf beginnt vor dem Incident mit einem Entscheidungsbaum. Wer darf eskalieren? Wer prüft zuerst die Erreichbarkeit? Wann wird in den Wartungsmodus geschaltet? Wann ist ein Restore schneller als eine Reparatur? Solche Fragen müssen vorab beantwortet sein, sonst entstehen Verzögerungen genau dann, wenn Zeit am teuersten ist.
Ein praxistauglicher Ablauf sieht oft so aus:
- Alarm bestätigen und Scope eingrenzen: nur Frontend, nur Checkout oder gesamte Plattform?
- Gesundheitscheck auf Applikations-, Cache- und Datenbankebene durchführen.
- Entscheiden, ob ein Konfigurationsfehler, ein Ressourcenengpass oder ein Datenproblem vorliegt.
- Falls nötig: in einen definierten Fallback-Modus gehen oder Last reduzieren.
- Wenn die Ursache unklar bleibt: kontrollierten Restore mit dokumentiertem Rollback-Pfad starten.
Besonders bei Magento ist dieser Ablauf wichtig, weil Störungen oft nicht dort entstehen, wo sie sichtbar werden. Ein langsamer Checkout kann von MariaDB, PHP-FPM oder einer blockierten Cache-Schicht kommen. Ohne klare Reihenfolge wird zu lange an der falschen Stelle gesucht.
Backup-Test ist nicht gleich Restore-Test
Viele Unternehmen verlassen sich auf die Meldung, dass Backups erfolgreich erstellt wurden. Das ist nützlich, aber nicht ausreichend. Erst ein Restore-Test zeigt, ob die Sicherung vollständig, aktuell und in der Praxis verwendbar ist. Besonders kritisch sind dabei die Wiederherstellungszeit und die Reihenfolge der Komponenten.
Ein reales Vorher/Nachher-Szenario:
Vorher: Backups laufen täglich, aber niemand prüft die Rücksicherung. Im Incident stellt sich heraus, dass die Datenbank zwar verfügbar ist, die Anwendung aber mit veralteten Konfigurationsdaten startet. Das Team verliert Stunden.
Nachher: Es gibt einen monatlichen Restore-Test mit definiertem Ziel: Datenbank, Medien, Konfiguration, Cronjobs und Cache-Reset. Ergebnis: Das Team kennt die effektive RTO, nicht nur die gewünschte.
Für den Betrieb zählt am Ende eine einfache Frage: Wie schnell sind wir wieder verkaufs- oder publikationsfähig? Die Antwort muss messbar sein, nicht geschätzt.
Kapazitätsplanung für Kampagnen und Lastspitzen
Incident-Response und Kapazitätsplanung gehören zusammen. Wer saisonale Aktionen, Newsletter-Spitzen oder Kampagnen plant, sollte die Wiederanlauffähigkeit des Hostings im Vorfeld prüfen. Eine Plattform kann auf dem Papier schnell sein und trotzdem in der Realität scheitern, wenn PHP-FPM-Pools zu klein dimensioniert sind oder MariaDB unter gleichzeitigen Schreiblasten einbricht.
Ein sinnvoller Check vor einer Aktion umfasst:
- Peak-Annahme mit realistischem Sicherheitszuschlag
- Überprüfung der PHP-FPM-Poolgrösse und Request-Backlog
- Kontrolle der Datenbank-Latenz unter Schreiblast
- Verifikation von Varnish- und Redis-Verhalten bei Cache-Miss-Wellen
- Prüfung der Alarmierung auf Eskalationszeiten, nicht nur auf Zustände
So wird aus Hosting nicht bloss Infrastruktur, sondern ein steuerbarer Betriebsprozess.
Was Cytracon in solchen Setups typischerweise absichert
Cytracon arbeitet bei Managed Hosting nicht nur an der Verfügbarkeit einzelner Dienste, sondern an der Betriebsfähigkeit des ganzen Stacks. Dazu gehören saubere SSL/TLS-Konfigurationen, belastbare Monitoring- und Alarmwege, nachvollziehbare Restore-Prozesse sowie eine Abstimmung zwischen nginx, PHP-FPM, Cache und Datenbank. Für Kunden bedeutet das: weniger Überraschungen, schnellere Entscheidungen und kürzere Wiederanlaufzeiten.
Der eigentliche Mehrwert liegt nicht im Versprechen «wir machen alles schneller», sondern in der Disziplin, Ausfälle in klare Schritte zu übersetzen. Das reduziert Schaden, beschleunigt die Kommunikation intern und schafft belastbare Erwartungen gegenüber Management, Vertrieb und Support.
Wenn Sie für Magento oder WordPress ein Hosting-Setup mit klaren RPO-/RTO-Zielen, getesteten Restores und belastbarem Monitoring aufbauen möchten, sprechen Sie mit uns: Kontakt aufnehmen.
