Backups mit Longhorn & MinIO

Longhorn + MinIO: Backups einrichten

MinIO ist ein objektbasierter Speicher, der das S3-Protokoll unterstützt – genauso wie Amazon S3 und andere S3-kompatible Lösungen. Der große Vorteil: MinIO lässt sich flexibel einsetzen – sowohl On-Premises als auch in der Cloud. Wer möchte, kann MinIO selbst betreiben und zusätzlich einen Cloud-S3-Bucket als externes Backup-Ziel einbinden.

Diese Flexibilität macht MinIO zur idealen Lösung als Backup-Target für Longhorn.

Longhorn als StorageClass

Longhorn ist ein cloud-nativer Distributed Block Storage für Kubernetes. Es bietet Snapshot- und Backup-Funktionalitäten, eine übersichtliche Web-Oberfläche und lässt sich unkompliziert in bestehende Setups integrieren.

In unserem Setup verwenden wir Longhorn als Standard-StorageClass. Die Installation erfolgt bequem über die Rancher UI – das eigene Longhorn-Dashboard ist danach direkt im Browser erreichbar.

Backupstrategie

Longhorn benötigt Zugriff auf MinIO – genauer gesagt auf einen dedizierten Bucket, in dem die Backups gespeichert werden.
Dafür müssen wir ein Access Key und ein Secret Key generieren und Longhorn zur Verfügung stellen.

Wir folgen dabei dem bewährten Prinzip “Least Privilege”:
Das heißt, wir legen in MinIO einen separaten Bucket an, erstellen eine Policy mit minimal nötigen Rechten und weisen diese einem technischen Benutzer zu.

Da wir unser zentrales Identity Management über Keycloak abbilden, wird dieser Benutzer nicht direkt in MinIO angelegt, sondern per OIDC über Keycloak verwaltet.

Wie genau man MinIO per OpenID Connect an Keycloak anbindet, erklären wir im Detail hier:

👉 Keycloak als OIDC-Provider – Zentrales Identity Management

Dort zeigen wir auch, wie man Benutzerrollen und Policies über Attribute steuert – so auch in diesem Fall für den Zugriff auf den Backup-Bucket.

MinIO Bucket und Policy anlegen

Um Backups zu speichern, benötigen wir zunächst einen dedizierten Bucket in MinIO.
Diesen legen wir in der MinIO-Konsole unter Buckets > Create Bucket an – z. B. mit dem Namen cluster-backups.

Im nächsten Schritt erstellen wir unter Policies eine neue Richtlinie, die ausschließlich Zugriff auf diesen einen Bucket erlaubt.
Sie sollte etwa wie folgt aussehen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::cluster-backups"
    },
    {
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::cluster-backups/*"
    }
  ]
}

Keycloak User

Anschließend legen wir den technischen Benutzer zentral in Keycloak an und weisen ihm über das policy-Attribut die zuvor definierte MinIO-Policy zu – in unserem Fall heißt sie clusterBackupsReadWrite.
Weitere Rechte braucht der User nicht und sollte sie auch nicht haben!

Das policy-Attribut lässt sich auf zwei Wegen zuweisen:

1. über eine Gruppe mit entsprechendem Attribut,
2. oder direkt am Benutzer.

Da dieser Benutzer keine weiteren Rollen oder Zwecke erfüllt, reicht es, das Attribut direkt am Benutzer zu setzen.
In neueren Keycloak-Versionen muss dafür in den Realm-Einstellungen die Option Unmanaged Attributes aktiviert werden:

Danach lässt sich das Attribut wie gewohnt anlegen:

Die Authentifizierung in MinIO erfolgt weiterhin über OIDC.
Sobald sich der Longhorn-Benutzer erfolgreich über Keycloak bei MinIO anmeldet, können wir in der MinIO-Oberfläche für diesen Benutzer ein Access Key und ein Secret Key generieren:

Diese Zugangsdaten benötigen wir später, um Longhorn mit dem Backup-Bucket zu verbinden.

Secret in Longhorn Namespace anlegen

Der Rest der Konfiguration ist recht unkompliziert:
Wir müssen ein Secret im Longhorn-Namespace hinterlegen, das die Zugangsdaten enthält.
Das Secret könnte zum Beispiel so aussehen:

# longhorn-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: longhorn-minio-credentials
  namespace: longhorn-system
type: Opaque
data:
  AWS_ACCESS_KEY_ID: dDZkc3REc1lRdWY3cGJTag==
  AWS_SECRET_ACCESS_KEY: UTlSUFdLeFo0YlVJcUJTenVPWTZUTGtGa1hjSHN6UlU=
  AWS_ENDPOINTS: aHR0cDovLzE5Mi4xNjguMS42Njo5MDAwLw==

⚠️ Ein paar Hinweise

Damit alles reibungslos funktioniert, muss sichergestellt sein, dass der Wert für AWS_ENDPOINTS den Port enthält.
MinIO ist bei uns im Cluster unter https://minio.osaia.cloud über den Standardport 9000 erreichbar.
Dieser Port muss explizit im Secret angegeben werden:

AWS_ENDPOINTS=https://minio.osaia.cloud:9000

Außerdem: Alle Secret-Werte müssen in Base64 kodiert sein – das ist in Kubernetes Pflicht.

Die Werte müssen natürlich an die eigene Umgebung angepasst werden – das hier ist nur ein Beispiel.

Anschließend kann das Secret mit kubectl eingespielt werden:

kubectl apply -f longhorn-secret.yaml

Nun wechseln wir in die Longhorn UI unter
Settings > Backup Target > default
und tragen die folgenden Werte ein:

• Credential Secret ist der Name des zuvor erstellten Kubernetes-Secrets.
• Die Backup Target URL wird bei Longhorn in folgendem Format angegeben:

s3://BUCKET_NAME@REGION/

Da wir MinIO On-Premises hosten, gibt es keine echte Region im Sinne von AWS. Trotzdem verlangt Longhorn zwingend einen Region-Eintrag.
Ihr könnt hier einfach eine gültige AWS-Region wie us-east-1 verwenden – technisch ist der Wert in unserem Setup irrelevant.

Wenn alles korrekt eingerichtet ist, sieht die Konfiguration anschließend so aus:

Nun kannst du unter dem Reiter Volumes ein Volume auswählen und ein Backup erstellen:

Super, das war’s! 🎉
Jetzt haben wir ein funktionierendes Backup, mit dem sich ein Volume jederzeit wiederherstellen oder neu erstellen lässt:

Damit ist ein wichtiger Schritt in Richtung Disaster Recovery erledigt.

Fazit

Mit der Kombination aus Longhorn und MinIO steht uns eine leistungsfähige, flexible und vollständig selbst verwaltbare Backup-Lösung zur Verfügung – ideal für produktionsnahe Kubernetes-Setups.

Durch die zentrale Authentifizierung über Keycloak und den Einsatz des Least Privilege-Prinzips behalten wir die volle Kontrolle über unsere Backup-Infrastruktur – sicher, nachvollziehbar und automatisierbar.

Ob On-Premises oder in der Cloud:
Backups lassen sich mit diesem Setup zuverlässig und konsistent abbilden – ein zentraler Baustein für jede Disaster-Recovery-Strategie.

Das Beste daran:
Alles bleibt in unserer Hand – ohne externe Abhängigkeiten und mit voller Transparenz über Speicher, Zugriff und Sicherheit.

---

Dieser Beitrag wurde erstellt von OSAIA Consulting – Experten für Platform Engineering, Automatisierung und Softwarearchitektur.

💬 Fragen oder Feedback?
Wir freuen uns über den Austausch – schreibt uns jederzeit über unsere Website.