feat(deploy): Wiederherstellung proben und Skript dafuer (#045)

Einer der vier Punkte bis 1.0.0: eine Sicherung einmal wirklich
zurueckspielen. Mit einem eigenen Stapel durchgespielt - Datenstand
festgehalten, Marke gesetzt, PDF abgelegt, gesichert, alle Volumes
zerstoert, zurueckgespielt. Datenbank, PDF und Anmeldung waren zurueck.

Zwei Luecken kamen erst dabei heraus:

1. Ohne --clean liess sich die Sicherung nur in eine LEERE Datenbank
   zurueckspielen - im Ernstfall also gerade nicht. Jetzt
   pg_dump --clean --if-exists, gegen eine Datenbank mit Daten geprueft.
2. Fuer die hochgeladenen PDFs gab es keinen beschriebenen Weg zurueck.

deploy/restore.sh haelt die Dienste an, spielt Datenbank und PDFs zurueck,
startet wieder und prueft die Erreichbarkeit. Die .env bleibt unangetastet:
Sie traegt APP_SECRET, und ein falscher Wert dort macht gespeicherte
Zugangsdaten unlesbar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/issues/045-wiederherstellung-geprobt.md

@@ -0,0 +1,40 @@
+# #045 Wiederherstellung proben und Skript dafür
+**Status:** erledigt
+**Meilenstein:** v0.27.0
+**Labels:** deployment, doku
+**Geschätzt:** 2 h   **Tatsächlich:** 0 h 50 min
+
+## Ziel
+Einer der vier Punkte bis 1.0.0: eine Sicherung **einmal wirklich zurückspielen**. Bis dahin war nur
+geprüft, dass `deploy/backup.sh` Dateien schreibt.
+
+## Ablauf der Probe
+Mit einem eigenen Docker-Stapel, getrennt von allen anderen Daten:
+
+1. Datenstand festgehalten (9 Hosts, 4 Kunden, 10 Laufzeiten), einen Kunden zur Wiedererkennung in
+   `Marke-192641` umbenannt, eine PDF-Datei in den Upload-Ordner gelegt
+2. Sicherung angelegt
+3. **Alle Daten zerstört** – `docker compose down -v`, also Datenbank- und Upload-Volume weg
+4. Zurückgespielt und geprüft
+
+**Ergebnis:** Datenbank vollständig zurück (die Marke war wieder da), die PDF-Datei lag mit den
+richtigen Rechten im Upload-Ordner, Anmeldung mit dem alten Passwort funktionierte.
+
+## Zwei Lücken, die erst die Probe gezeigt hat
+1. **Die Sicherung ließ sich nur in eine leere Datenbank zurückspielen.** `pg_dump` ohne `--clean`
+   scheitert an bestehenden Tabellen – genau im Ernstfall, wenn man in eine laufende Installation
+   zurückspielen will. Jetzt `--clean --if-exists`; gegengeprüft gegen eine Datenbank mit Daten:
+   null Fehlerzeilen, der zwischenzeitlich geänderte Wert war wieder auf dem Stand der Sicherung.
+2. **Für die hochgeladenen PDFs gab es keinen beschriebenen Weg.** Gesichert wurden sie, zurückspielen
+   musste man selbst herausfinden.
+
+## Ergebnis
+- `deploy/restore.sh`: hält die Dienste an, spielt Datenbank und PDFs zurück, startet wieder und prüft
+  die Erreichbarkeit. Fragt vorher nach, `--ja` überspringt das.
+- Die `.env` wird bewusst **nicht** überschrieben: Sie trägt `APP_SECRET`, und ein falscher Wert dort
+  macht die gespeicherten Zugangsdaten unlesbar. Die passende Fassung liegt als `env-<Stand>.txt` daneben.
+- `docs/betrieb/sicherung.md` beschreibt den geprobten Ablauf samt Handarbeit als Rückfallebene.
+
+## Offen
+Geprobt wurde der Docker-Weg. Für die Installation als Dienst ist derselbe Ablauf im Skript
+vorgesehen, aber noch nicht unter echten Bedingungen gelaufen.

docs/issues/README.md

@@ -48,4 +48,5 @@ Details und Architektur: [../architektur.md](../architektur.md). Zeiten werden a
 | [#042](042-qdevice-cluster.md) | Cluster-Knoten falsch gelesen bei QDevice | erledigt | v0.24.1 | 1 h | 0 h 20 min |
 | [#043](043-laufzeiten-bearbeiten.md) | Laufzeiten anlegen, bearbeiten, zusammenführen | erledigt | v0.25.0 | 4 h | 1 h 05 min |
 | [#044](044-eigenbedarf.md) | Eigene Hosts ohne Weiterberechnung | erledigt | v0.26.0 | 2 h | 0 h 40 min |
-| | **Summe** | | | **175 h** | **24 h 38 min** |
+| [#045](045-wiederherstellung-geprobt.md) | Wiederherstellung proben und Skript dafür | erledigt | v0.27.0 | 2 h | 0 h 50 min |
+| | **Summe** | | | **177 h** | **25 h 28 min** |