Backup- und Restore-Automatisierung#

Backup Automatisierung#

Die Backup-Automatisierung beginnt nicht erst beim eigentlichen Backup-Prozess, sondern schon bei der Bereitstellung der gesamten Umgebung.

• Phase 1: Infrastruktur-Bereitstellung

  Zunächst wird die Basis geschaffen:

  • Terraform übernimmt die Provisionierung der gesamten Umgebung in STACKIT.
    • Dazu gehören der Managed Kubernetes-Cluster, Netzwerke, Storage und alle notwendigen Ressourcen.
  • Dieses Setup bildet die Grundlage für alle weiteren Schritte und stellt sicher, dass die Infrastruktur jederzeit reproduzierbar ist.

• Phase 2: GitOps-Setup mit Argo CD

  Nach der Infrastruktur folgt die Automatisierung der Applikationsbereitstellung:

  • Terraform installiert Argo CD direkt im Cluster.
  • Argo CD wird mit dem Git-Repository verbunden, das alle deklarativen Definitionen enthält.
  • Damit ist sichergestellt, dass jede Änderung an der Plattform über Git gesteuert und versioniert erfolgt.

• Phase 3: Applikationsbereitstellung

  Sobald Argo CD aktiv ist, beginnt die eigentliche Bereitstellung der Kundenapplikationen:

  • Argo CD synchronisiert die Anwendungen aus dem Git-Repository.
  • Dazu gehören alle Komponenten wie Namespaces, Services und Datenbanken.
  • K8up – der zentrale Backup-Operator – wird ebenfalls installiert, inklusive seiner Custom Resource Definitions (CRDs).
  • Damit ist die Plattform bereit für automatisierte Backups.

• Phase 4: Backup-Automatisierung mit K8up

  Jetzt übernimmt K8up die Verantwortung, agiert jedoch ereignisbasiert:

  • Der K8up-Operator überwacht die definierten Schedule-Ressourcen und reagiert erst zum festgelegten Zeitpunkt (oder bei manueller Auslösung), indem er die entsprechenden Jobs startet:

    • Backup-Jobs (gemäß Cron-Schedule)

    • Prune-Jobs (Bereinigung basierend auf Retention-Policy)

    • Check-Jobs (Integritätsprüfung)

  • Alle Jobs werden deklarativ über CRDs gesteuert, sodass die Backup-Strategie zentral und transparent bleibt.

flowchart TB

%% === STYLE DEFINITIONS ===
classDef infra fill:#f0f9ff,stroke:#38bdf8,stroke-width:1px,rx:6,ry:6
classDef deploy fill:#fefce8,stroke:#eab308,stroke-width:1px,rx:6,ry:6
classDef app fill:#ecfdf5,stroke:#22c55e,stroke-width:1px,rx:6,ry:6
classDef k8up fill:#f1f5f9,stroke:#64748b,stroke-width:1px,rx:6,ry:6
classDef run fill:#fce7f3,stroke:#db2777,stroke-width:1px,rx:6,ry:6

%% === PHASE 1: INFRASTRUKTUR ===
subgraph INFRA["(1) Infrastruktur-Bereitstellung"]
    T["Terraform-Provisionierung<br>• Managed Kubernetes Cluster (STACKIT)<br>• Netzwerke, Storage, etc."]
end
class INFRA infra

%% === PHASE 2: GITOPS SETUP ===
subgraph GITOPS["(2) Argo CD Setup"]
    A["Argo CD Deployment<br>• Wird durch Terraform mitinstalliert<br>• Verbindet sich mit Git-Repo"]
end
class GITOPS deploy

%% === PHASE 3: APP-DEPLOYMENT ===
subgraph APP["(3) Applikationsbereitstellung"]
    direction TB
    ARGO["Argo CD synchronisiert Anwendungen<br>• App-Deployment<br>• Namespace-spezifische Komponenten<br>• Installation von K8up & CRDs"]
end
class APP app

%% === PHASE 4: K8UP AUTOMATION ===
subgraph K8UP["(4) K8up Scheduler & Jobs"]
    direction TB
    S["K8up Scheduler wird deployed"]
    B["Backup Jobs (täglich)"]
    P["Prune Jobs (Aufräumen alter Backups)"]
    C["Check Jobs (Integritätsprüfung)"]
end
class K8UP k8up

%% === FLOW ===
T --> A --> ARGO --> S
S --> B 
S --> P
S --> C

Restore Automatisierung#

Die Wiederherstellung (Restore) ist ein mehrstufiger Prozess, der sicherstellt, dass nach einem Ausfall oder einer Neuinstallation alle Datenbanken und persistenten Daten wieder in den gewünschten Zustand gebracht werden. Dieser Ablauf folgt einem strukturierten Workflow, der über definierte Rollen und technische Kontrollpunkte gesteuert wird. Die folgende Darstellung zeigt den vollständigen Restore-Prozess – von der Auslösung über die Pipeline, bis zur Wiederherstellung der Daten und finalen Validierung durch die Kundenseite:

Restore Ablauf#

Erläuterung des Restore-Prozesses

1. Problem & Restore-Entscheidung

   Kundenansprechpartner meldet ein Problem oder den Bedarf für einen Restore an den Restore Admin. Dies ist der Auslöser für den gesamten Prozess und stellt sicher, dass der Restore nur bei tatsächlichem Bedarf initiiert wird.

2. Restore-Vorbereitung

• Der Restore Admin greift auf bestehende Cluster-Parameter zu, wie z.b. cluster_name. Diese Parameter sind entscheidend für die korrekte Konfiguration des Restores.
• Er setzt oder aktualisiert die Pipeline-Parameter, insbesondere RESTORE_FROM_BACKUP="true", um den Restore-Modus zu aktivieren. Dies verhindert unbeabsichtigte oder unbefugte Restore-Aktionen.
• Eine finale Abstimmung mit dem Kundenansprechpartner erfolgt, um die Freigabe für den Restore zu erhalten.

3. Restore-Anstoß

• Der Restore Admin übermittelt die freigegebene Restore-Anforderung, inklusive der finalen Pipeline-Parameter, an den Cluster Initialisierer.
• Der Cluster Initialisierer startet die Restore-Pipeline mit den vorbereiteten Parametern, wodurch der technische Restore-Prozess eingeleitet wird.

4. Technische Restore-Ausführung

• Die CI/CD Pipeline rollt die Infrastruktur und Applikation neu aus und triggert die k8up Restore-Jobs. Der Restore Job sorgt für die Wiederherstellung der Daten.
• K8up exportiert Restore-Metriken, die von Monitoring-Tools wie Prometheus, Alertmanager und Grafana überwacht werden. Diese Metriken sind entscheidend für die Überwachung des Restore-Status und die Erkennung von Fehlern.

5. Technische Validierung

• Der Restore Admin prüft den Restore-Status, um sicherzustellen, dass die Restore-Jobs erfolgreich abgeschlossen sind und keine Fehler auftreten.

6. Fachliche Validierung

• Der Restore Admin meldet den Abschluss des technischen Restores an den Kundenansprechpartner und bittet um eine fachliche Prüfung.

• Der Kundenansprechpartner testet die Applikation und Daten, um sicherzustellen, dass alle Funktionen und Workflows korrekt wiederhergestellt sind.

  • Ergebnis: Restore fachlich OK

    Bei erfolgreicher fachlicher Prüfung bestätigt der Kundenansprechpartner den Restore. Der Restore Admin informiert den Cluster Initialisierer über den erfolgreichen Abschluss für Dokumentation und Reporting.

  • Ergebnis: Restore NICHT OK

    Bei Problemen meldet der Kundenansprechpartner diese an den Restore Admin, der die Ursache analysiert und ggf. einen weiteren Restore-Versuch abstimmt. Der Prozess wird erneut durchlaufen, bis der Restore fachlich und technisch erfolgreich abgeschlossen ist.

sequenceDiagram
    autonumber

    participant C as Kundenansprechpartner
    participant R as Restore Admin
    participant I as Cluster Initialisierer
    participant CI as CI/CD Pipeline
    participant K as Cluster & k8up
    participant M as Monitoring (Prometheus/Alertmanager/Grafana)

    %% 1. Problem & Restore-Entscheidung
    C->>R: Meldet Problem / Bedarf für Restore
    %% 2. Restore-Vorbereitung
    R->>CI: Liest vorhandene Cluster-Parameter<br/>(cluster_name, namespace, backup_target, ...)
    R->>CI: Setzt/aktualisiert Parameter<br/>(RESTORE_FROM_BACKUP="true")
    R->>C: Finale Abstimmung ab<br/>(Freigabe vom Kunden)

    %% 3. Restore-Anstoß
    R->>I: Übermittelt freigegebene Restore-Anforderung<br/>inkl. finaler Pipeline-Parameter
    I->>CI: Startet Restore-Pipeline<br/>mit den vorbereiteten Parametern

    %% 4. Technische Restore-Ausführung
    CI->>K: Rollt Infrastruktur/Applikation neu aus<br/>und triggert k8up Restore-Jobs
    K-->>M: Exportiert Restore-Metriken<br/>(k8up_jobs_* mit jobType="restore")
    M-->>R: Sendet Alerts bei Restore-Fehlern<br/>oder zeigt Status im Dashboard

    %% 5. Technische Validierung
    R->>M: Prüft Restore-Status<br/>(Restore-Jobs erfolgreich, keine Errors)

    %% 6. Fachliche Validierung
    R->>C: Meldet Abschluss des technischen Restores<br/>und bittet um fachliche Prüfung
    C->>K: Testet Applikation & Daten<br/>(UI, Workflows)
    
    alt Restore fachlich OK
        C->>R: Bestätigung „Restore erfolgreich“
        R->>I: Informiert über erfolgreichen Abschluss<br/>(für Dokumentation/Reporting)
    else Restore NICHT OK
        C->>R: Meldet Probleme (fehlende Daten/Fehler)
        R->>R: Analysiert Ursache (Logs, Metriken, Jobs)
        R->>C: Stimmt ggf. weiteren Restore-Versuch ab
        R->>I: Fordert erneuten Restore-Lauf an
        I->>CI: Startet Restore-Pipeline erneut
        CI->>K: Führt erneuten Restore aus
        K-->>M: Aktualisiert Restore-Metriken
        M-->>R: Meldet Status / Fehler
        R->>C: Meldet neuen Stand, erneute fachliche Prüfung 
    end

Nach der Beschreibung des gesamten Restore-Prozesses ist es wichtig, einen genaueren Blick auf die technische Umsetzung innerhalb der CI/CD Pipeline zu werfen. Im Folgenden werden die technischen Details der Restore-Pipeline genauer angesehen.

Phase 1: Voraussetzungen#

• Voraussetzung: Es wird vorausgesetzt, dass in Stage 1 durch Terraform und ArgoCD sowohl die Infrastruktur (Cluster, Storage, Netzwerk) als auch die Applikationen (Datenbanken, Services) bereits vollständig bereitgestellt und lauffähig sind.

Die folgenden Stages kümmern sich ausschließlich um den Restore-Prozess aus Backups.

• Ziel: Nach erfolgreichem Durchlauf sollen alle Datenbanken (PostgreSQL, MariaDB, Cassandra, LDAP) sowie alle PVCs auf den neuesten Stand gebracht werden.
• Hinweis: Wenn individuelle Versionen oder Snapshots benötigt werden, muss der Restore manuell erfolgen.

Phase 2: Vorkontrollen#

Diese erste technische Prüfung stellt sicher, dass alle notwendigen Umgebungsvariablen und Kubernetes-CRDs vorhanden sind. Fehlt etwas, bricht die Pipeline sofort ab, um inkonsistente Zustände zu vermeiden.

pre-checks:
  stage: pre-checks
  image: <INTERNE-REGISTRY>/kubectl:latest
  script:
    - set -euo pipefail
    - echo "Checking prerequisites for restore process..."

    # Check whether K8up CRDs are installed
    - kubectl get crd restores.k8up.io || (echo "K8up CRDs fehlen. Bitte K8up installieren." && exit 1)

    # Check whether namespace is set
    - if [ -z "${NAMESPACE}" ]; then echo "NAMESPACE ist nicht gesetzt." && exit 1; fi

    # Check whether backup repo password is available
    - if [ -z "${BACKUP_REPO_PASSWORD}" ]; then echo "BACKUP_REPO_PASSWORD fehlt." && exit 1; fi

    # Check whether S3 access data is available
    - if [ -z "${S3_ACCESS_KEY_ID}" ]; then echo "S3_ACCESS_KEY_ID fehlt." && exit 1; fi
    - if [ -z "${S3_SECRET_ACCESS_KEY}" ]; then echo "S3_SECRET_ACCESS_KEY fehlt." && exit 1; fi

    # Check whether the restore flag is set
    - if [ "${RESTORE_FROM_BACKUP}" != "true" ]; then echo "RESTORE_FROM_BACKUP ist nicht true. Restore wird übersprungen."; fi

    # Check whether database variables exist
    - if [ -z "${PG_CONTAINER}" ]; then echo "PG_CONTAINER fehlt." && exit 1; fi
    - if [ -z "${PG_USER}" ]; then echo "PG_USER fehlt." && exit 1; fi
    - if [ -z "${PG_HOST}" ]; then echo "PG_HOST fehlt." && exit 1; fi
    - if [ -z "${PG_PORT}" ]; then echo "PG_PORT fehlt." && exit 1; fi

    - if [ -z "${MDB_CONTAINER}" ]; then echo "MDB_CONTAINER fehlt." && exit 1; fi
    - if [ -z "${MDB_USER}" ]; then echo "MDB_USER fehlt." && exit 1; fi
    - if [ -z "${MDB_HOST}" ]; then echo "MDB_HOST fehlt." && exit 1; fi
    - if [ -z "${MDB_PASS}" ]; then echo "MDB_PASS fehlt." && exit 1; fi

    - if [ -z "${LDAP_CONTAINER}" ]; then echo "LDAP_CONTAINER fehlt." && exit 1; fi

    echo "Alle Pre-Checks erfolgreich abgeschlossen."

Phase 3: Restore PVCs#

In dieser Phase werden alle Persistent Volume Claims (PVCs) aus den neuesten Snapshots wiederhergestellt. Dies ist die Grundlage für alle zustandsbehafteten Komponenten.

restore-pvcs:
  stage: restore-pvcs
  image: <INTERNE-REGISTRY>/kubectl:latest
  rules:
    - if: $RESTORE_FROM_BACKUP == "true"
  script:
    - echo "Starting PVC restore..."
    - echo "Generating restore manifests for latest snapshots..."
    
    # Create restore manifests (without snapshot ID = always latest)
    - kubectl apply -f restore-manifests/pvc-restores/
    
    - echo "Waiting for k8up restore jobs to complete..."
    #Fehler bei timeout
    - kubectl wait --for=condition=complete restore --all -n ${NAMESPACE} --timeout=1800s || (echo "Restore jobs did not complete in time" && exit 1)

    
    - echo "All PVCs restored successfully"

• Hinweis: Für den PVC-Restore muss für jedes PVC ein eigenes Restore-YAML definiert werden. Das Folgende dient als Beispiel. Alle Restore-Dateien werden im Verzeichnis restore-manifests/pvc-restores/ abgelegt und in der Pipeline angewendet.

apiVersion: k8up.io/v1
kind: Restore
metadata:
  name: restore-clamav
  namespace: default
spec:
  restoreMethod:
    folder:
      claimName: clamav-database-clamav-simple-0
  backend:
    repoPasswordSecretRef:
      name: backup-repo
      key: password
    s3:
      endpoint: https://object.storage.eu01.onstackit.cloud
      bucket: <test-backup>
      accessKeyIDSecretRef:
        name: backup-credentials
        key: username
      secretAccessKeySecretRef:
        name: backup-credentials
        key: password

Phase 4: Restore Databases#

Nachdem die PVCs wiederhergestellt sind, folgt die Wiederherstellung der Datenbanken. Hier werden die zuvor gesicherten Dumps oder LDIF-Dateien eingespielt.

restore-databases:
  stage: restore-databases
  image: ghcr.io/k8up-io/k8up:v2.9.0
  rules:
    - if: $RESTORE_FROM_BACKUP == "true"
  before_script:
    - export RESTIC_PASSWORD="${BACKUP_REPO_PASSWORD}"
    - export AWS_ACCESS_KEY_ID="${S3_ACCESS_KEY_ID}"
    - export AWS_SECRET_ACCESS_KEY="${S3_SECRET_ACCESS_KEY}"
  script:
    - echo "Starting database restore..."
    - bash scripts/restore-databases.sh
    - echo "Database restore complete"
  artifacts:
    when: on_failure
    paths:
      - /tmp/restore/*.log
    expire_in: 1 week

Die nachstehenden Code-Auschnitte aus restore-databases.sh zeigen exemplarisch die Vorgehensweise beim Restore unterschiedlicher Datenbanken:

Restic wird als Tool verwendet, um Daten aus einem S3-kompatiblen Object Storage (STACKIT) wiederherzustellen. Der Prozess ist modular aufgebaut und folgt klaren Schritten:

• Verbindung zum Backup-Repository

  Zuerst werden die notwendigen Umgebungsvariablen gesetzt, um Restic mit dem S3-Backup-Repository zu verbinden, wie beispielhaft dargestellt:

  export RESTIC_REPOSITORY="s3:https://object.storage.eu01.onstackit.cloud/<kunde>-opndsk-de-backup-manual"
  export RESTIC_PASSWORD="<RESTIC PASSWORD>"
  export AWS_ACCESS_KEY_ID="<STACKIT ACCESS KEY>"
  export AWS_SECRET_ACCESS_KEY="<STACKIT SECRET KEY>"
  

• Snapshot-Ermittlung

  Für jede Komponente wird der neueste Snapshot identifiziert:

  get_latest_snapshot() {
      restic snapshots --json | jq -r ".[] | select(.paths[] | contains(\"$1\")) | .short_id" | tail -n 1
  }
  

  Snapshots werden nach Pfad gefiltert (z. B. nextcloud-pre-backup-postgres). Es wird immer der letzte Snapshot verwendet, um die aktuellsten Daten wiederherzustellen.

• PostgreSQL

  Besonderheit: PostgreSQL ist managed, d. h. es gibt keinen direkten Zugriff auf den Datenbank-Container. Deshalb wird ein temporärer Pod mit dem offiziellen PostgreSQL-Client erstellt, um die Dumps einzuspielen. PostgreSQL wird von mehreren Komponenten benutzt. Jede dieser Komponenten hat ihre eigene PostgreSQL-Datenbank und eigene Zugangsdaten. Deshalb müssen die folgenden Schritte für jede Datenbank separat z.b. als eine Funktion aufgerufen werden.

  Die Schritte sind:

  • Snapshot ermitteln:

    SNAPSHOT_ID=$(restic snapshots --json | jq -r ".[] | select(.paths[] | contains(\"nextcloud-pre-backup-postgres\")) | .short_id" | tail -n 1)
    

    → Findet den neuesten Snapshot für die jeweilige App.

  • Temporären Pod starten:

    kubectl run postgres-restore-client --image=postgres:15 --restart=Never -n ${NAMESPACE} --command -- sleep 3600kubectl wait --for=condition=ready pod/postgres-restore-client -n ${NAMESPACE} --timeout=120s
    

    → Der temporäre Pod dient als isolierte Umgebung für den Restore.

  • Dump einspielen:

    cat "$SQL_FILE" | kubectl exec --stdin ${TEMP_POD_NAME} -- bash -c \"PGPASSWORD='${!password_var}' psql -U ${!user_var} -h ${!host_var} -p 5432 -d ${database}"
    

  • Temporären Pod löschen:

    kubectl delete pod ${TEMP_POD_NAME} -n ${NAMESPACE} --ignore-not-found=true
    

• LDAP (StatefulSet im Cluster)

  LDAP ist zustandsbehaftet und läuft als StatefulSet. Hier wird ein logischer Restore durchgeführt (LDIF-Import), nicht ein PVC-Restore. Die Schritte sind:

  • LDAP stoppen:

    kubectl scale statefulset ums-ldap-server-primary --replicas=0
    

    → Verhindert Inkonsistenzen während des Imports.

  • Snapshot wiederherstellen:

    restic restore ${LDAP_SNAPSHOT} --target ${RESTORE_DIR}/ldap
    

    → LDIF-Datei wird ins Restore-Verzeichnis gelegt.

  • LDIF importieren:

    cat "${LDAP_FILE}" | kubectl exec --stdin ${LDAP_POD} -- slapadd
    

    → Logischer Import in die LDAP-Datenbank.

  • Stoppen des StatefulSets verhindert Schreibkonflikte.

  • slapadd sorgt für konsistente Wiederherstellung unabhängig von der Dateistruktur.

• MariaDB (StatefulSet im Cluster)

  MariaDB wird ausschließlich von Open-Xchange genutzt und läuft als StatefulSet. Der Restore erfolgt direkt im Pod. Die Schritte sind:

  • Snapshot wiederherstellen
    restic restore ${MARIADB_SNAPSHOT} --target ${RESTORE_DIR}/mariadb
    

  • Löschen einer bestehenden MariaDB-Datenbank
    kubectl -n ${NAMESPACE} exec ${MARIADB_POD} -- mariadb -u ${MARIADB_USER} -p${MARIADB_PASSWORD} -e "DROP DATABASE IF EXISTS opendesk; CREATE DATABASE opendesk;"
    

  • Dump einspielen
    cat "${MARIADB_FILE}" | kubectl exec --stdin ${MARIADB_POD} -- mariadb -u ${MARIADB_USER} -p${MARIADB_PASSWORD}
    

  → Vollständiger SQL-Dump wird importiert.

  • PVC bleibt bestehen, aber die Datenbank wird logisch neu aufgebaut.
  • Vor dem Import wird die Datenbank neu erstellt, um Konflikte zu vermeiden.

Phase 5: Restart applications#

Zum Abschluss müssen die Anwendungen neu gestartet werden, damit sie die wiederhergestellten Daten laden und in einen konsistenten Betriebszustand übergehen.

restart-applications:
  stage: post-restore
  image: <INTERNE-REGISTRY>/kubectl:latest
  rules:
    - if: $RESTORE_FROM_BACKUP == "true"
  script:
    - echo "Restarting applications to load restored data..."
    
    # Restart in order: databases first, then apps
    - kubectl rollout restart statefulset -l tier=database -n ${NAMESPACE} || true
    - kubectl rollout status statefulset -l tier=database -n ${NAMESPACE} --timeout=300s || true
    
    - kubectl rollout restart deployment --all -n ${NAMESPACE}
    - kubectl rollout restart statefulset --all -n ${NAMESPACE}
    
    - echo "Waiting for deployments to be ready..."
    - kubectl rollout status deployment --all -n ${NAMESPACE} --timeout=600s
    
    - echo "All applications restarted successfully"

Automatisierte Restore-Tests#

Um die Wiederherstellbarkeit der Backups regelmäßig zu validieren, werden automatisierte Restore-Tests in einer isolierten Testumgebung durchgeführt. Diese Tests stellen sicher, dass im Ernstfall eine vollständige Wiederherstellung möglich ist und identifizieren potenzielle Probleme frühzeitig.

Zielsetzung#

Die automatisierten Restore-Tests verfolgen mehrere Ziele: die Validierung der technischen Wiederherstellbarkeit aller gesicherten Komponenten, die Überprüfung der Integrität und Konsistenz der wiederhergestellten Daten, die Messung der tatsächlichen Restore-Dauer zur Verifizierung des RTO sowie die frühzeitige Erkennung von Problemen im Backup- oder Restore-Prozess.

Testumgebung#

Für die Durchführung der Restore-Tests wird ein dediziertes Kubernetes-Cluster mit dem Namen restore-test-cluster bereitgestellt. Dieses Cluster ist vollständig von den Produktiv- und Entwicklungsumgebungen isoliert und dient ausschließlich der Validierung von Restore-Prozessen. Die Infrastruktur des Test-Clusters wird identisch zur Produktivumgebung über Terraform provisioniert, um eine realistische Testbasis zu gewährleisten. Als Datenquelle für die Restore-Tests dienen die Backups des Referenz-Clusters schulung-opndsk-de, dessen Snapshots regelmäßig für die Validierung herangezogen werden.

Testszenarien#

Um die Wiederherstellbarkeit umfassend zu validieren, werden verschiedene Testszenarien definiert, die unterschiedliche Ausfallsituationen abbilden. Diese Szenarien decken sowohl partielle als auch vollständige Wiederherstellungen ab und berücksichtigen die spezifische Architektur der openDesk-Plattform.

Übersicht der Testszenarien#

Detailbeschreibung der Testszenarien#

Testszenario 1: Vollständiger Cluster-Restore (Disaster Recovery)

Dieses Szenario simuliert den vollständigen Verlust eines Kubernetes-Clusters, beispielsweise durch eine schwerwiegende Fehlkonfiguration. Der Test beginnt mit der Bereinigung des restore-test-cluster und der Entfernung aller bestehenden Workloads. Anschließend erfolgt die Neubereitstellung der Basis-Infrastruktur über Terraform sowie das Bootstrapping des Clusters über ArgoCD. Danach werden alle PVCs aus den neuesten Restic-Snapshots wiederhergestellt und sämtliche Datenbank-Dumps für PostgreSQL, MariaDB, LDAP und Cassandra eingespielt. Nach dem Neustart aller Applikationen werden automatisierte Health-Checks durchgeführt und der Restore Admin führt eine manuelle Stichprobenprüfung durch. Das Szenario gilt als erfolgreich, wenn alle Restore-Jobs abgeschlossen sind, alle Pods im Status Running sind, die Health-Checks erfolgreich sind und die Restore-Dauer innerhalb des definierten RTO von 4 bis 8 Stunden liegt.

Testszenario 2: Einzelne Applikations-Wiederherstellung

Dieses Szenario simuliert den Ausfall einer einzelnen Applikation durch korrupte Daten oder eine fehlerhafte Deployment-Änderung. Zunächst wird eine Zielapplikation ausgewählt (z.b. rotierend zwischen Element, Open-Xchange und XWiki). Der Datenverlust wird durch Löschen der applikationsspezifischen PVCs simuliert. Anschließend erfolgt die Wiederherstellung der betroffenen PVCs aus dem neuesten Snapshot sowie das Einspielen des zugehörigen Datenbank-Dumps. Nach dem Neustart der Applikation wird deren Funktionalität validiert und überprüft, dass andere Applikationen nicht beeinträchtigt wurden. Das Szenario gilt als erfolgreich, wenn die Zielapplikation vollständig wiederhergestellt und funktionsfähig ist, andere Applikationen unbeeinträchtigt bleiben und die Daten konsistent sind.

Testszenario 3: PostgreSQL-Restore (Managed Service)

Da PostgreSQL als STACKIT Managed Service außerhalb des Kubernetes-Clusters betrieben wird, erfordert dessen Wiederherstellung einen spezifischen Prozess. Nach der Auswahl einer PostgreSQL-Datenbank (z.B. Nextcloud oder Keycloak) wird der neueste Snapshot identifiziert und der Dump aus dem Restic-Repository extrahiert. Ein temporärer PostgreSQL-Client-Pod wird im Cluster erstellt, über den die Verbindung zur Managed PostgreSQL-Instanz hergestellt und der Dump eingespielt wird. Nach dem Löschen des temporären Pods und dem Neustart der abhängigen Applikation wird die Datenbankverbindung und Datenintegrität validiert. Das Szenario gilt als erfolgreich, wenn der Dump fehlerfrei eingespielt wird und die Applikation erfolgreich auf die Datenbank zugreifen kann.

Testszenario 4: MariaDB-Restore (Open-Xchange)

MariaDB wird ausschließlich von Open-Xchange genutzt und läuft als StatefulSet im Cluster. Der Test beginnt mit dem Stoppen der abhängigen Open-Xchange-Komponenten. Nach der Identifikation des neuesten MariaDB-Snapshots wird der Dump extrahiert, die Datenbank gelöscht und neu erstellt sowie der Dump eingespielt. Nach dem Neustart des MariaDB-StatefulSets und der Open-Xchange-Komponenten wird die E-Mail- und Groupware-Funktionalität validiert. Das Szenario gilt als erfolgreich, wenn Open-Xchange erfolgreich startet und E-Mail-Zugriff sowie Groupware-Funktionen vollständig verfügbar sind.

Testszenario 5: LDAP-Verzeichnis-Restore

Das LDAP-Verzeichnis enthält zentrale Identitäts- und Authentifizierungsdaten. Der Test beginnt mit dem Skalieren des LDAP-StatefulSets auf 0 Replicas. Nach der Identifikation des neuesten Snapshots wird die LDIF-Datei extrahiert, das bestehende Datenverzeichnis bereinigt und die LDIF-Datei mittels slapadd importiert. Nach dem Hochskalieren des StatefulSets wird die LDAP-Verbindung validiert und die Anmeldung mit verschiedenen Benutzerkonten getestet. Das Szenario gilt als erfolgreich, wenn der LDIF-Import fehlerfrei abgeschlossen wird, das StatefulSet erfolgreich startet und Benutzer sich authentifizieren können.

Testszenario 6: Cassandra-Restore (Dovecot-Metadaten)

Cassandra speichert Metadaten für den Dovecot-Mail-Stack und erfordert aufgrund seiner verteilten Architektur besondere Aufmerksamkeit. Der Test beginnt mit dem Stoppen des Dovecot-Dienstes. Nach der Identifikation der neuesten Snapshots für alle drei Nodes werden die Snapshot-Verzeichnisse auf allen Cassandra-PVCs wiederhergestellt. Nach dem Neustart des StatefulSets wird auf die vollständige Cluster-Synchronisation gewartet und die Keyspace-Konsistenz mittels nodetool status überprüft. Nach dem Neustart des Dovecot-Dienstes wird der Mail-Zugriff validiert. Das Szenario gilt als erfolgreich, wenn alle drei Nodes im Status UN (Up/Normal) sind und der Mail-Zugriff korrekt funktioniert.

Testszenario 7: Point-in-Time-Restore (älterer Snapshot)

Dieses Szenario testet die Wiederherstellung eines älteren Snapshots, um beispielsweise versehentlich gelöschte Daten wiederherzustellen. Es wird ein Snapshot ausgewählt, der mindestens 7 Tage alt ist. Nach der Dokumentation der Snapshot-ID erfolgt die Wiederherstellung der PVCs und das Einspielen der Datenbank-Dumps aus dem historischen Snapshot. Nach dem Neustart der Applikationen wird validiert, dass die Daten dem erwarteten Stand entsprechen und keine kritischen Schema-Inkompatibilitäten auftreten. Das Szenario gilt als erfolgreich, wenn der historische Snapshot erfolgreich wiederhergestellt wird und die Applikation funktionsfähig ist.

Testszenario 8: Secrets-Restore

Kubernetes-Secrets enthalten kritische Zugangsdaten für Datenbanken, S3-Storage und externe Services. Der Test simuliert einen Secrets-Verlust durch Löschen ausgewählter Secrets im Namespace. Nach der Identifikation des neuesten Secrets-Backups wird die JSON-Datei aus dem Restic-Repository extrahiert und die Secrets mittels kubectl apply wiederhergestellt. Nach dem Neustart der betroffenen Applikationen wird validiert, dass diese erfolgreich auf ihre Backend-Services zugreifen können. Das Szenario gilt als erfolgreich, wenn alle Secrets wiederhergestellt werden und keine Authentifizierungsfehler auftreten.

Testszenario 9: Partieller PVC-Restore

Dieses Szenario testet die gezielte Wiederherstellung eines einzelnen Persistent Volumes, beispielsweise nach Dateisystem-Korruption. Nach der Auswahl eines PVCs (z.B. xwiki-data-xwiki-0) wird die zugehörige Applikation gestoppt. Ein K8up Restore-Manifest wird für das spezifische PVC erstellt und angewendet. Nach dem Neustart der Applikation wird validiert, dass die Daten wiederhergestellt sind und andere PVCs sowie Applikationen nicht beeinträchtigt wurden. Das Szenario gilt als erfolgreich, wenn das PVC vollständig wiederhergestellt wird und andere Komponenten unbeeinträchtigt bleiben.

Testszenario 10: Restore aus Offsite-Backup

Dieses Szenario simuliert den Extremfall, dass das primäre STACKIT-Backup-Repository nicht verfügbar ist. Die Restic-Umgebungsvariablen werden für den Offsite-S3-Storage (Regio Cloud oder Hetzner) konfiguriert und die Verbindung validiert. Nach der Auflistung der verfügbaren Snapshots werden ausgewählte PVCs und Datenbank-Dumps aus dem Offsite-Backup wiederhergestellt. Die Restore-Dauer wird unter Berücksichtigung der Netzwerk-Latenz gemessen. Das Szenario gilt als erfolgreich, wenn die Verbindung zum Offsite-Repository hergestellt werden kann, der Restore erfolgreich ist und die Daten identisch mit denen des Primär-Repositories sind.

Erfolgskriterien je Testszenario#

Automatisierungsgrad der Testszenarien#

Nicht alle Testszenarien lassen sich vollständig automatisieren. Die folgende Übersicht zeigt den Automatisierungsgrad jedes Szenarios sowie die Begründung für manuelle Eingriffe, wo diese erforderlich sind.

Übersicht Automatisierungsgrad#

Erläuterung der Automatisierungsgrade#

Vollautomatisiert bedeutet, dass der gesamte Testprozess inklusive Restore-Durchführung und Validierung ohne manuellen Eingriff über die CI/CD-Pipeline ablaufen kann. Dies ist möglich, wenn sowohl die Restore-Schritte als auch die Erfolgskriterien technisch prüfbar sind.

Teilautomatisiert bedeutet, dass die technischen Restore-Schritte automatisiert ablaufen, die fachliche Validierung jedoch manuelle Prüfung durch den Restore Admin erfordert. Dies betrifft insbesondere Szenarien, bei denen die Datenkonsistenz oder Funktionalität nur durch Stichproben oder UI-Tests verifiziert werden kann.

Manuell bedeutet, dass wesentliche Schritte des Tests manuelle Eingriffe erfordern, beispielsweise die Auswahl eines spezifischen historischen Snapshots oder die Konfiguration alternativer Backup-Repositories.

Detaillierte Automatisierungsanalyse#

Testszenario 1: Vollständiger Cluster-Restore – Teilautomatisiert

Die technischen Restore-Schritte (Terraform-Provisionierung, ArgoCD-Bootstrapping, PVC-Restore, Datenbank-Imports, Applikations-Neustart) können vollständig über die CI/CD-Pipeline orchestriert werden. Die automatisierte Validierung umfasst die Prüfung der K8up Restore-Job-Status, Pod-Zustände und HTTP-Health-Checks aller Endpoints. Die fachliche Validierung erfordert jedoch manuelle Stichproben durch den Restore Admin, da die inhaltliche Korrektheit der wiederhergestellten Daten (z.B. Benutzerinhalte in Nextcloud, E-Mails in Open-Xchange) nicht vollständig automatisiert geprüft werden kann.

Testszenario 2: Einzelne Applikation – Teilautomatisiert

Der Restore-Prozess für eine einzelne Applikation kann vollständig automatisiert werden, einschließlich der Simulation des Datenverlusts (PVC-Löschung), der Wiederherstellung und des Applikations-Neustarts. Die technische Validierung (Pod-Status, Health-Checks, Datenbankverbindung) ist automatisierbar. Die fachliche Validierung erfordert jedoch manuelle Prüfung, um sicherzustellen, dass die applikationsspezifischen Daten (z.B. Projekte in OpenProject, Wiki-Seiten in XWiki) korrekt wiederhergestellt wurden.

Testszenario 3: PostgreSQL – Vollautomatisiert

Der PostgreSQL-Restore kann vollständig automatisiert werden. Die Pipeline erstellt den temporären Client-Pod, spielt den Dump ein und löscht den Pod anschließend. Die Validierung erfolgt durch automatisierte SQL-Abfragen, die die Existenz erwarteter Tabellen und Datensätze prüfen. Da die Datenintegrität durch Schema-Validierung und Zeilenanzahl-Prüfung technisch verifizierbar ist, entfällt die Notwendigkeit manueller Prüfung.

Testszenario 4: MariaDB – Teilautomatisiert

Die technischen Restore-Schritte sind automatisierbar. Die Validierung der Datenbankverbindung und grundlegender SQL-Abfragen kann ebenfalls automatisiert werden. Die fachliche Validierung der E-Mail- und Groupware-Funktionalität erfordert jedoch manuelle Prüfung, da die korrekte Darstellung von E-Mails, Kalendern und Kontakten nur durch UI-Tests oder manuelle Stichproben verifiziert werden kann.

Testszenario 5: LDAP – Vollautomatisiert

Der LDAP-Restore kann vollständig automatisiert werden. Die Pipeline skaliert das StatefulSet, importiert die LDIF-Datei und skaliert das StatefulSet wieder hoch. Die Validierung erfolgt durch automatisierte LDAP-Abfragen (ldapsearch), die die Existenz erwarteter Benutzer und Gruppen prüfen. Ein automatisierter Authentifizierungstest mit Test-Credentials verifiziert die Funktionsfähigkeit.

Testszenario 6: Cassandra – Teilautomatisiert

Die technischen Restore-Schritte sind automatisierbar, einschließlich der PVC-Wiederherstellung auf allen drei Nodes und des StatefulSet-Neustarts. Die Cluster-Konsistenz kann durch nodetool status automatisiert geprüft werden. Die fachliche Validierung der Mail-Metadaten (ACLs, Dovecot-Metadaten) erfordert jedoch manuelle Prüfung, da die korrekte Funktionalität nur durch tatsächlichen Mail-Zugriff verifiziert werden kann.

Testszenario 7: Point-in-Time – Manuell

Dieses Szenario erfordert manuelle Eingriffe, da die Auswahl des historischen Snapshots eine bewusste Entscheidung erfordert. Der Restore Admin muss den gewünschten Wiederherstellungszeitpunkt bestimmen und den entsprechenden Snapshot identifizieren. Die technischen Restore-Schritte können anschließend über die Pipeline ausgeführt werden, jedoch erfordert die Validierung manuelle Prüfung, ob die Daten dem erwarteten historischen Stand entsprechen.

Testszenario 8: Secrets – Vollautomatisiert

Der Secrets-Restore kann vollständig automatisiert werden. Die Pipeline extrahiert die Secrets-JSON-Datei aus dem Restic-Repository und wendet sie mit kubectl apply an. Die Validierung erfolgt durch automatisierte Prüfung, ob alle Applikationen nach dem Neustart erfolgreich auf ihre Backend-Services zugreifen können (Datenbankverbindungen, S3-Zugriff).

Testszenario 9: Partieller PVC – Vollautomatisiert

Der partielle PVC-Restore kann vollständig automatisiert werden. Die Pipeline erstellt das K8up Restore-Manifest für das spezifische PVC, wartet auf den Abschluss und startet die zugehörige Applikation neu. Die Validierung erfolgt durch Prüfung des Pod-Status und eines Health-Checks. Die Bestätigung, dass andere Komponenten unbeeinträchtigt sind, erfolgt durch automatisierte Prüfung aller anderen Pod-Zustände.

Testszenario 10: Offsite-Backup – Manuell

Dieses Szenario erfordert manuelle Eingriffe, da die Konfiguration des Offsite-Repositories (Änderung der Restic-Umgebungsvariablen auf den Offsite-S3-Endpoint) eine bewusste Abweichung vom Standardprozess darstellt. Die technischen Restore-Schritte können anschließend über die Pipeline ausgeführt werden. Die Validierung erfordert manuelle Prüfung, um sicherzustellen, dass die Daten aus dem Offsite-Backup mit dem Primär-Repository übereinstimmen.

Ablauf eines Testzyklus#

Der konkrete Ablauf eines Restore-Test-Zyklus gliedert sich in mehrere aufeinander aufbauende Phasen:

1. Vorbereitung der Testumgebung

Zu Beginn wird das restore-test-cluster in einen definierten Ausgangszustand versetzt. Falls aus vorherigen Testläufen noch Ressourcen vorhanden sind, werden diese bereinigt. Anschließend werden die Basis-Komponenten über ArgoCD synchronisiert, sodass alle notwendigen Namespaces, Secrets und Infrastruktur-Komponenten bereitstehen. Die K8up Custom Resource Definitions sowie die Verbindung zum Backup-Repository des Quell-Clusters schulung-opndsk-de werden konfiguriert.

2. Snapshot-Identifikation

Im nächsten Schritt werden die für die geplanten Testszenarien benötigten Snapshots aus dem Backup-Repository ermittelt. Die Snapshot-IDs und deren Erstellungszeitpunkte werden protokolliert, um die Nachvollziehbarkeit des Tests zu gewährleisten.

3. Durchführung der Testszenarien

Die für das aktuelle Quartal vorgesehenen Testszenarien werden nacheinander durchgeführt. Bei vollautomatisierten Szenarien läuft der gesamte Prozess über die CI/CD-Pipeline ab. Bei teilautomatisierten und manuellen Szenarien werden die automatisierbaren Schritte über die Pipeline ausgeführt und die manuellen Schritte vom Restore Admin durchgeführt. Zwischen den einzelnen Szenarien wird die Testumgebung bei Bedarf zurückgesetzt.

4. Automatisierte Validierung

Nach jedem Szenario führt die Pipeline automatisierte Prüfungen durch. Diese umfassen die Verifizierung der K8up Restore-Job-Status, die Überprüfung der Pod-Zustände, grundlegende Health-Checks der Applikations-Endpoints sowie die Validierung der Datenbankverbindungen.

5. Manuelle Validierung durch den Restore Admin

Bei teilautomatisierten und manuellen Szenarien führt der Restore Admin ergänzende manuelle Validierungen durch. Er prüft stichprobenartig die Konsistenz der wiederhergestellten Daten, verifiziert die Funktionsfähigkeit kritischer Applikations-Workflows und dokumentiert eventuelle Auffälligkeiten oder Abweichungen.

6. Reporting und Dokumentation

Nach Abschluss aller Testszenarien wird ein Testbericht erstellt, der folgende Informationen enthält: Datum und Uhrzeit des Testlaufs, durchgeführte Testszenarien mit Ergebnissen, verwendete Snapshot-IDs und deren Erstellungszeitpunkte, Dauer der einzelnen Restore-Phasen, Ergebnisse der automatisierten und manuellen Validierung sowie identifizierte Probleme oder Verbesserungspotenziale. Der Bericht wird revisionssicher archiviert und dient als Nachweis für die regelmäßige Wirksamkeitsprüfung gemäß Art. 32 DSGVO.

7. Bereinigung der Testumgebung

Nach erfolgreicher Dokumentation wird das restore-test-cluster zurückgesetzt, um Ressourcen freizugeben und eine saubere Basis für den nächsten Testlauf zu schaffen.