further rework to the documentation

docs/ops/backup-restore.md

@@ -0,0 +1,94 @@
+---
+title: Backup & Restore / Disaster Recovery
+sidebar_label: Backup & DR
+---
+
+Dieses Dokument beschreibt, was gesichert werden sollte, wie Backups geprüft werden und wie ein Restore im Notfall abläuft.
+
+## 1. Was muss gesichert werden?
+
+- **Datenbank**
+  - MySQL‑Datenbank (alle Schemas/Tables des Fotospiel‑Backends).
+  - Enthält Tenants, Events, Fotos‑Metadaten, Join‑Tokens, Abrechnungsdaten, Logs (soweit in DB).
+- **Medienspeicher**
+  - Hot‑Storage: Pfade unter `storage/app/private` / `storage/app/public` oder konfigurierten „hot“‑Disks.
+  - Archivspeicher: Buckets/Disks, in denen `event_media_assets` mit Status `archived` liegen.
+- **Konfiguration**
+  - `.env` Dateien (ohne sie in Git zu speichern), Dokploy‑Compose‑Konfigurationen, Secrets für externe Dienste.
+  - Optional: Horizon‑Konfiguration, Monitoring‑Dashboards.
+
+> TODO: Füge hier konkrete Pfade/Bucket‑Namen und die verwendeten Backup‑Tools (z.B. `mysqldump`, S3‑Snapshots, Dokploy‑Backups) ein.
+
+## 2. Backup-Strategie
+
+- **Datenbank-Backups**
+  - Frequenz: mindestens täglich (idealerweise alle 4–6 Stunden für Produktions‑DB).
+  - Aufbewahrung: z.B. 7–30 Tage, mit Off‑Site‑Kopie.
+  - Prüfschritte:
+    - Dump/Backupfile auf Plausibilität (Größe, letzte Änderung).
+    - Regelmäßige Test‑Restores in eine Staging‑DB:
+      - Beispiel (einfacher Dump auf Host – Pfade/Passwörter an Umgebung anpassen):
+        - `mysqldump -h 127.0.0.1 -u fotospiel -p fotospiel > fotospiel-$(date +%F).sql`
+      - Restore in temporäre DB (z.B. `fotospiel_restore`) und kurze Stichproben:
+        - `mysql -h 127.0.0.1 -u fotospiel -p fotospiel_restore < fotospiel-YYYY-MM-DD.sql`
+- **Medien-Backups**
+  - Hot‑Storage:
+    - Snapshot/Incremental‑Backup der Storage‑Volumes oder S3‑Buckets.
+  - Archive:
+    - Sicherstellen, dass Archiv‑Backups nicht versehentlich durch Lifecycle‑Policies gelöscht werden, bevor gesetzliche Retention erfüllt ist.
+- **Konfig-Backups**
+  - `.env` und Secrets nur verschlüsselt speichern (z.B. in einem Secrets‑Manager, nicht in Klartext‑Backups).
+  - Dokploy‑/Compose‑Konfiguration versionieren (Git) und zusätzlich sicher exportieren.
+
+## 3. Restore-Szenarien
+
+### 3.1 Einzelner Tenant/Event defekt
+
+1. Reproduzieren, ob der Fehler rein logisch (Datenkonsistenz) oder physisch (Fehlender Medien‑Blob) ist.
+2. **DB‑Restore (punktuell)**:
+   - Wenn möglich, nur relevante Tabellenbereiche (z.B. `tenants`, `events`, `photos`, `event_media_assets`, `event_packages`) aus Backup in eine temporäre DB laden.
+   - Differenzanalyse: welche Daten fehlen/fehlerhaft? Manuell oder via Skript zurückspielen.
+3. **Medien-Check**
+   - Fehlende Dateien im Hot/Archive‑Storage identifizieren (z.B. per `event_media_assets` Pfade + `Storage::disk()->exists`).
+   - Wenn Dateien im Backup vorhanden, gezielt an den richtigen Pfad zurückkopieren.
+
+> Diese Schritte sollten zuerst in einer Staging‑Umgebung eingeübt werden, bevor sie in Produktion angewendet werden.
+
+### 3.2 Betriebsweite Störung (DB/Storage Verlust)
+
+1. **DB wiederherstellen**
+   - Leere Datenbank aufsetzen, letztes konsistentes Backup einspielen.
+2. **Storage wiederherstellen**
+   - Hot‑Storage‑Backup auf Volumes/Buckets zurückspielen (z.B. Docker‑Volume `app-storage` oder zugeordneten Bucket).
+   - Archiv‑Buckets ggf. unverändert lassen, sofern noch intakt.
+3. **App & Queues**
+   - App mit readonly/maintenance‑Flag starten, Queues gestoppt lassen.
+   - Konsistenzprüfungen (z.B. stichprobenartige Tenants, Events, Medien, Abrechnungsdaten).
+4. **Queues wieder freigeben**
+   - Wenn die wichtigsten Funktionen wieder intakt sind, Queues/Horizon graduell zuschalten.
+
+> TODO: Ergänze konkrete Kommandos (Migrationsstatus prüfen, Health‑Checks) und definierte RTO/RPO‑Ziele.
+
+## 4. Tests & DR-Übungen
+
+- Mindestens 1–2 Mal pro Jahr einen vollständigen Restore in einer separaten Umgebung durchspielen:
+  - DB‑Backup einspielen.
+  - Medien‑Backups anbinden.
+  - Eine Handvoll Tenants/Events kompletter durchklicken (Upload, Galerie, Admin‑Funktionen).
+- Ergebnisse im `docs/process/changes/`‑Ordner dokumentieren (z.B. „DR‑Übung 2026‑Q1“ mit Learnings).
+
+## 5. Verantwortlichkeiten
+
+- **Backup-Ownership**: Wer stellt sicher, dass Backups laufen und testweise wiederhergestellt werden?
+- **DR-Ownership**: Wer führt die DR‑Übungen durch und wer entscheidet im Ernstfall über Failover/Restore?
+
+Diese Punkte sollten mit konkreten Namen/Rollen befüllt werden, damit im Ernstfall keine Unklarheiten bestehen.
+
+## 6. Ergänzende DR-Playbooks
+
+Spezielle DR‑Szenarien sind in separaten Runbooks beschrieben:
+
+- `docs/ops/dr-tenant-event-restore.md` – Vorgehen bei versehentlich gelöschten oder beschädigten Tenants/Events.
+- `docs/ops/dr-storage-issues.md` – Vorgehen bei Hot‑/Archive‑Storage‑Problemen (voll, hängende Archivierung, fehlende Medien).
+
+Dieses Dokument bleibt die High‑Level‑Übersicht – für konkrete Fälle solltest du immer auch die entsprechenden Playbooks konsultieren.