fotospiel-app/docs/ops/backup-restore.md

title, sidebar_label

title	sidebar_label
Backup & Restore / Disaster Recovery	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 als bd-Issue 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.