IBM Fusion 2.12.x – Backup-Ausfall trotz erreichbarem S3-Ziel

Überblick: Was „Connected“ wirklich prüft

In einer Kubernetes-basierten Backup-Umgebung entstanden keine neuen Backups mehr, obwohl die konfigurierte S3-kompatible Backup Location weiterhin als Connected geführt wurde. Der naheliegende Verdacht – ein Problem am Object-Storage-Ziel – erwies sich als falsche Fährte.

Die Fehlerkette in Kürze

Object Storage erreichbarDie Backup Location meldet Connected – geprüft wird hier ausschließlich die Erreichbarkeit des S3-Ziels.
Keine Policy zugeordnetDer Location fehlen aktive Backup Policies und zugeordnete Anwendungen, es laufen keine Backup-Jobs.
Interner Service nicht bereitDer zuständige Backend-Pod besteht seine Readiness Probe nicht.
Datenbank nicht erreichbarDer Service findet keinen nutzbaren MongoDB-Primary.
MongoDB-CA abgelaufenDas selbstsignierte CA-Zertifikat (mongoCA) des Replica-Sets ist ausgelaufen – die eigentliche Ursache.

Komponenten und ihre Beziehungen

Zwei Stränge, die sich unten treffen: links der unauffällige Pfad (S3 erreichbar, Location Connected), rechts die eigentliche Fehlerkette vom Zertifikat bis zum Policy Assignment.

„Connected“ ist wie der Empfangsbalken am Handy – er zeigt, dass die Antenne Kontakt hat, nicht, dass die App im Hintergrund noch läuft.

Symptom: Policy Assignment bleibt FailedCreating

Die Backup Location war verbunden, ihr aber waren keine aktiven Backup Policies und keine Anwendungen mehr zugeordnet. Grund dafür war ein fehlgeschlagenes Policy Assignment.

Wichtig: Der Status Connected einer Backup Location bewertet die Erreichbarkeit und grundlegende Validierung des Object-Storage-Ziels. Er ist kein End-to-End-Gesundheitsnachweis für den gesamten Backup-Prozess.

Trennung von Location, Policy und Assignment

Eine Backup Location allein reicht nicht aus: Erst die Zuordnung einer Backup Policy zu einer Anwendung – das Policy Assignment – startet die regelmäßige Sicherung in das konfigurierte Ziel. Location, Policy und Assignment sind logisch getrennte Objekte.

Beim Anwenden der Policy trat ein Timeout gegen einen internen Backup-Policy-Service auf:

// Policy Assignment · Status FailedCreating
POST https://backuppolicy-service.<namespace>.svc.cluster.local:9443/...
context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Hub-and-Spoke: S3 Remote Object Storage dient in diesem Modell als Backup-Ziel für clusterübergreifende Wiederherstellung. Policies werden vom Hub aus auf Anwendungen in Spoke-Clustern angewendet – auch dieser Mechanismus hängt am funktionierenden Policy-Service.

Backend-Pod: Readiness Probe schlägt fehl

Die Untersuchung des zugehörigen Backend-Pods zeigte, warum der Policy-Service Anfragen nicht verarbeiten konnte: Er galt nicht als bereit.

Health-Endpunkt antwortet nicht rechtzeitig

// Readiness Probe
Readiness probe failed:
.../health/ready:
net/http: request canceled
(Client.Timeout exceeded while awaiting headers)

Der Pod wurde dadurch nicht als bereit eingestuft. Der interne Service konnte keine Backup Policies zuverlässig verarbeiten und das Policy Assignment nicht erfolgreich erstellen.

Wichtig: Die Ursache lag nicht beim S3-Ziel selbst, sondern in einer internen Abhängigkeit des Backup-Policy-Service. Eine grüne Storage-Verbindung sagt nichts darüber aus, ob die Komponenten dahinter gesund sind.

Datenbankzugriff: MongoDB-Timeout

Die Service-Logs erklärten, warum der Health-Check nicht abgeschlossen werden konnte: eine gestörte MongoDB-Verbindung.

Kein nutzbarer Primary

// Backup-Policy-Service · Log
com.mongodb.MongoTimeoutException:
Timed out after 30000 ms while waiting for a server that matches
ReadPreferenceServerSelector{readPreference=primary}

Der Backup-Policy-Service erwartete einen erreichbaren MongoDB-Primary. Da keiner verfügbar war, schlug der Datenbankzugriff fehl und der Health-Check konnte nicht erfolgreich abgeschlossen werden.

Was „kein nutzbarer Primary" konkret heißt: nicht zwingend, dass alle MongoDB-Pods beendet sind. Der anfragende Service fand innerhalb seines Timeouts keinen Knoten, der gleichzeitig erreichbar ist, als PRIMARY fungiert, per TLS mit gültiger Vertrauenskette ansprechbar ist und vom Treiber für readPreference=primary akzeptiert wird.

Ursache: Abgelaufene MongoDB-CA (mongoCA)

Die MongoDB-Logs lieferten den ersten Hinweis auf die zugrunde liegende Ursache – die anschließende Zertifikatsprüfung bestätigte sie konkret.

TLS-Validierung zwischen Replica-Set-Mitgliedern schlägt fehl

// MongoDB · Log
SSL peer certificate validation failed: certificate has expired

Das Log zeigt zunächst nur eine fehlgeschlagene TLS-Peer-Validierung. Die anschließende Zertifikatsprüfung bestätigte: abgelaufen war nicht irgendein Server- oder Peer-Zertifikat, sondern das selbstsignierte MongoDB-CA-Zertifikat (mongoCA) selbst – die Vertrauensbasis für die gesamte TLS-Kommunikation zwischen den Replica-Set-Mitgliedern. War die CA nicht mehr gültig, konnten die Peers die Zertifikatsketten ihrer Kommunikationspartner nicht mehr validieren. Betroffen war damit nicht ein einzelnes Zertifikat, sondern die komplette Vertrauenskette des Replica-Sets.

Zertifikatsprüfung: die tatsächliche CA identifizieren

Die naheliegende Prüfung eines einzelnen Peer-Zertifikats reicht nicht aus, um die CA selbst zu bestätigen. Zwei Schritte dafür:

Schritt A · Vorhandene Keys im TLS-Secret ermitteln

oc -n ibm-backup-restore get secret certificates-tls-secret -o json | jq -r '.data | keys[]'

Achtung: Nur die Namen der Secret-Datenfelder ausgeben. Die Inhalte selbst dürfen nicht in Tickets, Chats oder unverschlüsselte Dokumente kopiert werden.

Schritt B · Die tatsächliche MongoDB-CA prüfen

Platzhalter <mongo-ca-key> durch den in Schritt A bestätigten Key-Namen ersetzen, zum Beispiel mongoCA.pem, falls dieser im Secret vorhanden ist.

oc -n ibm-backup-restore get secret certificates-tls-secret \
  -o jsonpath='{.data.<mongo-ca-key>}' \
  | base64 -d \
  | openssl x509 -noout -subject -issuer -serial -dates -text \
  | grep -E 'Subject:|Issuer:|Serial Number:|Not Before:|Not After :|CA:TRUE'

Erwartete Prüfungsergebnisse vor der Korrektur:

Not After liegt vor dem aktuellen Datum
das Zertifikat ist als CA gekennzeichnet, z. B. mit CA:TRUE
Subject und Issuer passen zur erwarteten internen MongoDB-PKI

Zusätzlich: Leaf-/Peer-Zertifikat prüfen

oc -n ibm-backup-restore get secret certificates-tls-secret \
  -o jsonpath='{.data.mongodb-0-guardian\.pem}' \
  | base64 -d \
  | openssl x509 -noout -subject -issuer -serial -dates

Diese Abfrage prüft ein MongoDB-Peer-/Leaf-Zertifikat. Sie ersetzt nicht die Prüfung des mongoCA-Zertifikats aus Schritt B.

Eine CA ist wie ein Ausweisamt. Läuft ihr eigenes Siegel ab, werden auf einen Schlag alle davon ausgestellten Ausweise wertlos – selbst wenn die einzelnen Ausweise selbst noch taufrisch sind.

Fehlerkette im Überblick & weiterführende Diagnose

Elf Ursache-Wirkungs-Schritte zwischen der abgelaufenen CA und ausbleibenden Backups.

Kurzfazit

Die Ursache für die ausbleibenden Backups war nicht die Erreichbarkeit des Object-Storage-Ziels – die Backup Location konnte weiterhin als Connected validiert werden. Der Ausfall wurde durch ein abgelaufenes selbstsigniertes MongoDB-CA-Zertifikat (mongoCA) verursacht. Dadurch konnten die Replica-Set-Mitglieder ihre TLS-Verbindungen nicht mehr validieren, der Backup-Policy-Service erreichte keinen nutzbaren Primary, wurde nicht Ready und konnte Backup Policies nicht mehr anwenden. Das Policy Assignment verblieb dadurch im Status FailedCreating, sodass keine neuen Backups entstanden.

Von der Ursache zur Wirkung

Abgelaufene MongoDB-CA (mongoCA)Selbstsigniertes CA-Zertifikat des Replica-Sets läuft ab.
Zertifikatsketten nicht mehr validierbarReplica-Set-Peers können die Ketten ihrer Kommunikationspartner nicht mehr prüfen.
TLS-Verbindungen schlagen fehl oder werden instabilZwischen den Replica-Set-Mitgliedern.
Replica-Set-Kommunikation beeinträchtigtAuch die Mehrheitsbildung (Election) ist betroffen.
Kein stabil nutzbarer MongoDB-PrimaryFür Clients nicht erreichbar.
Backup-Policy-Service läuft in einen MongoDB-TimeoutMongoTimeoutException bei readPreference=primary.
Readiness Probe schlägt fehlDer Health-Endpunkt /health/ready antwortet nicht rechtzeitig.
Backup-Policy-Service ist NotReadyLiefert 503 bzw. context deadline exceeded.
Policy Assignment bleibt FailedCreatingDie Zuordnung von Policy zu Anwendung kann nicht abgeschlossen werden.
Backup Policy wird nicht angewendetDer Location fehlen aktive Policies und Anwendungen.
Keine neuen Backups werden erstelltTrotz Connected-Status der Backup Location.

Was „Connected“ bestätigt

Der konfigurierte Object-Storage-Endpunkt ist erreichbar
Der Bucket kann im Rahmen der Location-Validierung angesprochen werden
Die Location-Konfiguration ist grundsätzlich verwendbar

Was „Connected“ nicht bestätigt

eine Backup Policy wurde erfolgreich angewendet
eine Anwendung ist aktiv einer Policy zugeordnet
das Policy Assignment ist erfolgreich
der interne Backup-Policy-Service ist bereit
MongoDB und weitere Backend-Abhängigkeiten sind gesund
neue Backup-Jobs werden erstellt oder abgeschlossen

Weiterführende Diagnose

Für die weitere Untersuchung empfiehlt IBM, gezielt Backup-&-Restore-Logs zu erfassen. Das Log-Paket enthält primär Ressourcen des Namespace ibm-backup-restore; in Hub-and-Spoke-Umgebungen lassen sich zusätzlich gezielt Logs einzelner Spoke-Cluster auswählen.

Weiterführende Referenzen

IBM Fusion

MongoDB

Behebung: MongoDB-CA regenerieren

Die abgelaufene MongoDB-CA wird durch Neuerzeugung der GuardianMongo-Custom-Resource regeneriert.

Vor Beginn: Support-Paket sammeln und die in Schritt 3–4 exportierten YAML-Dateien sichern. Die Prozedur in einem geplanten Wartungsfenster durchführen – sie verursacht eine vorübergehende Unterbrechung des Backup-&-Restore-Service auf dem Spoke-Cluster.

Eine PKI-Regeneration muss konsistent sein

Bei einer abgelaufenen mongoCA genügt es nicht, nur ein einzelnes Server- oder Peer-Zertifikat auszutauschen. CA, davon abhängige Leaf-/Peer-Zertifikate und die Trust-Referenzen aller Replica-Set-Mitglieder müssen zueinander passen. Deshalb setzt die Prozedur an der GuardianMongo-CR an, die die gesamte PKI verwaltet, statt an einem einzelnen Zertifikat.

Neue mongoCA
  + gültige MongoDB-Server-/Peer-Zertifikate
  + korrekte Signaturkette
  + aktualisierte Trust-Referenzen bei allen Replica-Set-Mitgliedern
  + kontrollierter Neustart der betroffenen MongoDB-Workloads
  = wieder funktionierende TLS-Kommunikation im Replica Set

Die vier Phasen auf einen Blick

Phase A · Vorbereiten & sichernSchritt 0–4: Support-Paket sammeln, sicheren Arbeitsordner anlegen, Ablauf der CA bestätigen, GuardianMongo-CR und MongoDB-Secret exportieren.
Phase B · CR neu erzeugenSchritt 5–6: GuardianMongo-CR löschen und neu anlegen – das stößt die PKI-Regeneration an.
Phase C · Original-Secret wiederherstellenSchritt 7–9: neu generiertes MongoDB-Secret verwerfen, Original-Secret zurückspielen, StatefulSet neu starten.
Phase D · ValidierenSchritt 10–14: neue CA, StatefulSet/Pods, Replica-Set-Status, Backup-Policy-Service und Policy Assignment prüfen.

Phase A · Vorbereiten & sichern

Schritt 0 · Backup-&-Restore-Logs sammeln (empfohlen)

Vor jeder Änderung den aktuellen Zustand über Logs, Events und Ressourcenstatus dokumentieren – nützlich für die Fehlersuche und als Rollback-Grundlage, falls die Prozedur unerwartet verläuft. Über die Fusion-UI: Support → Log Collection → neue Anfrage anlegen → betroffenen Spoke-Cluster auswählen → Backup-&-Restore-Komponenten einschließen → Paket herunterladen und sicher ablegen.

Wichtig: Erst mit der Zertifikatsregeneration fortfahren, wenn das Log-Paket erfolgreich heruntergeladen und gesichert ist.

Schritt 1 · Sicheren Arbeitsordner anlegen

Alle Exporte dieser Prozedur landen in einem eigenen, geschützten Ordner statt in /tmp – die Dateien können sensible Konfiguration enthalten.

mkdir -p ~/ibm-fusion-mongodb-cert-rotation
chmod 700 ~/ibm-fusion-mongodb-cert-rotation

Schritt 2 · Ablauf und Fingerprint der CA bestätigen

Die Zertifikatsprüfung aus Abschnitt 4 (Schritt A/B) hier wiederholen und zusätzlich Seriennummer sowie SHA-256-Fingerprint notieren – als Vergleichswert für die Validierung nach der Regeneration.

oc -n ibm-backup-restore get secret certificates-tls-secret \
  -o jsonpath='{.data.<mongo-ca-key>}' \
  | base64 -d \
  | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

Schritt 3 · GuardianMongo-CR exportieren

Sichert den aktuellen Zustand der Custom Resource, bevor sie gelöscht wird.

oc -n ibm-backup-restore get guardianmongo guardianmongo \
  -o yaml > ~/ibm-fusion-mongodb-cert-rotation/guardianmongo-before.yaml

Schritt 4 · MongoDB-Secret exportieren

Sichert das bestehende MongoDB-Secret als Rollback-Grundlage.

oc -n ibm-backup-restore get secret mongodb \
  -o yaml > ~/ibm-fusion-mongodb-cert-rotation/mongodb-secret-before.yaml

Achtung: Erst weitermachen, wenn beide Dateien (guardianmongo-before.yaml, mongodb-secret-before.yaml) gesichert sind – sie werden für das Rollback in Phase C benötigt. Keine Backup-, Restore-, Policy- oder Service-Änderungen parallel zu dieser Prozedur durchführen.

Phase B · CR neu erzeugen

Schritt 5 · GuardianMongo-CR löschen

Entfernt die Custom Resource, die den fehlerhaften CA-Zustand referenziert. Keine Secrets oder Zertifikate ohne bestätigte Owner- bzw. Controller-Beziehung blind löschen – hier ist die Beziehung über die CR eindeutig.

oc delete GuardianMongo/guardianmongo -n ibm-backup-restore

Schritt 6 · GuardianMongo-CR neu erzeugen

Entweder den zuvor exportierten Stand erneut anwenden:

oc apply -n ibm-backup-restore -f ~/ibm-fusion-mongodb-cert-rotation/guardianmongo-before.yaml

oder die CR manuell mit den Werten aus dem Original-YAML neu anlegen:

apiVersion: fusion.guardian.ibm.com/v1
kind: GuardianMongo
metadata:
  name: guardianmongo
  namespace: ibm-backup-restore
spec:
  mongoname: mongodb
  mongonamespace: ibm-backup-restore
  mongostate: Installed
  mongostorageclassname: <storage-class-from-original-yaml>
  mongousage: Full

Etwa 2–3 Minuten warten – das löst die Regeneration von certificates-tls-secret (neue CA plus neue Leaf-/Peer-Zertifikate und Trust-Referenzen) und die Neuanlage eines mongodb-Secrets aus. Danach prüfen, ob beide Ressourcen entstanden sind:

oc get secret certificates-tls-secret -n ibm-backup-restore
oc get secret mongodb -n ibm-backup-restore

Phase C · Original-Secret wiederherstellen

Schritt 7 · neu generiertes MongoDB-Secret löschen

Das frisch erzeugte mongodb-Secret weicht vom ursprünglichen ab und wird durch das gesicherte Original ersetzt.

oc delete secret/mongodb -n ibm-backup-restore

Schritt 8 · Original-MongoDB-Secret wiederherstellen

Spielt das in Schritt 4 gesicherte mongodb-Secret zurück.

oc apply -n ibm-backup-restore -f ~/ibm-fusion-mongodb-cert-rotation/mongodb-secret-before.yaml

Wichtig: Nur das mongodb-Secret wird wiederhergestellt. Das alte certificates-tls-secret darf nicht zurückgespielt werden – es enthält die abgelaufene mongoCA. Ein Rollback dieses Secrets würde die abgelaufene Vertrauenskette erneut aktivieren und den ursprünglichen Fehler reproduzieren.

Schritt 9 · MongoDB-StatefulSet neu starten

Damit alle Replica-Set-Mitglieder die neue CA, die neuen Zertifikate und das wiederhergestellte Secret übernehmen, wird das StatefulSet komplett neu gestartet.

oc scale statefulset/mongodb --replicas=0 -n ibm-backup-restore

Prüfen, dass alle MongoDB-Pods beendet sind:

oc get pods -n ibm-backup-restore | grep mongo

StatefulSet wieder auf 3 Replicas hochskalieren:

oc scale statefulset/mongodb --replicas=3 -n ibm-backup-restore

Ein paar Minuten warten und prüfen, ob die Backup-&-Restore-Services wieder zu MongoDB verbinden können. Vor einem vollständigen Neustart sicherstellen, dass das Wartungsfenster dafür ausreichend lang bemessen ist.

Phase D · Validieren

Nach einer erfolgreichen Regeneration müssen alle Ebenen der Fehlerkette geprüft werden, nicht nur das Zertifikat selbst.

Schritt 10 · Neue CA prüfen

oc -n ibm-backup-restore get secret certificates-tls-secret \
  -o jsonpath='{.data.<mongo-ca-key>}' \
  | base64 -d \
  | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

Erwartete Ergebnisse:

Not After liegt deutlich in der Zukunft
Seriennummer und/oder SHA-256-Fingerprint unterscheiden sich vom in Schritt 2 notierten alten Wert
das Zertifikat ist weiterhin als CA markiert
die Leaf-/Peer-Zertifikate sind über eine gültige Vertrauenskette prüfbar

Schritt 11 · StatefulSet und Pods prüfen

oc -n ibm-backup-restore get statefulset mongodb -o wide
oc -n ibm-backup-restore get pods -o wide | grep -i mongo

Schritt 12 · Replica-Set-Status prüfen

Falls mongosh im MongoDB-Pod verfügbar ist:

oc -n ibm-backup-restore exec -it mongodb-ab-0 -- mongosh --eval \
  'rs.status().members.map(m => ({name: m.name, state: m.stateStr, health: m.health, self: m.self}))'

Erwartung: genau ein Mitglied ist PRIMARY, die übrigen sind SECONDARY, alle verfügbaren Mitglieder zeigen health: 1.

Hinweis: mongodb-ab-0 ist nicht automatisch der Primary. Die Rolle muss über rs.status() bzw. db.hello() geprüft werden.

Schritt 13 · Backup-Policy-Service prüfen

oc -n ibm-backup-restore get deployment backuppolicy-deployment -o wide
oc -n ibm-backup-restore get pods -o wide | grep -i backuppolicy
oc -n ibm-backup-restore get endpoints backuppolicy-service -o wide

Erwartung: der backuppolicy-Pod ist Running und Ready, der Health-Endpunkt /health/ready schlägt nicht mehr fehl, der Service besitzt mindestens einen Ready Endpoint, keine neuen HTTP-503- oder context deadline exceeded-Fehler.

Schritt 14 · Policy Assignment und End-to-End-Funktion prüfen

oc -n ibm-spectrum-fusion-ns get policyassignment
oc -n ibm-spectrum-fusion-ns describe policyassignment <policyassignment-name>

Erwartung: Das Policy Assignment verbleibt nicht in FailedCreating, die Policy wird wieder erfolgreich der Anwendung zugeordnet, neue Backup-Jobs werden erzeugt, die Backup Location zeigt wieder aktive Policies und Anwendungen, und neue Backupdaten werden in das konfigurierte Object-Storage-Ziel geschrieben.