98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
---
|
||
title: DR-Playbook – Tenant/Event versehentlich gelöscht
|
||
sidebar_label: DR – Tenant/Event
|
||
---
|
||
|
||
Dieses Playbook beschreibt, wie du vorgehst, wenn ein Tenant oder Event versehentlich gelöscht oder stark beschädigt wurde. Es baut auf den allgemeinen Hinweisen aus `docs/ops/backup-restore.md` auf.
|
||
|
||
> Wichtig: Diese Schritte sollten zuerst in einer **Staging-Umgebung** geübt werden. In Produktion nur nach klarer Freigabe und mit sauberer Dokumentation anwenden.
|
||
|
||
## 1. Schadensbild erfassen
|
||
|
||
Bevor du irgendetwas wiederherstellst:
|
||
|
||
- **Was genau ist betroffen?**
|
||
- Nur ein Event (z.B. versehentlich im Admin archiviert/gelöscht)?
|
||
- Mehrere Events eines Tenants?
|
||
- Der komplette Tenant (inkl. Benutzer, Events, Pakete)?
|
||
- **Welche Daten fehlen/fehlerhaft?**
|
||
- Fehlen nur Metadaten (Events, Fotos, Pakete) oder auch Medien‑Dateien?
|
||
- Gibt es noch Spuren im Admin/UI (z.B. leere Übersichten, aber Logs mit Fehlermeldungen)?
|
||
- **Zeitfenster eingrenzen**
|
||
- Wann wurde der Fehler bemerkt?
|
||
- Wann war der Zustand sicher noch korrekt (z.B. vor letztem Deploy / gestern Abend)?
|
||
|
||
Diese Informationen bestimmen, welches Backup verwendet werden sollte.
|
||
|
||
## 2. Logische vs. physische Schäden unterscheiden
|
||
|
||
- **Logischer Schaden**
|
||
- Falsche Flags (Status falsch, Event „archiviert“ statt „aktiv“).
|
||
- Inkompatible Paket‑Zuweisungen, aber Daten sind noch vorhanden.
|
||
- Lösbare Fälle oft ohne Restore durch gezielte Updates / Admin‑UI.
|
||
- **Physischer Schaden**
|
||
- Reihen in Kern‑Tabellen gelöscht (z.B. `events`, `photos`, `event_media_assets`, `tenants`).
|
||
- Medien‑Dateien im Storage gelöscht/überschrieben.
|
||
|
||
Nur bei physischen Schäden ist ein Restore aus Backup nötig. Logische Schäden sollten möglichst mit minimalinvasiven Korrekturen behoben werden.
|
||
|
||
## 3. Vorgehen bei einzelnen Events
|
||
|
||
### 3.1 Datenbank – Event-Datensätze identifizieren
|
||
|
||
1. **Event-IDs ermitteln**
|
||
- Aus Logs, alten Links, Metriken oder Backups.
|
||
2. **Querverweise prüfen**
|
||
- `events` (Basisdaten), `photos`, `event_media_assets`, `event_packages`, ggf. `event_join_tokens`.
|
||
3. **Temporäre Restore-DB nutzen**
|
||
- Erzeuge eine temporäre Datenbank (z.B. `fotospiel_restore`) und spiele den relevanten Backup‑Dump ein.
|
||
- Dort die betroffenen Event‑Datensätze suchen.
|
||
|
||
### 3.2 Selektiver Restore von Event-Daten
|
||
|
||
Empfohlenes Muster:
|
||
|
||
- In **Restore-DB**:
|
||
- Exportiere alle relevanten Zeilen für das Event (z.B. `events`, `photos`, `event_media_assets`) in SQL/CSV.
|
||
- In **Produktions-DB**:
|
||
- Prüfe, ob IDs kollidieren (z.B. neue Events seit dem Backup).
|
||
- Freie IDs und referentielle Integrität beachten; wenn IDs bereits vergeben sind, ist ein reiner Import meist nicht möglich → dann manuelle Rekonstruktion (neues Event + Medien erneut verknüpfen).
|
||
|
||
> Dieses Playbook beschreibt bewusst kein generisches „SQL-Skript“, weil die tatsächliche Struktur und IDs von der aktuellen Migration abhängen. Ziel ist, die **Vorgehensweise** zu standardisieren, nicht ein unüberlegtes Massen‑Update.
|
||
|
||
### 3.3 Medien-Dateien
|
||
|
||
1. In der Restore‑Umgebung prüfen, welche Pfade `event_media_assets` für das Event referenzieren.
|
||
2. Im Backup‑Storage nach diesen Pfaden suchen (Hot‑ und ggf. Archiv‑Bucket).
|
||
3. Fehlende Dateien in das produktive Storage‑Volume/Bucket an den erwarteten Pfad kopieren.
|
||
|
||
Wenn die Medien physisch nicht mehr vorhanden sind, ist nur eine teilweise Rekonstruktion möglich (z.B. Thumbnails ohne Originale) – das sollte mit dem Tenant klar kommuniziert werden.
|
||
|
||
## 4. Vorgehen bei Tenant-weiten Fehlern
|
||
|
||
Wenn ein kompletter Tenant versehentlich gelöscht wurde (inkl. Benutzer/Events):
|
||
|
||
1. **Einordnung**
|
||
- Handelt es sich um einen isolierten Tenant oder könnten mehrere betroffen sein (z.B. durch fehlerhaftes Skript)?
|
||
2. **Restore-Strategie wählen**
|
||
- _Variante A: Partial Restore_ – nur die Tabellenzeilen zum Tenant aus der Backup‑DB in die Produktions‑DB zurückführen.
|
||
- _Variante B: Backup-Spiegel_ – Tenant + zugehörige Medien in eine separate Umgebung wiederherstellen und dem Kunden dort einen temporären Zugang geben.
|
||
3. **Risikoabwägung**
|
||
- Partial Restore in eine laufende Produktions‑DB trägt höhere Risiken (Kollisionsgefahr mit neuen Daten).
|
||
- Spiegel‑Variante ist operativ aufwändiger, kann aber sicherer sein, wenn viele neue Daten seit dem Backup hinzugekommen sind.
|
||
|
||
> Welche Variante gewählt wird, sollte von Platform‑Ops + Produkt gemeinsam entschieden werden.
|
||
|
||
## 5. Kommunikation & Dokumentation
|
||
|
||
- **Mit dem betroffenen Tenant**
|
||
- Ehrlich kommunizieren, was passiert ist, was wiederherstellbar ist und welches Risiko ein Restore birgt.
|
||
- Zeitrahmen und mögliche Einschränkungen klar benennen.
|
||
- **Intern**
|
||
- Den gesamten Prozess in einem `docs/process/changes/*`‑Eintrag oder im Ticketing festhalten:
|
||
- Was, wann, warum schief ging.
|
||
- Welche Restore‑Schritte durchgeführt wurden.
|
||
- Welche Verbesserungen künftig notwendig sind (z.B. bessere Schutzmechanismen, zusätzliche Bestätigungen beim Löschen).
|
||
|
||
Dieses Playbook ist bewusst höher‑levelig gehalten; spezifische SQL‑ oder Tool‑Snippets sollten ergänzend in einem internen Notizsystem oder als separate Anhänge gepflegt werden, sobald eure Backup‑Pipelines stabil etabliert sind.
|