---
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 bd-Issue 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.