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/betrieb/sicherung.md

@@ -27,19 +27,51 @@ ruft es als Erstes auf und bricht ab, wenn es fehlschlägt.
 ## Zurückspielen
 
 ```bash
-# Docker
-docker compose down
-docker compose up -d postgres
-gunzip -c sicherung.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
+bash deploy/restore.sh /var/backups/proxledger            # jüngste Sicherung
+bash deploy/restore.sh /var/backups/proxledger 20261010-192437   # bestimmter Stand
+```
+
+Das Skript hält Dashboard und Worker an, spielt Datenbank **und** hochgeladene PDFs zurück, startet
+alles wieder und prüft, ob das Dashboard antwortet. Vorher fragt es nach; `--ja` überspringt die
+Rückfrage (für Skripte).
+
+Die `.env` fasst es bewusst **nicht** an: Sie trägt `APP_SECRET`, und ein falscher Wert dort macht die
+gespeicherten Zugangsdaten für SMTP und Webhook unlesbar. Die zum Stand passende Fassung liegt als
+`env-<Stand>.txt` in der Sicherung – im Zweifel von Hand vergleichen.
+
+### Von Hand, wenn es sein muss
+
+```bash
+docker compose stop web worker
+gunzip -c datenbank-20261010-192437.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
+docker compose run --rm -T --entrypoint tar web -xzf - -C / < uploads-20261010-192437.tar.gz
 docker compose up -d
 ```
 
-Danach die `.env` mit **demselben** `APP_SECRET` zurücklegen wie zum Zeitpunkt der Sicherung. Ein
-anderer Wert lässt die gespeicherten Zugangsdaten unlesbar werden; das Dashboard sagt das beim
-nächsten Versand deutlich, aber die Werte müssen dann neu eingetragen werden.
+Bei der Installation als Dienst stattdessen `psql "$DATABASE_URL"` und `tar -xzf … -C /opt/proxledger/data`.
+
+## Geprobt am 10.10.2026
+
+Nicht behauptet, sondern durchgespielt – mit einem eigenen Stapel:
+
+1. Stand festgehalten (9 Hosts, 4 Kunden, 10 Laufzeiten), ein Kunde zur Wiedererkennung umbenannt,
+   eine PDF-Datei abgelegt
+2. Sicherung angelegt
+3. **Alle Daten zerstört** (`docker compose down -v` – Datenbank und Upload-Volume weg)
+4. `deploy/restore.sh` aufgerufen
+
+Ergebnis: Datenbank vollständig zurück (die umbenannte Kundin war wieder da), die PDF-Datei lag mit
+den richtigen Rechten im Upload-Ordner, Anmeldung mit dem alten Passwort funktionierte.
+
+Dabei zwei Lücken gefunden und geschlossen: Die Sicherung ließ sich nur in eine **leere** Datenbank
+zurückspielen (jetzt `pg_dump --clean --if-exists`), und für die hochgeladenen PDFs gab es überhaupt
+keinen beschriebenen Weg.
+
+> Geprobt wurde der Docker-Weg. Für die Installation als Dienst ist derselbe Ablauf im Skript
+> vorgesehen, aber noch nicht unter echten Bedingungen gelaufen.
 
 ## Das Wichtigste
 
 **Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung.** Spielen Sie sie einmal in eine
-leere Testumgebung ein und melden Sie sich dort an. Erst dann wissen Sie, dass Sicherung und
-`APP_SECRET` zusammenpassen.
+Testumgebung ein und melden Sie sich dort an. Erst dann wissen Sie, dass Sicherung und `APP_SECRET`
+zusammenpassen.