# RAPPORT-HOST — Backup-Konzept

> Status: **Konzept + Datenmodell stehen** (Migration `0004_backups.sql`). Die
> Erzeugungs-/Restore-Logik wird gebaut, sobald echtes Provisioning gegen einen
> laufenden Rapport-Stack läuft — vorher gäbe es nur leere Listen und Buttons
> ohne Funktion.

## 1 · Warum nicht jetzt schon „fertig"

Im aktuellen **MOCK-Modus** existieren keine echten Kunden-Datenbanken — Instanzen
sind synthetische DB-Einträge. Ein Backup-Mechanismus braucht aber echte
Studio-Daten in einem laufenden Postgres. Darum: Konzept + `backups`-Tabelle
jetzt, ausführende Logik mit echtem Stack.

## 2 · Was ein Backup im Modell A bedeutet

Wir hosten **Modell A**: ein geteilter Rapport-Stack, jeder Kunde ist ein
*Studio* (mandantengetrennt per RLS). Ein „Backup von Kunde X" ist deshalb
**kein** Full-DB-Dump, sondern ein **studio-bezogener Export**:

- alle Zeilen mit `studio_id = <Kunde>` aus allen relevanten Tabellen
- plus die zugehörigen Storage-Objekte (Quittungen/Logos) des Studios

Das hält Backups klein und verhindert, dass Kundendaten vermischt werden.

## 3 · Erzeugung (geplant)

| Aspekt | Entscheidung |
|---|---|
| Werkzeug | `pg_dump` mit studio-gefiltertem Export bzw. eine `export_studio(studio_id)`-RPC im Rapport-Schema |
| Zeitplan | täglich automatisch (cron im HOST-Backend) + manuell per Admin-Button |
| Speicherort | konfigurierbar via Env: lokale Disk (Default) oder S3/Backblaze |
| Verschlüsselung | at-rest (Storage-seitig) — bei externem Ziel Pflicht |
| Aufbewahrung | z.B. 7 tägliche + 4 wöchentliche (rotierend); konfigurierbar |
| Register | jede Datei wird in `backups` protokolliert (Status, Größe, sha256) |

## 4 · Restore (geplant, heikel)

Restore in einem Multi-Tenant-Stack ist die gefährlichste Operation. Regeln:

1. **Nur das eine Studio** wiederherstellen — niemals die ganze DB.
2. Vor Restore: **Sicherungs-Dump des aktuellen Studio-Stands** (Rollback-Option).
3. Restore in eine **Staging-Tabelle/Transaktion**, dann atomar umschalten.
4. Admin-Bestätigung mit Tippen des Kundennamens (kein Ein-Klick-Restore).
5. Audit-Log-Eintrag (wer/wann/welches Backup).

## 5 · Datenmodell (`backups`-Tabelle, schon angelegt)

`id · instance_id · account_id · trigger(scheduled|manual) · status(pending|ok|failed)
· storage_key · size_bytes · sha256 · error · created_at · completed_at`

Die Dump-**Dateien** liegen NICHT in der DB, nur die Metadaten. Die Admin-UI
liest später nur diese Tabelle (Liste pro Kunde) + löst manuelle Backups/Restores
über Endpunkte aus.

## 6 · Geplante API (noch nicht gebaut)

```
GET  /api/admin/accounts/:id/backups        Liste der Backups eines Kunden
POST /api/admin/instances/:id/backup        manuelles Backup auslösen
POST /api/admin/backups/:id/restore         Restore (mit Bestätigung)
GET  /api/admin/backups/:id/download         Dump herunterladen (signiert)
```

## 7 · Nächster Schritt

Erst **echtes Provisioning** (laufender Stack, echte Studio-Daten). Dann:
`export_studio`/`import_studio`-RPC im Rapport-Schema → HOST-Cron + Endpunkte →
Admin-UI (Backup-Liste im Kunden-Detail + manuelles Backup/Restore).