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