# WirtPilot Own Cloud – Backup- und Recovery-Vertrag

WirtPilot sichert Datenbank **und** hochgeladene Dateien. Ein Datenbankdump
allein enthält nicht die eigentlichen Supabase-Storage-Dateien. Konfiguration
ist erst dann ein Nachweis, wenn ein isolierter Restore technisch und fachlich
bestanden wurde.

## Schutzklassen

### Portable Daily – Standard für einen einzelnen inhabergeführten Betrieb

- vollständiger verschlüsselter Datenbank- und Storage-Export mindestens alle
  24 Stunden;
- getrennte, versionierte und gegen Überschreiben geschützte Offsite-Ablage;
- nachgewiesenes RPO höchstens 1.440 Minuten;
- nachgewiesenes RTO höchstens 60 Minuten;
- isolierter Restore mindestens vierteljährlich und nach wesentlichen
  Schema-/Operator-Änderungen.

Dieses Modell begrenzt laufende Kosten, kann im Katastrophenfall aber Daten seit
dem letzten erfolgreichen Lauf verlieren. Das Restaurant muss dieses Risiko
bewusst akzeptieren und den Sicherungszeitpunkt an seinen Betrieb anpassen.

### High Continuity – für geringe Verlusttoleranz

- vom Anbieter belegtes Point-in-Time-Recovery oder eine gleichwertig
  unabhängig nachgewiesene kontinuierliche Datenbanksicherung;
- gemessenes RPO höchstens 15 Minuten;
- separate versionierte Storage-Sicherung;
- gemessenes RTO höchstens 60 Minuten;
- isolierter Restore mindestens vierteljährlich und nach wesentlichen
  Änderungen.

Diese Schutzklasse kann kostenpflichtige Supabase-Funktionen oder zusätzliche
Infrastruktur benötigen. Aktuelle Preise werden im kundeneigenen Anbieter-Konto
vor Buchung geprüft und ausdrücklich bestätigt.

## Verbindlicher Ablauf

1. Der Portable Operator erstellt Streaming-Exporte ohne Secrets in Logs.
2. Der Offsite-Empfänger bestätigt das vollständige Bundle mit eigener,
   releasegebundener Signatur.
3. Ein separater Heartbeat belegt Intervall, Projektbindung und Alter der
   letzten erfolgreichen Sicherung.
4. Der Restore erfolgt ausschließlich in ein anderes, isoliertes Projekt ohne
   Produktionsdomain, Produktions-Cron oder reale Provider-Secrets.
5. Der Prüfer vergleicht Schema, Migrationen, RLS, Tabellenaggregate, Buckets
   und Datei-Hashes und testet Anmeldung sowie Kernabläufe.
6. Eine getrennte funktionale Beobachtung bestätigt RPO, RTO und Ergebnis.
7. Erst vier verschiedene kundeneigene Public-Key-Pins plus die
   Herausgebersignatur dürfen die Launch-Readiness entsperren.

Die technische Bedienung steht in
[`portable-backup-restore-operator.md`](portable-backup-restore-operator.md).
Ein Modusname oder Umgebungsvariablen ohne signierte, aktuelle Nachweise bleiben
fail-closed.