95 lines
5.0 KiB
Markdown
95 lines
5.0 KiB
Markdown
---
|
||
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 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.
|