openDesk Backupkonzept

Einleitung

Die vorliegende Konzeption beschreibt das Backup- und Restore-Verfahren für die openDesk-Plattform, die auf Kubernetes basiert. openDesk wird als Software-as-a-Service (SaaS) bereitgestellt und bietet Organisationen eine moderne, cloudbasierte Arbeitsumgebung. Die Plattform umfasst zentrale Komponenten wie Collabora Online für Dokumentenbearbeitung, Nextcloud für Dateiverwaltung und Collaboration, Open-Xchange für E-Mail und Groupware sowie weitere integrierte Dienste. Für maximale Isolation und Datensicherheit erhält jeder Mandant in der Produktivumgebung einen dedizierten Kubernetes-Cluster. Die Software ist jedoch so konzipiert, dass sie auch den Betrieb mehrerer Mandanten in separaten Namespaces innerhalb eines Clusters unterstützt, was in Entwicklungs- und Testumgebungen zur Anwendung kommt.

Ziel der Backup-Strategie

Ziel dieses Dokuments ist es, eine strukturierte und zuverlässige Lösung für die Sicherung und Wiederherstellung von Daten und Konfigurationen zu etablieren. Angesichts der SaaS-Natur der Plattform und der damit verbundenen Verantwortung gegenüber den Mandanten ist ein robustes Backup- und Restore-Konzept unerlässlich, um Datenverlust zu verhindern, Service-Kontinuität zu gewährleisten und regulatorische Anforderungen zu erfüllen.

Zur Umsetzung dieses Konzepts wird K8up als Backup-Lösung eingesetzt. K8up ist ein Kubernetes-nativer Operator für Backup und Restore, der auf Restic basiert und speziell für containerisierte Umgebungen entwickelt wurde. Die Lösung ermöglicht automatisierte Backups von Persistent Volumes, Anwendungsdaten und Kubernetes-Ressourcen und bietet gleichzeitig flexible Aufbewahrungsrichtlinien und eine einfache Integration in bestehende S3-kompatible Storage-Backends. Weitere Details zu K8up finden sich in der offiziellen Dokumentation unter https://k8up.io.

Dieses Konzept dient als zentrale Dokumentation für alle relevanten Stakeholder und definiert die technischen Anforderungen, Backup-Strategien, Restore-Prozesse sowie die operativen Verantwortlichkeiten. Es bildet die Grundlage für den sicheren Betrieb der openDesk-SaaS-Plattform und gewährleistet die Verfügbarkeit der Daten und die Integrität der Backup-Repositories. Hinweis: Die logische Integrität der Anwendungsdaten (Application Consistency) wird durch die Backup-Mechanismen nicht validiert, sondern setzt konsistente Datenexporte voraus.

Überblick über die Infrastruktur

openDesk betreibt aktuell ein dediziertes Kubernetes-Cluster pro Mandant (Kunde) basierend auf dem STACKIT Kubernetes Engine (SKE), einem vollständig verwalteten Managed-Kubernetes-Service. Bei Onboarding eines neuen Mandanten wird ein neuer Cluster provisioniert und über ein standardisiertes Deployment-Template mittels ArgoCD initialisiert (Bootstrapping). Diese mandanten-isolierte Architektur gewährleistet maximale Datentrennung. Der Bootstrapping-Prozess kombiniert Terraform für die Infrastruktur-Provisionierung mit ArgoCD für die automatisierte Anwendungs-Deployment und bildet damit die Grundlage für die Disaster-Recovery-Strategie.

Die für die Backup- und Restore-Strategie relevanten Infrastrukturkomponenten werden nachfolgend dargestellt und beschrieben

graph TB
    %% Styles - Unverändert
    classDef git fill:#e3f2fd,stroke:#2196f3,stroke-width:2px,color:#000
    classDef gitops fill:#f1f8e9,stroke:#66bb6a,stroke-width:2px,color:#000
    classDef apps fill:#fff3e0,stroke:#fb8c00,stroke-width:2px,color:#000
    classDef storage fill:#fce4ec,stroke:#ec407a,stroke-width:2px,color:#000
    classDef db fill:#e1bee7,stroke:#9c27b0,stroke-width:2px,color:#000
    classDef managed fill:#b2dfdb,stroke:#009688,stroke-width:2px,color:#000
    classDef cloud fill:#f0f8ff,stroke:#00897b,stroke-width:3px,color:#000
    classDef monitor fill:#ffccbc,stroke:#ff5722,stroke-width:2px,color:#000

    %% Ebene 1: Source & GitOps
    subgraph Deployment Flow
        Git[Git Repositories<br/>K8s Manifests + Terraform Modules<br/>GitOps Prinzip]:::git
        ArgoCD[ArgoCD Controller<br/>Namespace: argocd<br/>Auto-Sync aus Git]:::gitops
    end

    %% Ebene 2: Applikation
    Apps[Anwendungen<br/>Namespace: kunde-opndsk-de<br/>Keycloak, OpenLDAP, Nextcloud,<br/>OX, OpenProject, Element,<br/>XWiki, Collabora, Jitsi]:::apps

    %% Ebene 3: Daten & Storage (Logisch nebeneinander angeordnet)
    
    %% Gruppe 1: K8s Native Storage
    PV[Persistent Volumes<br/>App-Daten, Configs + Cache<br/>z.B. OpenLDAP Directory Database]:::storage

    %% Gruppe 2: Self-Managed DBs
    subgraph Self-Managed Databases
        Cassandra[(Self-Managed Cassandra<br/>StatefulSet <br/>Namespace: kunde-opndsk-de<br/>NoSQL distributed DB)]:::db
        PVCassandra[PVCs]:::storage
        
        MariaDB[(Self-Managed MariaDB<br/>StatefulSet <br/>Namespace: kunde-opndsk-de-infra<br/>Operator: mariadb-operator)]:::db
        PVMariaDB[PVCs]:::storage
    end

    %% Gruppe 3: Managed Cloud Services (KORRIGIERT)
    subgraph StackitCloud[STACKIT Cloud Services]
        Postgres[(Managed PostgreSQL<br/>Außerhalb K8s Cluster<br/>Managed Service)]:::db
        S3[Managed S3<br/>Primärer Datenspeicher<br/>Object Versioning<br/>S3-API Access]:::managed
    end
    
    %% Ebene 4: Offsite Backup
    S3Offsite[Offsite S3 Backup<br/>Sekundärer Storage<br/>Geografische Redundanz]:::managed

    %% Monitoring (Seitlich platziert)
    Prom[Prometheus Monitoring<br/>Namespace: monitoring<br/>Metriken-Sammlung<br/>Begrenzte Aufbewahrung]:::monitor

    %% Hauptfluss-Beziehungen
    Git -->|GitOps Sync| ArgoCD
    ArgoCD -->|Deploys| Apps
    
    Apps -->|App-Daten + Config| PV
    Apps -->|NoSQL Data| Cassandra
    Apps -->|Relational Data| MariaDB
    Apps -->|Relational Data| Postgres
    Apps -->|Primary Data Storage| S3

    %% Storage Persistenz Beziehungen
    Cassandra -->|Persistiert auf| PVCassandra
    MariaDB -->|Persistiert auf| PVMariaDB

    %% Backup Beziehung
    S3 ==>|Repliziert zu| S3Offsite

    %% Monitoring & Secrets Beziehungen (Gestrichelt)
    Prom -.->|Überwacht| Apps
    Prom -.->|Überwacht| Cassandra
    Prom -.->|Überwacht| MariaDB
    
    Apps -.->|Nutzt Secrets für| Postgres
    Apps -.->|Nutzt Secrets für| S3

    %% Explizite Stilzuweisung für den Subgraph (KORREKTUR)
    class StackitCloud cloud

  • Git Repositories enthalten sowohl die Kubernetes-Manifests für alle Anwendungen als auch Terraform-Module für die Infrastruktur-Provisionierung. Da die gesamte Konfiguration gemäß dem GitOps-Prinzip verwaltet wird, genügt zur Wiederherstellung der Logik das erneute Ausrollen des Git-Repositories. Beim GitOps-Prinzip wird der gewünschte Systemzustand deklarativ in einem Git-Repository definiert und durch einen Controller (ArgoCD) automatisch mit dem Cluster synchronisiert.

  • ArgoCD läuft als Controller in einem dedizierten Namespace im Cluster und synchronisiert automatisch die Manifests aus Git in den Cluster. Im Backup-Kontext ist relevant, dass alle ArgoCD-verwalteten Anwendungen nach einem Cluster-Rebuild automatisch aus Git wiederhergestellt werden können.

    Hinweis: Die "Self-Heal"-Funktion ist standardmäßig deaktiviert, da einige Applikationen (z.B. Nubus) diese Funktion nicht unterstützen und es sonst zu Konflikten kommen kann.

  • Die Anwendungen (Keycloak, OpenLDAP, Nextcloud, OX, OpenProject, Element, XWiki, Collabora, Jitsi) laufen im mandantenspezifischen Customer-Namespace <kunde>-<stage> und erzeugen verschiedene Arten von persistenten Daten. Die meisten Anwendungen speichern ihre eigentlichen Nutzdaten direkt im STACKIT Managed S3 (z.B. Nextcloud-Dateien, Mediendateien) oder in den Datenbanken (PostgreSQL, MariaDB, Cassandra), während die Persistent Volumes primär für Konfigurationsdateien, Anwendungs-Logs und temporäre Daten genutzt werden. Eine wichtige Ausnahme bilden hierbei Cassandra und MariaDB, welche ihre kritischen Anwendungsdaten direkt auf den Persistent Volumes speichern. Diese Architektur bedeutet, dass zwar Teile der Daten außerhalb der PVs liegen (Managed Services), jedoch für die auf PVs liegenden Datenbanken zwingend Mechanismen zur Sicherung der Application Data erforderlich sind.

  • Persistent Volumes basieren auf STACKIT Managed Block Storage und speichern sowohl Anwendungskonfigurationen und temporäre Cache-Daten als auch primäre Anwendungsdaten für bestimmte Anwendungen wie OpenLDAP. Während die meisten Anwendungen ihre Daten primär in S3 schreiben, nutzen einige Anwendungen PVs zum Zwischenspeichern geschäftskritischer Daten oder als primären Datenspeicher (z.B. OpenLDAP Directory Database).

  • Self-Managed Cassandra DB (Namespace: <kunde>-<stage>). Dient ausschließlich als Speicher für spezifische Komponenten wie Dovecot-Metadaten (ACL-Listen, Mail-Metadaten). Diese Komponente ist nur relevant, wenn der Mail-Stack (Dovecot) direkt im Cluster betrieben wird.

  • Self-Managed MariaDB wird als StatefulSet in einem separaten Infrastructure-Namespace <kunde>-<stage>-infra betrieben, während der MariaDB-Operator in einem separaten Namespace mariadb-operator läuft. Die relationale Datenbank persistiert ihre Daten auf PersistentVolumeClaims. Der Operator automatisiert Lifecycle-Management-Aufgaben wie Provisionierung, Konfiguration und Verwaltung der MariaDB-Instanzen

  • STACKIT Managed Postgres ist ein vollständig verwalteter Datenbankdienst, der von ☁️STACKIT Cloud außerhalb des Kubernetes-Clusters betrieben wird. openDesk-Anwendungen nutzen diese zentrale PostgreSQL-Instanz für ihre relationalen Daten. Der Managed Service übernimmt automatisch Wartung, Patches und Hochverfügbarkeit. Die Verbindungs-Credentials werden als Kubernetes Secrets im Cluster hinterlegt.

  • STACKIT Managed S3 dient als primärer Datenspeicher für die meisten openDesk-Anwendungen. Die Anwendungen greifen über S3-APIs auf diesen Storage zu, wobei die Access Keys als Kubernetes Secrets im Cluster hinterlegt sind. S3 bietet Object Versioning, wodurch frühere Versionen von Objekten erhalten bleiben und bei Bedarf wiederhergestellt werden können.

    Abgrenzung (S3-Storage): openDesk bietet optional die Möglichkeit, einen S3-compatible Object Storage via MinIO direkt im Cluster zu betreiben. Dieses Feature ist nicht Bestandteil des aktuellen Backup-Konzepts, da für die Speicherung von Objekten ausschließlich der externe Managed S3 Service von STACKIT genutzt wird.

  • Offsite S3 Backup fungiert als sekundärer Object Storage für geografische Redundanz. Die Daten aus dem STACKIT Managed S3 werden in diesen Offsite-Storage repliziert, um Disaster Recovery über Rechenzentren hinweg zu gewährleisten. Der konkrete Provider für diesen Offsite-S3-Speicher ist noch nicht final festgelegt; aktuell befinden sich Regio Cloud und Hetzner als S3-kompatible Optionen in der Evaluierung.

  • Prometheus Monitoring läuft im Cluster im Namespace monitoring und sammelt Metriken von allen Anwendungen und Kubernetes-Komponenten. Die Monitoring-Daten werden typischerweise nur für einen begrenzten Zeitraum aufbewahrt und dienen der Überwachung der Cluster-Gesundheit und Performance-Analyse

Die folgende Übersicht zeigt die Namespace-Struktur in einer Kundeninstanz (dediziertes Cluster) am Beispiel des Kunden "schulung":

NAME                         STATUS   AGE
argocd                       Active   50d
cert-manager                 Active   50d
cluster-infra                Active   50d
default                      Active   50d
fluentbit                    Active   50d
ingress-nginx                Active   50d
k8up                         Active   50d
kruise-daemon-config         Active   50d
kruise-system                Active   50d
kube-node-lease              Active   50d
kube-public                  Active   50d
kube-system                  Active   50d
mariadb-operator             Active   50d
monitoring                   Active   50d
oauth2-proxy                 Active   50d
openkruise                   Active   50d
schulung-opndsk-de           Active   48d
schulung-opndsk-de-infra     Active   48d

Die Namespace-Struktur gliedert sich in System-Namespaces (z.B. kube-system, kube-public), Operator- und Tool-Namespaces (z.B. argocd, k8up, mariadb-operator, monitoring) sowie kundenspezifische Namespaces (kunde-opndsk-de für Anwendungen und kunde-opndsk-de-infra für Infrastruktur-Komponenten)

Abweichende Architektur für Großumgebungen

Während Standard-Installationen vollständig innerhalb des Kubernetes-Clusters betrieben werden, nutzen große Produktivinstanzen eine ausgelagerte Infrastruktur für Dovecot und Rspamd, die auf dedizierten virtuellen Maschinen (VMs) verteilt ist. Diese Architektur umfasst zusätzlich eine separate Redis-Instanz zur Speicherung von Spam-Learning-Listen.

Wichtiger Hinweis: Für diese ausgelagerten VM-Komponenten (insbesondere die Redis-Daten des Rspamd) existiert zum aktuellen Zeitpunkt noch kein integriertes Backup-Konzept. Dies stellt eine Abweichung vom Standard-Vorgehen dar und muss gesondert betrachtet werden.

Anforderungen an Backup und Restore

Recovery Point Objective (RPO)

Das RPO definiert den maximal akzeptablen Datenverlust im Falle eines Ausfalls.

  • Zielwert: 24 Stunden.
  • Begründung: Die automatisierte Sicherung aller persistenten Daten erfolgt standardmäßig einmal täglich (nächtlicher Batch-Lauf). Im schlimmsten Fall (Ausfall kurz vor dem nächsten geplanten Backup) entspricht der Datenstand dem des vorangegangenen Abends.

Recovery Time Objective (RTO)

Das RTO definiert die maximal zulässige Zeitdauer vom Zeitpunkt der Schadensmeldung bis zur Wiederherstellung der Betriebsbereitschaft der kritischen Dienste.

  • Zielwert: 4 bis 8 Stunden (innerhalb der vereinbarten Servicezeiten).
  • Begründung: Die Wiederherstellung umfasst die Bereitstellung der Infrastruktur, den Download der Restic-Snapshots vom S3-Speicher und das Einspielen der Dumps in die Datenbanken. Die tatsächliche Dauer ist abhängig von der Datenmenge und der verfügbaren Bandbreite zum Offsite-Storage. Die Datenmenge wächst dabei mit der Anzahl der Benutzer einer Kundeninstanz, der Intensität der Nutzung (z.B. Datei-Uploads in Nextcloud, E-Mail-Volumen, Chat-Verkehr) sowie der Änderungs- bzw. Wachstumsrate der Daten über die Zeit.

Aufbewahrungsrichtlinien (Retention Policy)

Um eine historische Datenwiederherstellung zu ermöglichen und gleichzeitig Speicherplatz effizient zu nutzen, wird eine rollierende Aufbewahrungsstrategie (Grandfather-Father-Son Prinzip) angewendet. Die Standard-Konfiguration in K8up (siehe Kapitel 2.1.3) sieht vor:

  • Letzte Backups: Die letzten 5 Snapshots werden unabhängig vom Alter vorgehalten.
  • Tägliche Backups: Vorhaltung der letzten 14 Tage.
  • Wöchentliche Backups: Vorhaltung der letzten 4 Wochen.
  • Monatliche Backups: Vorhaltung der letzten 12 Monate.
  • Jährliche Backups: Vorhaltung der letzten 2 Jahre.

Wichtiger Hinweis: Die oben definierten Aufbewahrungsfristen basieren auf technischen Standard-Policies. Sie müssen im Rahmen des noch zu erstellenden Löschkonzepts zwingend überprüft und ggf. angepasst werden, um sicherzustellen, dass kundenspezifische Datenlöschfristen und datenschutzrechtliche Vorgaben (z.B. "Recht auf Vergessenwerden") auch in den Backups korrekt abgebildet werden.

Weitere Anforderungen

  • Vollautomatisierte Sicherung: Der gesamte Backup-Prozess (Auslösen, Snapshot-Erstellung, Übertragung, Pruning) muss ohne manuellen Eingriff zeitgesteuert erfolgen.
  • Standardisierter Restore-Workflow: Wiederherstellungsprozesse müssen soweit wie möglich skriptbasiert oder durch Tools unterstützt sein, um die Abhängigkeit von individuellem Expertenwissen im Disaster-Fall zu reduzieren.
  • Infrastructure-as-Code (IaC) Integration: Die Backup-Konfiguration selbst (Zeitpläne, Retention-Policies) muss deklarativ definiert und versioniert sein (GitOps), um eine automatische Wiederherstellung der Backup-Funktionalität bei einem Cluster-Neuaufbau zu garantieren.
  • Testbarkeit: Die Automatisierung muss regelmäßige, automatisierte Integritätstests (z.B. Repository-Checks) ermöglichen, um die Wiederherstellbarkeit proaktiv zu überwachen.
  • Geografische Redundanz: Alle Backups müssen zwingend an einen sekundären, physisch getrennten Standort (Offsite S3) repliziert werden.
  • Kosteneffizienz: Die Auswahl des Offsite-Speichers muss unter Berücksichtigung der Total Cost of Ownership (TCO) erfolgen. Insbesondere für die Langzeitarchivierung (Retention > 30 Tage) sind Speicherklassen zu wählen, die geringe Speicherkosten bieten (z.B. Cold Storage), da schnelle Zugriffszeiten für historische Daten eine untergeordnete Rolle spielen.