From 979d39e6775887ef6cfc46ce972158f84a2315c0 Mon Sep 17 00:00:00 2001 From: Nick Szaunig Date: Tue, 15 Sep 2026 10:21:19 +0200 Subject: [PATCH] feat: taegliche Datenbanksicherung mit dokumentierter Wiederherstellung MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- k8s/07-backup-cronjob.yaml | 131 +++++++++++++++++++++++++++++++++++++ k8s/README.md | 73 +++++++++++++++++++-- 2 files changed, 198 insertions(+), 6 deletions(-) create mode 100644 k8s/07-backup-cronjob.yaml diff --git a/k8s/07-backup-cronjob.yaml b/k8s/07-backup-cronjob.yaml new file mode 100644 index 0000000..9b13ef1 --- /dev/null +++ b/k8s/07-backup-cronjob.yaml @@ -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 diff --git a/k8s/README.md b/k8s/README.md index 9f19772..de716a6 100644 --- a/k8s/README.md +++ b/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.