fotospiel-app/docs/ops/dr-tenant-event-restore.md

title, sidebar_label

title	sidebar_label
DR-Playbook – Tenant/Event versehentlich gelöscht	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.