Checkliste für den Wiederherstellungstest einer Eventwebsite
Eine vorhandene Sicherung beweist noch keine Wiederherstellbarkeit. Stelle vor dem Ticketverkauf eine Kopie getrennt von der Live-Seite wieder her und prüfe den Besucherweg. Echte Teilnehmer- und Zahlungsdaten bleiben unangetastet.
Boletolibre-Redaktion
Veröffentlicht
1. Umfang und Ziele festlegen
Notiere Sicherungszeitpunkt mit Zeitzone, Verantwortliche und den kritischen Besucherweg. RTO ist die maximal akzeptable Unterbrechung, RPO der maximal akzeptable Datenverlust als Zeitspanne. Setze eigene Ziele und vergleiche sie mit dem Test; ein erfolgreiches Backup allein genügt nicht.[3][2]
| Festhalten | Beispiel |
|---|---|
| Besucherweg | Eventseite → Anmeldung oder Ticketlink → sichere Bestätigung |
| Wiederherstellungspunkt | Zeitpunkt, Zeitzone und Ablageort |
| RTO und RPO | Vom Team akzeptierte Grenzen |
| Testumgebung | Isoliert, ohne Änderung des Live-DNS |
2. Bestandteile der Sicherung prüfen
Prüfe Seiten und Datenbank, Dateien und Bilder, Konfiguration und Geheimnisse einzeln. Eine WordPress-Datenbanksicherung enthält beispielsweise weder Dateien, Themes und Plugins noch Uploads und Konfigurationsdatei. Externe Ticket- oder E-Mail-Dienste brauchen einen eigenen Wiederherstellungsplan.[4]
- Quelle und zuständige Person für jeden Datenbestand notieren.
- DNS und Zertifikat dokumentieren, ohne Produktion umzuschalten.
- Nicht geprobte externe Systeme ausdrücklich als nicht getestet kennzeichnen.
3. Ohne Live-Nebenwirkungen wiederherstellen
- Geschützte Testumgebung vorbereiten und Startzeit notieren.
- E-Mail, Webhooks, Analytik und echte Zahlungen abschalten oder umlenken; nur Testdaten verwenden.
- Dateien, Datenbank, Uploads und Konfiguration wiederherstellen; manuelle Schritte erfassen.
- Live-Seite und DNS unverändert lassen.
Die führende Checkliste empfiehlt eine isolierte Umgebung und Prüfungen von Dateien, Datenbank, Formularen und Integrationen.[1]
4. Den Besucherweg überprüfen
| Prüfung | Nachweis |
|---|---|
| Eventseite | Datum, Ort, Preis und Regeln passen zum Sicherungspunkt |
| Medien und Links | Bilder, Downloads und Ticketlink funktionieren |
| Anmeldung | Synthetischer Eintrag landet nur im Testziel |
| Kauf und Bestätigung | Testmodus ohne echte Belastung oder Teilnehmernachricht |
| Administration | Berechtigter Login und harmlose Teständerung |
Jeden Punkt als bestanden, fehlgeschlagen oder nicht getestet notieren. Eine geladene Startseite beweist keine funktionierende Anmeldung.
5. Ergebnis messen und erneut testen
Die Zeitmessung endet erst beim funktionierenden vereinbarten Besucherweg. Vergleiche die Dauer mit RTO und die Datenlücke mit RPO. Für kritische Fehler Verantwortliche und Wiederholungstermin festlegen.[2][3]
| Testprotokoll | Eintrag |
|---|---|
| Datum, Person, Umgebung | ________ |
| Sicherung und Zeitpunkt | ________ |
| RTO-Ziel / tatsächliche Dauer | ________ / ________ |
| RPO-Ziel / tatsächliche Datenlücke | ________ / ________ |
| Fehler, zuständige Person, Wiederholung | ________ |
Protokoll außerhalb der wiederhergestellten Seite ablegen und nach größeren Änderungen erneut testen.
Quellen und weiterführende Informationen
- Website Backup Restore Testing Checklistmybox.com · Abgerufen
- Perform periodic recovery testingAWS Well-Architected Framework · Abgerufen
- Define recovery objectives for downtime and data lossAWS Well-Architected Framework · Abgerufen
- Backing up your databaseWordPress Developer Resources · Abgerufen