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]>
2026-09-15 10:21:19 +02:00
1 parent 21ac8bbc6a
commit 979d39e677
@@ -0,0 +1,131 @@
+# Taegliche Sicherung der Datenbank.
+#
+# WARUM: 03-postgres.yaml haelt Bestellungen, Rechnungen, Kundenkonten und
+# Chargendaten in einem einzelnen PersistentVolume ohne jede Sicherung. Geht
+# dieses Volume verloren (Speicherfehler, versehentliches "kubectl delete
+# pvc", ein misslungenes Cluster-Update), sind saemtliche Bestellungen und
+# Rechnungen unwiederbringlich weg. Rechnungen unterliegen in Deutschland
+# ausserdem einer zehnjaehrigen Aufbewahrungspflicht (§ 147 AO) — ein
+# Datenverlust ist hier nicht nur aergerlich, sondern ein Rechtsproblem.
+#
+# Diese Sicherung liegt bewusst NUR im Cluster. Sie schuetzt gegen
+# Volume-Verlust und Bedienfehler, nicht gegen den Ausfall des gesamten
+# Clusters oder Standorts. Fuer eine vollstaendige Absicherung die
+# erzeugten .sql.gz-Dateien zusaetzlich regelmaessig aus dem Cluster
+# herausziehen (Beispielbefehl siehe k8s/README.md, Abschnitt "Sicherung
+# und Wiederherstellung").
+#
+# MYSQL STATT POSTGRES: laeuft die Installation mit DATABASE_PROVIDER=mysql
+# (03-mysql.yaml), stattdessen das Image "mysql:8.4.11" verwenden und den
+# pg_dump-Aufruf unten ersetzen durch:
+#   mysqldump -h wabenhain-mysql -u wabenhain -p"$PGPASSWORD" \
+#     --single-transaction --routines wabenhain | gzip -9 > "$file.partial"
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: wabenhain-db-backup
+  namespace: wabenhain
+spec:
+  accessModes:
+    - ReadWriteOnce
+  # storageClassName: "dein-storage-class"
+  resources:
+    requests:
+      # Eine gzip-komprimierte Sicherung dieses Datenbestandes liegt im
+      # niedrigen Megabyte-Bereich; 10Gi tragen die 30 Tage Aufbewahrung
+      # unten mit grossem Puffer.
+      storage: 10Gi
+---
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: wabenhain-db-backup
+  namespace: wabenhain
+spec:
+  # 03:15 Uhr — ausserhalb der ueblichen Bestellzeiten. Die Uhrzeit richtet
+  # sich nach der Zeitzone des Clusters (meist UTC).
+  schedule: "15 3 * * *"
+  # Kein zweiter Lauf, solange der vorherige noch laeuft.
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  # Fehlgeschlagene Laeufe laenger aufheben als erfolgreiche: nur an ihnen
+  # laesst sich per "kubectl logs" nachvollziehen, warum eine Sicherung
+  # ausblieb.
+  failedJobsHistoryLimit: 5
+  # Faellt ein Lauf aus (Knoten weg, Cluster-Wartung), gilt er nach einer
+  # Stunde als verpasst statt ewig nachgeholt zu werden.
+  startingDeadlineSeconds: 3600
+  jobTemplate:
+    spec:
+      backoffLimit: 2
+      template:
+        spec:
+          restartPolicy: OnFailure
+          # 70 ist die UID/GID des "postgres"-Nutzers im offiziellen
+          # Alpine-Image; fsGroup gibt dem Job Schreibrecht auf dem
+          # gemounteten Backup-Volume (gleiche Begruendung wie beim
+          # uploads-Volume in 05-app-deployment.yaml).
+          securityContext:
+            runAsUser: 70
+            runAsGroup: 70
+            fsGroup: 70
+          containers:
+            - name: pg-dump
+              # Gleiche Hauptversion wie der Server in 03-postgres.yaml —
+              # ein aelteres pg_dump kann eine neuere Datenbank nicht lesen.
+              image: postgres:16.15-alpine
+              env:
+                - name: PGPASSWORD
+                  valueFrom:
+                    secretKeyRef:
+                      name: wabenhain-secrets
+                      key: DB_PASSWORD
+              command: ["/bin/sh", "-c"]
+              args:
+                - |
+                  set -eu
+                  # pipefail ist hier das Wichtigste an diesem Skript:
+                  # ohne es liefert "pg_dump | gzip" den Exit-Code von gzip.
+                  # gzip gelingt auch dann, wenn pg_dump vorher abgebrochen
+                  # ist — der Job galte als erfolgreich und im Verzeichnis
+                  # laege eine abgeschnittene, beim Wiederherstellen
+                  # wertlose Datei. Genau so entstehen Sicherungen, die erst
+                  # im Ernstfall als unbrauchbar auffallen.
+                  set -o pipefail
+
+                  stamp="$(date -u +%Y-%m-%d_%H%M)"
+                  target="/backup/wabenhain-${stamp}.sql.gz"
+
+                  # Erst unter einem Zwischennamen schreiben, dann
+                  # umbenennen: ein mitten im Lauf abgebrochener Job
+                  # hinterlaesst so keine Datei, die wie eine vollstaendige
+                  # Sicherung aussieht.
+                  pg_dump --host=wabenhain-postgres --username=wabenhain \
+                    --dbname=wabenhain --clean --if-exists \
+                    | gzip -9 > "${target}.partial"
+                  mv "${target}.partial" "${target}"
+
+                  # Angefangene Dateien frueherer Abbrueche mit aufraeumen.
+                  find /backup -name 'wabenhain-*.sql.gz.partial' -mtime +1 -delete
+
+                  # 30 Tage Aufbewahrung. Achtung: ersetzt KEINE
+                  # langfristige Archivierung der Rechnungen (§ 147 AO,
+                  # zehn Jahre) — dafuer die Rechnungs-PDFs bzw. regelmaessig
+                  # ausgelagerte Sicherungen nutzen.
+                  find /backup -name 'wabenhain-*.sql.gz' -mtime +30 -delete
+
+                  echo "Sicherung abgeschlossen:"
+                  ls -lh /backup
+              resources:
+                requests:
+                  cpu: 50m
+                  memory: 128Mi
+                limits:
+                  memory: 256Mi
+              volumeMounts:
+                - name: backup
+                  mountPath: /backup
+          volumes:
+            - name: backup
+              persistentVolumeClaim:
+                claimName: wabenhain-db-backup
@@ -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.