Backup-Konzept (komponentenweise)#

Kubernetes#

Backup-Strategie, Frequenz, Retention#

Siehe Kapitel Backup-Strategie

Backup-Prozedur und entsprechender Automation#

• Ressourcen-Definitionen: Ein Großteil der Kubernetes-Ressourcen (Deployments, Services, ConfigMaps) ist deklarativ in Git hinterlegt und erfordert keine separate Sicherung.

Ausnahme Secrets: Da Secrets zukünftig primär über einen Managed Vault verwaltet und in den Cluster injiziert werden (statt statisch im Git zu liegen), ist eine Sicherung ihres Laufzeit-Zustands zwingend erforderlich. Hierfür wurde ein dedizierter PreBackupPod (secrets-pre-backup-kubectl) eingerichtet. Weitere Details finden sich im Abschnitt PrebackupPods.

• PVCs Backup: Für die Sicherung der Persistent Volume Claims (PVCs) kommt der K8up Operator zum Einsatz. Er stellt sicher, dass alle persistenten Daten regelmäßig gesichert werden.

Wichtig: Nur PVCs, bei denen die Annotation k8up.io/backup: "false" gesetzt ist, werden explizit vom Backup ausgeschlossen.

Die Automatisierung des Backup Prozesses für PVCs erfolgt durch den Schedule Custom Resource (CR), der täglich um 23:00 Uhr Backups auslöst.

Hier ist die Liste der PersistentVolumeClaims (PVCs), die K8up standardmäßig sichert.

PrebackupPods#

Neben den PVC-Backups werden für bestimmte Komponenten PreBackupPods eingesetzt, um konsistente, applikationsspezifische Backups zu erzeugen. Diese Pods führen vor dem eigentlichen PVC-Backup logische Dumps oder spezielle Aktionen aus.

• Blacklist-Mechanismus

  Der Pod blacklist-specific-pvcs-pre-backup sorgt dafür, dass bestimmte PVCs vom Backup ausgeschlossen werden, indem er die Annotation k8up.io/backup=false setzt.

  Betroffene PVCs:

  Durch die aktuelle Logik werden folgende PVC-Gruppen ausgeschlossen:

  • openproject-web-*-app-tmp

  • openproject-web-*-tmp

  • openproject-worker-default-*-app-tmp

  • openproject-worker-default-*-tmp

  • shared-run-ums-ldap-server-primary-*

  • shared-run-ums-ldap-server-secondary-*

  • shared-data-ums-ldap-server-primary-*

  • shared-data-ums-ldap-server-secondary-*

• PostgreSQL-Datenbanken

  Für alle Anwendungen, die PostgreSQL nutzen, wird vor dem PVC-Backup ein logischer Dump erstellt. Dies geschieht über folgende PreBackupPods:

  • guardianmanagementapi-pre-backup-postgres
  • keycloak-extensions-pre-backup-postgres
  • matrix-pre-backup-postgres
  • nextcloud-pre-backup-postgres
  • notes-pre-backup-postgres
  • notificationsapi-pre-backup-postgres
  • nubusauthsession-pre-backup-postgres
  • openproject-pre-backup-postgres
  • selfservice-pre-backup-postgres
  • xwiki-pre-backup-postgres

  Jeder dieser Pods führt den Befehl pg_dump -O aus und erzeugt einen vollständigen SQL-Dump der jeweiligen Datenbank. Weitere Details sind im Kapitel 3.2, Abschnitt PostgreSQL zu finden.

• MariaDB-Datenbanken

  Die Open-Xchange App Suite nutzt MariaDB. Der Pod oxappsuite-pre-backup-mariadb erstellt einen vollständigen Dump aller Datenbanken mit mariadb-dump --all-databases. Details hierzu finden sich in Kapitel 3.2, Abschnitt MariaDB.

• Apache Cassandra

  Für Cassandra wird kein Dump erstellt, sondern ein konsistenter Snapshot aller Keyspaces. Der PreBackupPod cassandra-pre-backup führt auf jedem Cassandra-Pod den Befehl nodetool snapshot aus. Details hierzu finden sich in Kapitel 3.2, Abschnitt Apache Cassandra.

• Secrets

  Der PreBackupPod secrets-pre-backup-pod exportiert alle Kubernetes-Secrets im Namespace als JSON-Datei (kubectl get secrets -o json). Der erzeugte Export wird an STDOUT ausgegeben, von K8up direkt eingelesen und anschließend über Restic verschlüsselt in das konfigurierte S3-Repository hochgeladen.

LDAP-Verzeichnis#

LDAP wird in diesem Konzept separat betrachtet, da es sich nicht um eine klassische relationale Datenbank handelt, sondern um ein verzeichnisbasiertes System. Die Sicherung erfordert daher einen anderen Ansatz als bei PVC-basierten Backups. Der LDAP-Server läuft als StatefulSet innerhalb des Kubernetes-Clusters. StatefulSets sind für zustandsbehaftete Workloads konzipiert und stellen sicher, dass jeder Pod eine stabile Identität hat.

Ein LDAP-Backup bedeutet, die gesamte Verzeichnisstruktur und deren Inhalte in einem konsistenten Format zu exportieren. Dies wird nicht durch das Kopieren des PVC erreicht, sondern durch einen applikationsspezifischen Prozess. Die relevanten Annotationen (Ausschnitt aus LDAP StatefulSets) für den Backup-Prozess lauten:

  k8up.io/backup: "true"
  k8up.io/backupcommand: slapcat
  k8up.io/file-extension: .ldif

Der PrebackupPod ldap-pre-backup annotiert die LDAP-Pods mit den erforderlichen K8up-Parametern (backupcommand=slapcat, file-extension=.ldif). Dadurch erstellt K8up einen vollständigen LDIF-Dump der Verzeichnisdaten. In diesem Fall sichert K8up nicht das Volume selbst, sondern führt im Pod den LDAP-eigenen Befehl "slapcat" aus. Dieser erzeugt einen konsistenten Export der gesamten LDAP-Datenbank im LDIF-Format. Die resultierende .ldif-Datei wird dann von K8up in das definierte Backup-Ziel hochgeladen. Ein PVC wird hier nicht direkt gesichert, da slapcat bereits eine logische Datensicherung erzeugt, die unabhängig von der internen Dateistruktur ist. Die Automatisierung des Backup Prozesses für PVCs erfolgt durch den Schedule Custom Resource (CR), der täglich um 23:00 Uhr Backups auslöst.

Backup-Monitoring und Validierung#

Das Monitoring der K8up-Jobs ist entscheidend, um die Zuverlässigkeit und Wiederherstellbarkeit der gesamten Kubernetes-Umgebung sicherzustellen. Ein Backup, das unbemerkt fehlschlägt oder veraltet ist, kann im Ernstfall wertlos sein – daher muss der Prozess kontinuierlich überwacht und validiert werden. Für das Monitoring wird das bestehende Tool Prometheus genutzt. K8up exportiert eigene Prometheus-kompatible Metriken, die den Zustand aller Backup-, Prune- und Restore-Jobs abbilden. Diese Metriken sind über einen dedizierten Service-Endpoint im Cluster verfügbar. Der Endpoint kann mit folgendem Befehl überprüft werden:

kubectl get svc -n k8up

Beispielausgabe:

NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
k8up-metrics   ClusterIP   100.82.59.199   <none>        8080/TCP   55d

Die "k8up-metrics" Service stellt einen HTTP-Endpunkt unter dem Pfad /metrics bereit. Dieser Endpunkt liefert alle von K8up exportierten Monitoring-Daten im Prometheus-Format.

Ein Ausschnitt aus den Metriken, die K8up zur Verfügung stellt, sind:

Die 3 Kernmetriken:

• k8up_jobs_total
• k8up_jobs_successful_counter
• k8up_jobs_failed_counter

bilden die Grundlage für jede Backup-Überwachung.

Darüberhinaus können noch weitere Metriken aus dieser Tabelle hilfreich sein:

• Schedule-Integrität

  • k8up_schedules_gauge

  Diese Metrik zeigt, ob k8up die definierten Backup-Schedules überhaupt verarbeitet.

• Operator-Funktionalität

  • controller_runtime_reconcile_errors_total
  • controller_runtime_reconcile_total{result="error"}

  Diese Metriken stellen Infomration über den K8up Operator zur Verfügung. Wenn der Operator nicht funktioniert, gibt es gar keine Backups.

Der Monitoring-Fluss sieht dabei wie folgt aus:

• K8up führt regelmäßig Backup-, Prune- oder Check-Jobs aus und schreibt Statusinformationen in den internen Prometheus-Endpoint (k8up-metrics:8080/metrics).
• Prometheus scrapet diesen Endpoint periodisch (z. B. alle 30 Sekunden) und speichert die Metriken als Zeitreihen.
• PromQL-Regeln werten die Metriken aus.
• Alertmanager empfängt die ausgelösten Alerts und sendet Benachrichtigungen an z.b. Zuständige.
• Grafana visualisiert den Zustand aller Backups, Trends und Laufzeiten in Dashboards.
• Darüberhinaus werden die zuständigen Rollen, nämlich Backup-Admin und Restore-Admin benachrichtigt.

flowchart TB
 subgraph K8up["(1) K8up Jobs & Operator"]
    direction TB
        B1["Backup Job"]
        B2["Prune Job"]
        B3["Check Job"]
        B4["Restore Job"]
  end
 subgraph Prometheus["(2) Prometheus"]
        P1["Scrape /metrics"]
  end
 subgraph Alerting["(3) PromQL-Regeln & (4) Alertmanager"]
    direction TB
        R["PromQL Rules<br>(z. B. fehlgeschlagene Backups)"]
        A["Alertmanager"]
  end
 subgraph Grafana["(5) Grafana Dashboards"]
        G["Visualisierung & Backup Status"]
  end
 subgraph s1["(5) Benachrichtigung"]
        n2["Backup-Admin"]
        n3["Restore-Admin"]
  end
    B1 --> M["/metrics Endpoint"]
    B2 --> M
    B3 --> M
    B4 --> M
    M --> P1
    P1 --> R & G
    R --> A
    A --> G & n2 & n3

    n2@{ shape: rounded}
    n3@{ shape: rounded}
     B1:::job
     B2:::job
     B3:::job
     B4:::job
     P1:::prom
     R:::alert
     A:::alert
     G:::graf
     M:::metric
    classDef job fill:#1e293b,stroke:#0f172a,color:#fff,rx:6,ry:6
    classDef metric fill:#3b82f6,stroke:#1d4ed8,color:#fff,rx:6,ry:6
    classDef prom fill:#16a34a,stroke:#166534,color:#fff,rx:6,ry:6
    classDef alert fill:#eab308,stroke:#a16207,color:#000,rx:6,ry:6
    classDef graf fill:#dc2626,stroke:#7f1d1d,color:#fff,rx:6,ry:6
    classDef group fill:#f1f5f9,stroke:#94a3b8,rx:10,ry:10,color:#000

Prometheus-Einstellungen#

Da kube-prometheus-stack bereits verwedent wird, können die Prometheus-Operator-CRDs genutzt werden, um k8up-Metriken einfach und deklarativ einzubinden. Zuerst muss überprüft werden, ob ServiceMnitor CRD installiert ist. Die CRD servicemonitors.monitoring.coreos.com muss vorhanden sein, da sie für die automatische Erfassung des k8up-metrics Service benötigt wird.

ServiceMonitor für k8up#

Mit einem ServiceMonitor kann Prometheus den K8up-Metrics-Endpunkt (/metrics) regelmäßig scrapen. In der folgenden Beispielkonfiguration wird Prometheus den k8up-metrics Service automatisch überwachen, indem es den Endpunkt /metrics alle 30 Sekunden abfragt.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: k8up-servicemonitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: k8up
  namespaceSelector:
    matchNames:
      - k8up
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

PromQL-Regeln für Alerts#

Sobald die Metriken verfügbar sind, können sinnvolle PromQL-Regeln definiert werden, um die Backup-Integrität sicherzustellen.

• Beispiele für hilfreiche PromQL-Regeln bezüglich Backup-, Prune- und Check-Jobs:

  • Backup-Staleness (kein Backup in 24h):

    increase(k8up_jobs_successful_counter{jobType="backup"}[24h]) == 0
    

    Beschreibung: Löst aus, wenn in den letzten 24 Stunden kein erfolgreicher Backup-Job ausgeführt wurde. Kritisch für die Sicherstellung der täglichen Backups.

  • Prune-Staleness (kein Prune seit 7 Tagen):

    increase(k8up_jobs_successful_counter{jobType="prune"}[7d]) == 0
    

    Beschreibung: Alarmiert, wenn seit 7 Tagen kein Prune-Job erfolgreich war. Wichtig, um alte Daten zu entfernen und Speicherplatz freizuhalten.

  • Check-Staleness (kein Check seit 7 Tagen):

    increase(k8up_jobs_successful_counter{jobType="check"}[7d]) == 0
    

    Beschreibung: Meldet, wenn seit einer Woche kein Check-Job durchgeführt wurde. Diese Jobs prüfen die Integrität des Backup-Repositories.

• Beispiele für hilfreiche PromQL-Regeln bezüglich Restore-Job:

  • Restore-Fehler:

    increase(k8up_jobs_failed_counter{jobType="restore"}[30m]) > 0
    

    Beschreibung: Löst aus, wenn in den letzten 30 Minuten ein Restore-Job fehlgeschlagen ist. Da Restores nicht regelmäßig laufen, ist dies ein ereignisbasierter Alarm für kritische Wiederherstellungsprobleme.

Diese Regeln können in einer PrometheusRule-Ressource hinterlegt werden, um Alerts über den Alertmanager auszulösen.

Datenbanken#

Datenbanken bilden das Rückgrat vieler zentraler Anwendungen. Ein konsistentes Backup dieser Systeme ist daher essenziell, um Datenverlust zu vermeiden und eine schnelle Wiederherstellung im Ernstfall zu gewährleisten. Im Folgenden werden die Backup-Mechanismen für die Datenbanktypen beschrieben, die eingesetzt werden.

PostgreSQL#

PostgreSQL ist eine der zentralen Datenbanken in der Plattform und wird von mehreren Komponenten genutzt:

• Element / Synapse (Chat-Backend)
• Nubus (Portal-Komponente)
• OpenProject (Projektmanagement)
• XWiki (Wissensplattform)
• Nextcloud (Datei- und Kollaborationsplattform)
• Notes-App

Darüber hinaus existieren weitere Services wie Guardian Management API, Keycloak-Extensions, Selfservice und Notifications, die ebenfalls PostgreSQL verwenden.

Backup-Strategie, Frequenz, Retention#

Siehe Kapitel Backup-Strategie

Backup-Prozedur und entsprechender Automation#

Um eine konsistente Sicherung zu gewährleisten, wird vor jedem PVC-Backup durch K8up ein sogenannter PreBackupPod ausgeführt. Dieser Pod führt innerhalb des Datenbank-Containers ein logisches Dump-Backup aus. Dadurch werden alle relevanten Tabellen und Schemata unabhängig von der darunterliegenden Dateistruktur gesichert. Der PreBackupPod wird von K8up automatisch gestartet, bevor das eigentliche PVC-Snapshot-Backup erfolgt. Das definierte Kommando erstellt per pg_dump eine vollständige SQL-Dump-Datei der Datenbank, die im Volume abgelegt wird.

Ausschnitt aus k8up/templates/PreBackupPod-postgres.yml:

backupCommand: sh -c 'PGDATABASE="$POSTGRES_DB" PGUSER="$POSTGRES_USER" PGPASSWORD="$POSTGRES_PASSWORD" PGHOST="$POSTGRES_HOST" PGPORT="$POSTGRES_PORT" pg_dump -O'

Der Befehl pg_dump -O erstellt ein logisches Backup der PostgreSQL-Datenbank im SQL-Format, ohne Eigentümer-Informationen (OWNER TO ...) zu übernehmen. Der erzeugte Dump wird an STDOUT ausgegeben, von K8up direkt eingelesen und anschließend über Restic in das konfigurierte S3-Repository hochgeladen.

Die eingesetzten PreBackupPods sind:

• guardianmanagementapi-pre-backup-postgres – sichert die Datenbank der Guardian Management API
• keycloak-extensions-pre-backup-postgres – sichert die Datenbank für Keycloak-Erweiterungen
• matrix-pre-backup-postgres – sichert die Datenbank für Matrix/Synapse (Chat-Backend)
• nextcloud-pre-backup-postgres – sichert die Nextcloud-Datenbank
• notes-pre-backup-postgres – sichert die Datenbank des Notes-Dienstes
• notificationsapi-pre-backup-postgres – sichert die Datenbank für Benachrichtigungen
• nubusauthsession-pre-backup-postgres – sichert die Datenbank für Nubus-Authentifizierung
• openproject-pre-backup-postgres – sichert die OpenProject-Datenbank
• selfservice-pre-backup-postgres – sichert die Datenbank für den Selfservice-Dienst
• xwiki-pre-backup-postgres – sichert die XWiki-Datenbank

Jeder dieser Pods führt den Befehl pg_dump -O aus, um einen vollständigen SQL-Dump der jeweiligen Datenbank zu erstellen.

Backup-Monitoring und Validierung#

Siehe Kapitel Backup-Monitoring und Validierung

MariaDB#

MariaDB wird nur von Open-Xchange genutzt.

Backup-Strategie, Frequenz, Retention#

Siehe Kapitel Backup-Strategie

Backup-Prozedur und entsprechender Automation#

Auch hier wird vor dem PVC-Backup ein PreBackupPod gestartet, der einen Datenbank-Dump erzeugt. Der Backup-Befehl für MariaDB lautet:

Ausschnitt aus ...\prebackuppods\oxappsuite-pre-backuppod.yaml:

backupCommand: sh -c 'MYSQL_PWD="$MYSQL_PASSWORD" mariadb-dump -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u "$MYSQL_USER" --all-databases '

Der Befehl mariadb-dump --all-databases erstellt ein logisches Backup aller MariaDB-Datenbanken im SQL-Format. Dies passiert in einem PreBackupPod namens oxappsuite-pre-backup-mariadb. Das erzeugte Backup wird an STDOUT ausgegeben, von K8up direkt eingelesen und anschließend über Restic in das konfigurierte S3-Repository übertragen.

Backup-Monitoring und Validierung#

Siehe Kapitel Backup-Monitoring und Validierung

Apache Cassandra#

Cassandra wird von Dovecot verwendet und läuft als StatefulSet innerhalb des Kubernetes-Clusters.

Backup-Strategie, Frequenz, Retention#

Siehe Kapitel Backup-Strategie

Backup-Prozedur und entsprechender Automation#

Die Sicherung von Apache Cassandra unterscheidet sich grundlegend von PostgreSQL und MariaDB, da Cassandra eine verteilte NoSQL-Datenbank ist. Ein konsistentes Backup erfordert die Erstellung von Snapshots auf allen Nodes, bevor die PVCs gesichert werden. Anstatt die Sicherung über K8up-Annotationen direkt im Pod auszuführen, wird in der aktuellen Architektur ein dedizierter PreBackupPod eingesetzt:
cassandra-pre-backup

Dieser Pod übernimmt folgende Aufgaben:

• Ermittelt alle Cassandra-Pods im Namespace.
• Führt auf jedem Pod den Befehl nodetool snapshot aus, um einen konsistenten Snapshot der relevanten Keyspaces zu erstellen (z. B. system, system_auth, system_schema, system_traces, sowie anwendungsspezifische Keyspaces wie dovecot_dictmap und dovecot_acl).
• Verwendet einen Zeitstempel als Snapshot-Tag (YYYYMMDD-HHMMSS).
• Wartet auf die Fertigstellung aller Snapshot-Jobs und prüft den Exit-Status.
• Löscht alte Snapshots gemäß Retention-Policy (nodetool clearsnapshot --older-than 10d).

Der Befehl nodetool snapshot erstellt Hardlinks der SSTable-Dateien im Verzeichnis snapshots/ innerhalb des Cassandra-Datenverzeichnisses. Dieses Datenverzeichnis (/bitnami/cassandra/data/) ist im Container gemountet und mit einem PersistentVolumeClaim (PVC) verbunden.

Das bedeutet: Die Snapshot-Dateien liegen direkt auf den PVCs, ohne zusätzlichen Kopiervorgang.

Betroffene PVCs:

• data-cassandra-0
• data-cassandra-1
• data-cassandra-2

nodetool snapshot ist ein Verwaltungswerkzeug für Apache Cassandra, das verwendet wird, um einen konsistenten Snapshot der Datenbank zu erstellen. Es ermöglicht die Sicherung der Datenbank ohne Betriebsunterbrechung, indem es eine Momentaufnahme des aktuellen Zustands der Daten speichert.

Nach der Snapshot-Erstellung sichert K8up diese PVCs mit Restic in das S3-Backup-Repository.

Backup-Monitoring und Validierung#

Siehe Kapitel Backup-Monitoring und Validierung

Object Storage (S3-kompatibel)#

Object Storage wird von mehreren Komponenten genutzt:

• Dovecot
• Nubus
• OpenProject
• Open-Xchange
• Nextcloud

3.3.1 Backup-Strategie, Frequenz, Retention#

Siehe Kapitel Backup-Strategie

3.3.2 Backup-Prozedur und entsprechender Automation#

Die Sicherung des Object Storage erfolgt in zwei Schutzschichten:

• S3-Bucket-Versionierung (Native S3-Funktion)

Jeder produktive Bucket ist mit Object Versioning aktiviert. Dadurch wird jede Änderung oder Löschung als neue Version gespeichert. Versionierung ist die erste Schutzschicht („Soft-Backup“ direkt im Bucket).

• Offsite-Backup (zweite Schutzschicht)

Zusätzlich werden alle produktiven Buckets regelmäßig auf einen zweiten Standort repliziert.

3.3.3 Backup-Monitoring und Validierung#

Siehe Kapitel Backup-Monitoring und Validierung