IBM Fusion 2.9.x – Backup & Restore auf OpenShift

Zwei Schutzarten, zwei Aufgaben

Fusion Backup & Restore kennt zwei Dinge, die leicht verwechselt werden: den Schutz deiner Anwendungen und den Schutz des Backup-Werkzeugs selbst. Wer das vermischt, baut ein Konzept mit einer Lücke, die erst im Ernstfall auffällt.

Was Fusion sichert – und was nicht

Schutzart	Sichert	Sichert nicht
Application Protection	Alle namespace-scoped Ressourcen einer Anwendung plus abhängige cluster-scoped Ressourcen, dazu die PVC-Daten	Namespaces, die nicht als Anwendung erfasst sind
Service Protection	Den Backup-&-Restore-Service selbst: Locations, Policies, Policy Assignments, Backup-CRs	etcd, Control Plane, Node-Konfiguration, Anwendungsdaten

Die Umzugsfirma – Application Protection fährt Möbel ins Lager. Service Protection sichert die Aktenordner der Firma: Inventarlisten, Kundenadressen, Auftragszettel. Zwei völlig verschiedene Güter, zwei getrennte Lagerorte.

Achtung: „Service Protection" liest sich wie ein Cluster-Backup und wird regelmäßig für eines gehalten. Es sichert weder etcd noch die OpenShift Control Plane. Wer sich darauf verlässt, hat ein Backup-Konzept, das grün meldet und den wichtigsten Fall nicht abdeckt – siehe Abschnitt 5.

Wo die Objekte liegen

Der Fusion-Namespace ist per Default ibm-spectrum-fusion-ns, kann aber abweichen. Der Service-Namespace des Backup-Tools ist ebenfalls konfigurierbar – hart auf ibm-backup-restore zu verweisen, ist deshalb ungenau. Beide Werte solltest du am laufenden Cluster ablesen statt anzunehmen.

# Fusion-Instanz und ihren Namespace finden
oc get spectrumfusion -A

# Service-Namespace des Backup-&-Restore-Service auslesen
oc -n <fusion-namespace> get fusionserviceinstance \
  ibm-backup-restore-service-instance -o json | jq '.spec.parameters'

Data-Bucket und Catalog-Bucket

Zwei S3-Buckets mit unterschiedlichem Inhalt und unterschiedlicher Lebensdauer. Der eine enthält Nutzdaten, der andere das Wissen darüber, wo diese Nutzdaten liegen.

Data-Bucket

Ziel der Application Backups. Hier liegen die Kubernetes-Objekte der Anwendungen und die Inhalte ihrer PVCs. Wächst mit der Datenmenge, wird regelmäßig beschrieben, unterliegt der Retention der Backup Policy.

Catalog-Bucket

Ziel der Service Protection. Enthält keine Anwendungsdaten, sondern die Verwaltung: welche Locations es gibt, welche Policies, welche Zuordnungen, welche Backups existieren. Klein, aber ohne ihn ist der Data-Bucket ein Lager ohne Inventarliste.

Lager und Inventarliste – ein Lager ohne Liste ist ein Haufen unbeschrifteter Kisten. Eine Liste ohne Lager ist Papier. Nur beides zusammen ergibt eine Wiederherstellung.

Warum Fusion die Liste braucht

Fusion findet Backups nicht dadurch, dass es ein Bucket durchsucht. Es kennt sie über die Backup-CRs im Cluster. Ist der Cluster weg, sind auch die CRs weg – und damit die Kenntnis darüber, dass im Data-Bucket überhaupt etwas liegt. Der Catalog-Restore stellt genau diese Kenntnis wieder her, keine einzige Anwendung.

Achtung: Läuft dein S3 lokal auf demselben Cluster, stirbt der Catalog-Bucket im Totalausfall mit. IBM verlangt für diesen Fall eine zusätzliche externe Sicherung der S3-Daten. Bis dahin melden alle Backups Erfolg und sind im Ernstfall trotzdem unerreichbar.

Hinweis: Die Regel „ein Bucket ausschließlich für den Catalog, ein separates für Anwendungen" ist eine Aussage aus dem IBM-Support, in der Dokumentation zu Fusion HCI 2.9.x aber nicht als harte Supportanforderung belegt. Technisch nachvollziehbar wegen der Trennung von Metadaten und Nutzdaten – lass sie dir für dein Design trotzdem im Ticket schriftlich geben.

Hub und Spoke bei mehreren Clustern

Ab dem zweiten Cluster stellt sich die Frage, wo Policies und Locations gepflegt werden. Fusion beantwortet sie mit einer festen Rollenverteilung: ein Hub verwaltet, beliebig viele Spokes führen aus.

Rollenverteilung

Hub – hält Scheduling, Retention, Policy-Handling und Location-Management. Von hier aus werden Policies auf Anwendungen beliebiger Cluster angewendet.
Spoke – trägt nur den Backup-&-Restore-Agent. Er nimmt Jobs entgegen und führt sie lokal aus. Fusion muss trotzdem installiert sein, nur eben in der Agent-Rolle.
Jobs-Seite – zeigt im Hub alle Backup- und Restore-Jobs über alle Cluster hinweg, filterbar pro Cluster.

Disponent und Fahrer – der Hub ist die Zentrale mit den Auftragszetteln, der Spoke der Fahrer vor Ort. Die Möbel fahren direkt vom Haus ins Lager, nicht über die Zentrale. Im Hub liegen nur die Papiere.

Was das für den Catalog bedeutet

Service Protection wird ausschließlich auf dem Hub konfiguriert. Die Backup-Informationen der Spokes sind dabei automatisch enthalten, auf den Spokes ist keine eigene Konfiguration nötig. Ein Catalog-Bucket für die gesamte Landschaft, nicht einer pro Cluster.

Nebeneffekt, den man selten bewusst einkauft: Die Architektur trennt die Workloads im Spoke so ab, dass sie die Backup-Locations nicht erreichen. Ein kompromittierter Spoke kommt nicht an die Backups. Das ist zugleich die sauberste Antwort auf die Frage, wie man Plattform-Nutzer von den Backup-Zielen fernhält.

Achtung: Service Protection über Hub und Spokes greift nur auf Remote-S3-Backups. Reine lokale Snapshot-Backups sind nicht unterstützt – sie tauchen nach einem Catalog-Restore schlicht nicht wieder auf, ohne dass vorher etwas fehlgeschlagen wäre.

Anbindung eines Spoke-Clusters

Die Verbindung wird über ein Connection Snippet aufgebaut, das auf dem Hub erzeugt und bei der Agent-Installation im Spoke eingetragen wird. Das Snippet ist eine Stunde gültig; daraus erzeugt der Hub über seine Certificate Authority ein dauerhaftes Zertifikat für die Verbindung. Netzunterbrechungen zwischen Hub und Spoke von bis zu einer Stunde übersteht die Kopplung.

Für die Agent-Installation wird eine StorageClass ausgewählt; der interne Datenkatalog braucht mindestens 200 GB ReadWriteOnce. Die YAML-Variante des Snippets ist für automatisierte Deployments gedacht, über die Oberfläche wird das Snippet direkt eingetragen.

Location, Policy, Assignment

Drei Objekttypen tragen die gesamte Konfiguration. Wer sie kennt, versteht auch, was im Catalog-Backup überhaupt drinsteckt – denn genau diese Objekte werden dort gesichert.

Die drei Bausteine

Objekt	Beantwortet	Wesentliche Angaben
BackupStorageLocation	Wohin wird gesichert?	Typ des Endpoints, Bucket-Name, Credentials, typabhängige Zusatzparameter
BackupPolicy	Wie oft und wie lange?	Frequenz, Retention, zugeordnete Location
BackupPolicyAssignment	Für welche Anwendung?	Verknüpfung von Policy und Anwendung – ohne Assignment läuft kein geplantes Backup

Zeitung abonnieren – die Location ist die Lieferadresse, die Policy das Abo mit Erscheinungsrhythmus und Aufbewahrungsdauer, das Assignment die Anmeldung für einen konkreten Haushalt. Ohne Anmeldung liegt das Abo nur in der Schublade.

Hinweis: Als Location-Typen stehen unter anderem Azure, IBM Cloud, S3-kompatibler Object Storage, AWS und Storage Protect zur Auswahl. Eine eigene UI-Kategorie namens „Service Protection Location" ist in der HCI-2.9.x-Doku nicht belegt – beim Service-Restore führt ein Assistent durch das Anlegen der Location. Prüfe die Bezeichnung an deiner installierten Version, statt sie aus einem Design-Dokument zu übernehmen.

Backup-CR als Beispiel

Backups lassen sich auch deklarativ anlegen. Interessant ist das Feld appCluster: Es benennt den Cluster, auf dem die Anwendung liegt, und ist nur für Anwendungen auf einem Spoke nötig. Fehlt es, geht Fusion von einer Anwendung auf dem Hub aus.

apiVersion: data-protection.isf.ibm.com/v1alpha1
kind: Backup
metadata:
  name: backup-app1-daily-20260810
  namespace: ibm-spectrum-fusion-ns
spec:
  appCluster: apps.spoke1.example.com
  application: app1
  backupPolicy: s3-daily

Diese Kommandos laufen ausschließlich vom Hub aus – auch dann, wenn die Backup-CR fachlich zu einem Spoke gehört.

Drei Use Cases aus der Praxis

Die Fälle, um die es in Design-Diskussionen tatsächlich geht – und welcher davon mit welchem Werkzeug bedient wird.

Fall 1 · Das Backup-Werkzeug ist kaputt

Nach einem Update funktioniert Backup & Restore nicht mehr. Die Anwendungsdaten liegen unverändert im Data-Bucket, aber die Verwaltung ist beschädigt. Die Reihenfolge ist zwingend: erst den Operator reparieren oder neu installieren, dann den Catalog wiederherstellen. Ein Catalog-Restore auf einen kaputten Operator läuft nicht durch.

Fall 2 · Ein System-Namespace ist beschädigt

Ein openshift-*- oder kube-*-Namespace wurde durch einen Konfigurationsfehler unbrauchbar. Fusion ist dafür nicht gebaut: Es sichert Anwendungen, nicht den Cluster. Sicherbar sind solche Namespaces zwar, ein vollständiger Restore scheitert aber an Objekten, die OpenShift nicht überschreiben lässt. Nutzbar bleibt das als Ersatzteillager für einzelne Ressourcen, etwa ein verlorenes Secret.

Fall 3 · Eine Anwendung soll zurück

Inkonsistenz, Admin-Fehler, fehlgeschlagenes Deployment. Der Standardfall: Wiederherstellung des kompletten Namespaces aus dem Data-Bucket. Genau dafür ist das Werkzeug gebaut, und hier verhält es sich wie erwartet.

Achtung: Der oft genannte vierte Fall – „ein OCP- oder Fusion-Upgrade zerstört den Cluster" – ist mit Fusion Backup & Restore nicht abgedeckt. Weder Control Plane noch etcd sind Bestandteil eines Fusion-Backups. Eine dokumentierte IBM-Empfehlung, ein fehlgeschlagenes Fusion-Upgrade per Service Protection zurückzurollen, existiert nicht.

Grenzen und das getrennte etcd-Backup

Fusion deckt die Anwendungsebene ab. Alles darunter braucht ein zweites, unabhängiges Verfahren nach Red-Hat-Vorgabe.

Umzug ist keine Sanierung – die Umzugsfirma trägt Möbel, sie repariert keine tragenden Wände. Für das Gebäude ist jemand anderes zuständig.

Was das etcd-Backup abdeckt – und was nicht

Vor jedem Cluster-Update verlangt Red Hat einen etcd-Snapshot. Das ist keine Empfehlung, sondern Voraussetzung für jede spätere Wiederherstellung.
Restore nur innerhalb derselben z-Stream-Version. Ein Snapshot aus einer anderen Minor-Version ist als Wiederherstellungspunkt nicht nutzbar.
Kein Versions-Rollback. Red Hat betrachtet den etcd-Restore bei einem katastrophal fehlgeschlagenen Update als letzten Ausweg, ausdrücklich nicht als unterstützten Weg zurück auf die Vorversion.

Für ein gescheitertes Minor-Upgrade bleibt damit nur der Neuaufbau des Clusters plus anschließende Wiederherstellung über Service Protection und Application Backups – der Ablauf aus Abschnitt 7.

Hinweis: Die Einschränkung, dass openshift-*-Namespaces nur teilweise wiederherstellbar sind, ist in der geprüften HCI-2.9.x-Doku nicht als Liste ausgeschlossener Ressourcen hinterlegt. Plausibel ist sie, belegt bislang nicht. Wer das im Konzept festschreibt, sollte es im Testcluster einmal praktisch nachweisen.

Achtung: Bei einem Service-Restore werden vorhandene Backup-&-Restore-Objekte durch den Stand des gewählten Service-Backups ersetzt. Auf einem laufenden Cluster mit aktiven Policies ist das kein harmloser Vorgang – seit dem Backup angelegte Policies und Assignments verschwinden dabei.

Zugriffsrechte und Self-Service

Plattform-Nutzer sollen Backups anstoßen können, ohne an die Locations oder an die darunterliegende Velero-Ebene zu kommen. Fusion liefert dafür einen Teil der Antwort, den Rest baust du selbst.

Was Fusion mitbringt

Für die eigenen Backup-&-Restore-CRs stehen je CR vier Rollen bereit: admin, crdview, edit und view. Sie werden über namespace-lokale RoleBindings an Anwender oder ServiceAccounts vergeben und lassen sich gezielt kombinieren – etwa Backup erlauben, Restore entziehen. Daneben gibt es die Rolle eines Backup-&-Restore-Administrators, der über die CRs arbeitet, ohne Zugriff auf die Fusion-Oberfläche zu haben.

Achtung: Ein Fusion-seitiges Modell, das den direkten Zugriff auf die darunterliegenden OADP-/Velero-CRDs aktiv sperrt, ist nicht dokumentiert. Wer nur die Fusion-Rollen vergibt, hat die Velero-APIs damit nicht abgeriegelt – das läuft über normales OpenShift-RBAC auf diese separaten APIs und muss eigens getestet werden.

Hinweis: Im Hub-Spoke-Betrieb löst sich ein Teil des Problems architektonisch: Workloads im Spoke erreichen die Backup-Locations ohnehin nicht. Die RBAC-Frage bleibt dann auf den Hub beschränkt.

Wiederherstellung auf einem neuen Cluster

Der komplette Ablauf in vier Phasen. Die erste Phase liegt vor dem Ernstfall – wer sie überspringt, kommt in Phase C nicht weiter.

Die vier Phasen auf einen Blick

Phase A · VorbereitenSchritte 1–4: Voraussetzungen, die im Normalbetrieb geschaffen werden müssen.
Phase B · Cluster bereitstellenSchritte 5–6: neuer oder gesunder OpenShift-Cluster mit Fusion.
Phase C · Verwaltung zurückholenSchritte 7–9: Backup & Restore installieren, Location anlegen, Service Recover.
Phase D · Anwendungen zurückholenSchritt 10: Restore je Anwendung aus den wiederhergestellten Backup-CRs.

Phase A · Vorbereiten

Schritt 1 · Service Protection einrichten und laufen lassen

Ohne ein aktuelles Catalog-Backup gibt es später nichts, worauf sich der Recover stützen kann. Im Hub-Spoke-Betrieb wird das ausschließlich auf dem Hub konfiguriert; die Spoke-Informationen sind automatisch enthalten.

Schritt 2 · Auf Remote-S3 prüfen

Anwendungen, die nur per lokalem Snapshot gesichert sind, tauchen nach dem Recover nicht wieder auf. Prüfe für jede geschützte Anwendung, ob ihre Policy auf eine S3-Location zeigt und nicht auf reine Snapshots.

Schritt 3 · Lokales S3 extern zusätzlich sichern

Liegt der Object Storage auf demselben Cluster, ist er im Totalausfall mit weg. Service Protection stellt Metadaten aus dem Cloud Storage wieder her – existiert dieser Storage nicht mehr, endet der Ablauf hier. Eine externe Kopie der S3-Daten ist in diesem Aufbau Pflicht, keine Kür.

Schritt 4 · Fusion-Namespace dokumentieren

Der Fusion-Namespace muss zwischen Sicherung und Wiederherstellung identisch sein. Weicht er auf dem Zielcluster ab, schlägt der Recover fehl – ein Detail, das im Runbook stehen muss und nicht im Kopf einer Person.

oc get spectrumfusion -A

Phase B · Cluster bereitstellen

Schritt 5 · Neuen oder gesunden OpenShift-Cluster bereitstellen

Der Zielcluster kann ein frisch installierter oder ein bereits vorhandener gesunder Cluster sein. Er ist die Voraussetzung für alles Weitere – ein Recover in einen defekten Cluster hinein ist kein vorgesehener Weg.

Schritt 6 · IBM Fusion installieren

Fusion muss stehen, bevor der Backup-&-Restore-Service installiert werden kann. Achte auf denselben Namespace wie auf dem Quellcluster (Schritt 4).

Phase C · Verwaltung zurückholen

Schritt 7 · Backup & Restore installieren

Der Recover setzt einen funktionsfähigen Backup-&-Restore-Service voraus. Das ist derselbe Punkt, an dem Fall 1 aus Abschnitt 4 hängt: Erst das Werkzeug, dann der Catalog. Andersherum läuft nichts.

Schritt 8 · Location auf den Catalog-Bucket anlegen

Der neue Cluster kennt den Catalog-Bucket noch nicht – die Location-Definition lag ja selbst im Catalog. Sie wird daher beim Service-Restore über einen Assistenten neu angelegt, mit Endpoint, Bucket und Credentials des Catalog-Buckets.

Schritt 9 · Service Recover ausführen

Der Recover stellt Locations, Policies, Policy Assignments und die Backup-CRs wieder her. Danach kennt der Cluster wieder alle vorhandenen Backups – wiederhergestellt ist damit die Verwaltung, noch keine einzige Anwendung.

# Nach dem Recover: sind die Backup-CRs wieder da?
oc -n <fusion-namespace> get backups.data-protection.isf.ibm.com

Phase D · Anwendungen zurückholen

Schritt 10 · Restore je Anwendung

Erst jetzt werden die eigentlichen Daten geholt: Anwendung für Anwendung aus den wiederhergestellten Backup-CRs, jeweils mit Auswahl des Zielclusters. Das ist der Punkt, an dem der Data-Bucket wieder gebraucht wird – bis hierhin lief alles über den Catalog.

Hinweis: Der Ablauf baut die Backup-Verwaltung plus anschließende Anwendungs-Wiederherstellung auf. Er klont keinen Cluster und stellt keine Control Plane wieder her – Cluster-Konfiguration, Operatoren und Netzwerkeinstellungen des Zielclusters bleiben deine Aufgabe.