Files

T

karim 0daf6c393d feat(backup): Konzept (BACKUP.md) + backups-Datenmodell (0004)

Backup-Übersicht/Restore bewusst NICHT als Fake-UI gebaut — im Mock gäbe es
keine echten Kundendaten. Stattdessen:
- 0004_backups.sql: Register-Tabelle (Metadaten: instance/account, trigger,
  status, storage_key, size, sha256, Zeitstempel). Dump-Dateien liegen extern.
- BACKUP.md: Konzept für Modell A (studio-bezogener Export statt Full-Dump),
  Erzeugung (pg_dump/cron/Storage/Rotation), Restore-Sicherheitsregeln,
  geplante API. Bau der Logik, sobald echtes Provisioning steht.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-05-31 13:09:53 +02:00

3.1 KiB

Raw Blame History

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:

Nur das eine Studio wiederherstellen — niemals die ganze DB.
Vor Restore: Sicherungs-Dump des aktuellen Studio-Stands (Rollback-Option).
Restore in eine Staging-Tabelle/Transaktion, dann atomar umschalten.
Admin-Bestätigung mit Tippen des Kundennamens (kein Ein-Klick-Restore).
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).

3.1 KiB Raw Blame History