feat: taegliche Datenbanksicherung mit dokumentierter Wiederherstellung

Es gab bisher keinerlei Sicherung: Bestellungen, Rechnungen,
Kundenkonten und Chargendaten lagen in einem einzelnen
PersistentVolume ohne Netz. Ein Speicherfehler, ein versehentliches
"kubectl delete pvc" oder ein misslungenes Cluster-Update haetten alles
davon unwiederbringlich geloescht. Rechnungen unterliegen in
Deutschland zusaetzlich einer zehnjaehrigen Aufbewahrungspflicht
(§ 147 AO) — ein Datenverlust waere hier nicht nur aergerlich, sondern
ein Rechtsproblem.

Neu: 07-backup-cronjob.yaml — naechtlicher pg_dump auf ein eigenes
Volume, gzip-komprimiert, 30 Tage Aufbewahrung, concurrencyPolicy
Forbid. Fehlgeschlagene Laeufe werden laenger aufgehoben als
erfolgreiche: nur an ihnen laesst sich per "kubectl logs"
nachvollziehen, warum eine Sicherung ausblieb.

Zwei Details, an denen Sicherungsskripte typischerweise scheitern:

- "set -o pipefail". Ohne das liefert "pg_dump | gzip" den Exit-Code von
  gzip, und gzip gelingt auch dann, wenn pg_dump vorher abgebrochen ist.
  Der Job galte als erfolgreich, im Verzeichnis laege eine
  abgeschnittene Datei, und das faellt erst im Ernstfall auf. Beide
  Varianten mit einem absichtlich abbrechenden Dump geprueft: ohne
  pipefail Exit 0 samt vollstaendig aussehender .sql.gz, mit pipefail
  Exit 1 und keine .sql.gz.
- Schreiben unter ".partial" und erst danach umbenennen, damit ein
  mitten im Lauf abgebrochener Job keine Datei hinterlaesst, die wie
  eine vollstaendige Sicherung aussieht. Liegengebliebene .partial-Reste
  raeumt derselbe Lauf mit auf.

k8s/README.md: neuer Abschnitt "Sicherung und Wiederherstellung" mit
Ansehen, manuellem Ausloesen, Herausziehen aus dem Cluster und dem
vollstaendigen Wiederherstellungsweg (App auf 0 skalieren, Dump
einspielen, wieder hochskalieren) — samt dem Hinweis, dass eine nie
getestete Sicherung keine Sicherung ist. Der Abschnitt "Bekannte
Grenzen" nannte "ohne Replikation/Backup-Automation"; das stimmt jetzt
nur noch zur Haelfte und ist entsprechend praezisiert: die Sicherung
liegt weiterhin im selben Cluster und ersetzt keine Replikation.

Alle Manifeste gegen einen YAML-Parser geprueft.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

k8s/README.md

@@ -73,6 +73,9 @@ kubectl apply -f k8s/04-uploads-pvc.yaml
 
 kubectl apply -f k8s/05-app-deployment.yaml
 kubectl apply -f k8s/06-ingress.yaml
+
+# Taegliche Datenbanksicherung (siehe "Sicherung und Wiederherstellung").
+kubectl apply -f k8s/07-backup-cronjob.yaml
 ```
 
 Migrationen + Seed (nur Admin-Konto, KEINE Beispieldaten — siehe Punkt 2
@@ -107,9 +110,67 @@ Redeploy.
   horizontale Skalierung zuerst `lib/rate-limit.ts` auf Redis o.ae. umstellen.
 - Kein `HorizontalPodAutoscaler`, kein `PodDisruptionBudget`, keine
   `NetworkPolicy` — je nach Cluster/Anforderungen ergaenzen.
-- Die Postgres-/MySQL-StatefulSets sind Single-Instance ohne Replikation/
-  Backup-Automation. Fuer produktiven Betrieb einen Managed-Datenbank-Dienst
-  oder einen dedizierten DB-Operator (z.B. CloudNativePG) in Erwaegung
-  ziehen — `DATABASE_URL` in `02-secret.yaml` einfach auf den externen
-  Endpunkt zeigen lassen, `03-postgres.yaml`/`03-mysql.yaml` dann nicht
-  anwenden.
+- Die Postgres-/MySQL-StatefulSets sind Single-Instance **ohne
+  Replikation**. Eine taegliche Sicherung gibt es inzwischen
+  (`07-backup-cronjob.yaml`, siehe "Sicherung und Wiederherstellung"), sie
+  liegt aber im selben Cluster und ersetzt damit weder Replikation noch
+  eine Auslagerung an einen anderen Ort. Faellt der Knoten aus, ist der
+  Shop bis zur Wiederherstellung offline. Fuer produktiven Betrieb mit
+  hoeherem Anspruch einen Managed-Datenbank-Dienst oder einen dedizierten
+  DB-Operator (z.B. CloudNativePG) in Erwaegung ziehen — `DATABASE_URL` in
+  `02-secret.yaml` einfach auf den externen Endpunkt zeigen lassen,
+  `03-postgres.yaml`/`03-mysql.yaml` dann nicht anwenden.
+
+## Sicherung und Wiederherstellung
+
+`07-backup-cronjob.yaml` legt jede Nacht um 03:15 Uhr eine
+gzip-komprimierte `pg_dump`-Sicherung auf einem eigenen Volume ab und
+haelt sie 30 Tage vor. Ohne diese Sicherung liegen Bestellungen,
+Rechnungen und Kundenkonten in einem einzelnen PersistentVolume ohne
+jedes Netz — und Rechnungen unterliegen in Deutschland einer
+zehnjaehrigen Aufbewahrungspflicht (§ 147 AO).
+
+**Sicherungen ansehen:**
+
+```bash
+kubectl get cronjob wabenhain-db-backup -n wabenhain
+kubectl logs -n wabenhain -l job-name --tail=50   # Ausgabe des letzten Laufs
+```
+
+**Sofort eine Sicherung ausloesen** (etwa vor einem riskanten Eingriff):
+
+```bash
+kubectl create job --from=cronjob/wabenhain-db-backup manuell-$(date +%s) -n wabenhain
+```
+
+**Aus dem Cluster herausziehen.** Die Sicherung im Cluster schuetzt gegen
+Volume-Verlust und Bedienfehler, nicht gegen den Ausfall des gesamten
+Clusters oder Standorts. Deshalb regelmaessig (oder per eigenem Cron auf
+einem Rechner ausserhalb) kopieren:
+
+```bash
+POD=$(kubectl get pod -n wabenhain -l job-name -o name | head -1)
+kubectl exec -n wabenhain "$POD" -- ls -1 /backup
+kubectl cp wabenhain/"${POD#pod/}":/backup/wabenhain-2026-01-31_0315.sql.gz ./wabenhain-2026-01-31.sql.gz
+```
+
+**Wiederherstellen.** Vorher die App anhalten, damit waehrend des
+Einspielens niemand schreibt — `--clean --if-exists` im Dump loescht die
+vorhandenen Tabellen zuerst:
+
+```bash
+kubectl scale deployment/wabenhain-app -n wabenhain --replicas=0
+
+gunzip -c wabenhain-2026-01-31.sql.gz   | kubectl exec -i -n wabenhain wabenhain-postgres-0 --       psql -U wabenhain -d wabenhain
+
+kubectl scale deployment/wabenhain-app -n wabenhain --replicas=1
+```
+
+Der App-Container fuehrt beim naechsten Start ohnehin
+`prisma migrate deploy` aus (siehe Dockerfile-CMD) — ein Dump aus einem
+aelteren Schemastand wird dadurch automatisch nachgezogen.
+
+**Eine ungepruefte Sicherung ist keine Sicherung.** Einmal nach der
+Einrichtung und danach gelegentlich einen Wiederherstellungsversuch gegen
+eine Wegwerf-Datenbank fahren, statt sich erst im Ernstfall darauf zu
+verlassen.