# CRM-Restore: PostgreSQL und synthetische Anhänge

Voraussetzungen: Python 3.10+, Docker und dieses exakt gepinnte Image. Nur falls es fehlt:

```sh
docker pull postgres:18.6-trixie@sha256:86c951e05bf56c93d95d397747fb8820ac76cc3bedb78f43abd83eedbe3666ae
```

Dann `run.py` in einem eigenen Verzeichnis speichern und ausführen:

```sh
python3 run.py > results.json
```

Keine Zieladressen oder Produktionszugänge. Der Runner erstellt einen Container mit zufälligem
Namen, ohne Netzwerk, ohne Host-Ports, mit temporären PostgreSQL-Daten und zufälligem Passwort.
Er entfernt ausschließlich seinen eigenen Container und sein temporäres Dateiverzeichnis.
Ein harter Prozessabbruch kann die automatische Bereinigung verhindern; fremde Container dürfen
für die Bereinigung nicht angefasst werden. Es werden keine Images automatisch nachgeladen.

14 Prüfungen: Änderung der Quelle nach dem Backup; zwei wiederhergestellte Kontakte;
Dateimetadaten; bewusst unvollständiger Datenbank-only-Restore; vollständige Datei-Hashes;
fehlender Nach-Backup-Datensatz; intakte Beziehungen; wiederhergestelltes RLS und FORCE RLS;
Alpha/Beta/ohne Organisation getrennt; kein INSERT-Grant; beschädigte Datei erkannt und repariert.
Die Wiederherstellung nutzt `pg_dump -Fc` und `pg_restore --exit-on-error` aus derselben Version.

## Umfang und Grenzen

Quelle und frisches Ziel sind Datenbanken in derselben isolierten PostgreSQL-Instanz.
Clusterrollen werden separat angelegt; der Datenbank-Dump sichert sie nicht. Die Datensicherung
findet im ruhenden Zustand statt. Lokale Dateien vertreten die Objektablage; keine S3-/Supabase-
Storage-API wird geprüft. Zwei Textdateien sind kein Größen- oder Leistungstest.
Die SQL-Variable `fixture.org` setzt ausschließlich die Testlogik: keine produktive Anmeldung.
Nur die Kontakttabelle hat die gezeigte Lesepolicy; keine Rechteprüfung für Downloadpfade,
Storage, Schreiboperationen, Kundenkonten oder Hintergrundjobs wird behauptet.

Die technische Zeit im Ergebnis beginnt vor der Anlage der Zieldatenbank und endet nach Import,
Fehlstellenprüfung, Dateikopie und Hashprüfung. Sie schließt Vorfallerkennung, die folgenden
Rechteprüfungen und Anwendungsstart aus. Kein RTO-Versprechen, kein gemessener regionaler Failover.
RPO/RTO eines Kundenprojekts müssen separat definiert und vollständig erprobt werden.

`results-2026-09-28.json` dokumentiert Zeit, Version, Image, Einzelprüfungen und Quelltext-SHA-256.
Anpassung unter der beiliegenden MIT-Lizenz; Artikel und obhut-Marke sind davon ausgenommen.