Private Cloud: Backup-Strategie und Identitätsmanagement

Teil 1: Was gesichert wird — und was nicht #

Backup ist kein Feature, es ist ein Versprechen #

Eine private Cloud ohne Backup-Strategie ist kein souveräner Betrieb — es ist ein Experiment auf Zeit. Irgendwann geht etwas schief: eine versehentlich gelöschte Datenbank, ein Kubernetes-Upgrade, das einen StatefulSet zerschießt, ein versehentlich gelöschter Namespace. Die Frage ist nicht ob, sondern wann.

Meine Backup-Strategie folgt einem einfachen Prinzip: Ich will wissen, was gesichert wird, warum es gesichert wird, und wie ich es wiederherstelle. Kein Tool, das heimlich Dinge tut, die ich nicht nachvollziehen kann.

Velero — der Backbone des Backups #

Velero ist das zentrale Backup-Tool für den gesamten Kubernetes-Cluster. Es sichert Kubernetes-Ressourcen — also die YAML-Definitionen von Deployments, StatefulSets, Services, ConfigMaps, Secrets — und die persistenten Volumes, die dazu gehören. Die Volume-Inhalte werden dabei von Kopia clientseitig verschlüsselt, bevor sie in einem S3-Bucket bei Contabo landen. Die Ressourcen-Backups gehen per TLS dorthin; Secrets sind durch SOPS bereits im Cluster verschlüsselt und damit auch im Backup nur als Chiffrat enthalten.

Velero läuft nach einem festen Schedule: täglich ein vollständiges Backup aller Namespaces, mit einer Retention von 14 Tagen. Zwei Wochen sind genug, um Bedienfehler oder fehlgeschlagene Upgrades zurückzudrehen — für Langzeit-Archivierung ist Velero nicht das richtige Werkzeug.

Das Besondere an diesem Ansatz: Da alle Datenbanken als eigene StatefulSets laufen und ihre Daten in Longhorn-Volumes liegen, sind sie Teil des Velero-Backups. Ein Trade-off ist hier offen zu nennen: Velero sichert das Filesystem im laufenden Betrieb, nicht über einen DB-eigenen, transaktionssicheren Dump. Im Restore-Fall startet PostgreSQL aus dem Crash-Recovery-Modus — das funktioniert in der Praxis zuverlässig, ist aber nicht dasselbe wie ein pg_dump. Wer maximale Sicherheit will, ergänzt einen logischen Dump als CronJob. Für meinen Einsatzfall ist die Crash-Recovery ausreichend, weil ich kein zweites Backup-Tool im Stack haben will.

Was bewusst nicht gesichert wird #

Und hier liegt die interessanteste Entscheidung der ganzen Backup-Strategie: Die eigentlichen Nextcloud-Dateien — also alles, was Nutzer in Nextcloud hochladen — werden nicht von Velero gesichert.

Warum? Weil die Nextcloud-Dateien gar nicht im Cluster liegen. Nextcloud ist so konfiguriert, dass der primäre Datenspeicher direkt in den S3-Bucket bei Contabo zeigt — die Dateien sind also schon dort, bevor irgendein Backup laufen könnte. Velero sichert nur noch die Nextcloud-Datenbank, die das Mapping zwischen S3-Objekt und Dateinamen enthält.

Das verschiebt die Frage allerdings, statt sie zu lösen: Ich verlasse mich für die eigentlichen Dateien vollständig auf Contabo. Das deckt Hardwareausfälle und Cluster-Probleme ab — gegen ein versehentliches Löschen durch Nextcloud, einen kompromittierten S3-Access-Key oder einen Account-Verlust bei Contabo hilft es nicht. Wer diese Szenarien abdecken will, braucht eine unabhängige Zweitkopie bei einem anderen Anbieter; das ist eine bewusste Erweiterung, die außerhalb dieser Serie liegt.

Für Immich ist die Situation strukturell ähnlich: Die Mediendateien liegen im NFS-Volume und werden separat behandelt. Velero sichert hier wie bei Nextcloud die Datenbank — Metadaten, Benutzerkonten, Alben — nicht die eigentlichen Mediendaten.

Restore — der eigentliche Test eines Backups #

Ein Backup, das nie getestet wurde, ist kein Backup — es ist Hoffnung. Deshalb gibt es für den Restore-Fall eine konkrete Vorgehensweise, die ich quartalsweise teste — meist im Sandbox-Namespace, einmal pro Jahr als vollständiger Cluster-Neuaufbau auf einem Test-Proxmox.

Für einzelne Namespaces: velero restore create --from-backup <backup-name> --include-namespaces <namespace>. Das reicht für den häufigsten Fall — eine App ist kaputt, der Rest des Clusters läuft weiter.

Für einen vollständigen Cluster-Neuaufbau: Proxmox aufsetzen, Kubernetes mit Ansible deployen, Flux bootstrappen, den SOPS-age-Key aus dem Offline-Backup einspielen, Velero installieren, S3-Credentials konfigurieren, Backup einspielen. Die Ansible-Playbooks und Flux-Konfigurationen sind selbst im Git-Repository gesichert — der Cluster ist also vollständig reproduzierbar. Der age-Key ist der einzige Teil des Setups, der außerhalb von Git existiert — ohne ihn wäre auch das beste Backup nutzlos.

Die Eleganz des Ansatzes liegt in der Einfachheit: ein Backup-Tool, ein Ziel, eine Retention-Policy. Was nicht da ist, muss nicht gesichert werden — und Nextcloud-Dateien sind bereits in S3.

Teil 2: Kanidm — SSO ohne Enterprise-Ballast #

Soweit zur Datenhaltung. Der zweite Teil dieses Posts geht zu einer ganz anderen Ebene der Sovereignty: Wer darf eigentlich was sehen?

Was ist Kanidm überhaupt? #

Kanidm ist ein moderner Identity-Provider, geschrieben in Rust, mit einem klaren Designziel: einfach zu betreiben, sicher by default, ohne administrative Komplexität. Es implementiert OAuth 2.0 und OIDC — die Standards, die heute hinter jedem “Mit Google anmelden”-Button stecken — und macht sie für kleine Setups zugänglich.

Das bedeutet: Nextcloud, Paperless-ngx und Immich kennen keinen lokalen Benutzer mehr. Sie vertrauen Kanidm, dass es sagt wer wer ist. Ein Login, zentral verwaltet, und jede App delegiert die Authentifizierung.

Was Kanidm kann — und was es bewusst nicht tut #

Kanidm bietet alles, was für diesen Stack gebraucht wird: Benutzerverwaltung, Gruppen, OAuth2/OIDC für Apps, MFA per TOTP oder Passkeys, und eine ergonomische CLI. Die Konfiguration ist in wenigen YAML-Dateien beschreibbar — kein riesiges Admin-UI, keine Enterprise-Konzepte, die man erst verstehen muss.

Was Kanidm bewusst nicht tut: Es abstrahiert nicht jeden denkbaren Unternehmensanwendungsfall. Es gibt keine SAML-Unterstützung für Legacy-Systeme, keine komplexen attributbasierten Zugriffsregeln, keine eingebaute Policy-Engine für Fine-grained Authorization. Das ist kein Mangel — es ist eine Designentscheidung, die den Betrieb einfach hält.

Wann Keycloak die bessere Wahl wäre #

Keycloak ist ein hervorragendes Produkt. Es ist mächtig, weit verbreitet, gut dokumentiert und in vielen Unternehmen im produktiven Einsatz. Es wäre die richtige Wahl, wenn:

• SAML für ältere Systeme gebraucht wird — Kanidm spricht kein SAML. Wenn Legacy-Applikationen oder externe Partner SAML voraussetzen, führt kein Weg an Keycloak vorbei.
• Mehrere Tenants oder Organizations mit eigenen Benutzerverwaltungen verwaltet werden müssen — Keycloak hat Realms, Kanidm ein flacheres Modell.
• Komplexe attributbasierte Zugriffsregeln oder Fine-grained Policies benötigt werden — Keycloak kann das, Kanidm nicht.
• Ein Team von mehreren Administratoren die Identitätsverwaltung betreibt und eine umfangreiche Web-Oberfläche braucht — Keycloaks Admin-UI ist erheblich umfangreicher.

Kurz: Keycloak ist für Unternehmen gebaut, die Identity als ein komplexes, zentrales System betreiben. Das ist seine Stärke — und gleichzeitig der Grund, warum es für Ein-Mann-Betriebe und kleine Mittelständler mit überschaubarem Anwendungs-Stack mehr Aufwand bedeutet, als der Nutzen rechtfertigt.

Warum Kanidm für diesen Anwendungsfall besser passt #

Für eine private Cloud oder einen kleinen Anwendungs-Stack bietet Kanidm genau das richtige Verhältnis von Funktionalität zu Betriebsaufwand. Es startet schnell, braucht wenig Ressourcen — relevant auf einem i3 mit geteilten Ressourcen — und die Konfiguration ist so überschaubar, dass man sie vollständig im Kopf halten kann.

Keycloak hingegen braucht eine eigene PostgreSQL-Instanz, erheblich mehr RAM, und die initiale Konfiguration über das Admin-UI ist umfangreich genug, dass man leicht den Überblick verliert. Für einen überschaubaren Stack ist das ein unausgewogenes Verhältnis.

Der entscheidende Punkt: Kanidm ist nicht Keycloak light. Es ist ein eigenständiges, gut durchdachtes Tool mit einem anderen Designziel. Wer versteht, was es kann und was nicht, bekommt ein stabiles, wartungsarmes SSO-System.

Der Vergleich macht deutlich: Es geht nicht darum, dass Keycloak schlechter wäre. Es geht darum, dass die Anforderungen den richtigen Rahmen setzen. Für SAML, Multi-Tenancy und komplexe Policies ist Keycloak die richtige Wahl. Für einen überschaubaren Anwendungs-Stack und Anforderungen, die ohne Föderation, Brokering und komplexes Rollen-Mapping auskommen, ist Kanidm das bessere Werkzeug.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen mit digitaler Souveränität — ich freue mich auf die Diskussion: