NetBackup-MongoDB-Fehler 6601, 6625, 6654

Die NetBackup-MongoDB-Fehler 6601, 6625 und 6654 sollten nicht als ein einziger, generischer Datenbankfehler behandelt werden. Aktuelle Fälle aus der Praxis zeigen, dass sich der Fehler verschiebt, wenn sich Anmeldedaten und Host-Konfiguration ändern, während die Veritas-Dokumentation zeigt, dass MongoDB-Authentifizierung, Host-Authentifizierung, Benennung, RSA-Schlüssel, Backup-Hosts und Policy-Konfiguration getrennte Ebenen sind.

Die praktische Faustregel bei der Fehlersuche lautet, zuerst zu ermitteln, welche Ebene fehlgeschlagen ist, bevor eine andere geändert wird. Ein Administrator sah Status 6625 verschwinden, nachdem die mit tpconfig verwendeten Host-Anmeldedaten geändert wurden, blieb dann aber weiterhin durch Status 6601 blockiert. Ein anderer sah Status 6654, „Unable to retrieve credentials", selbst nachdem die MongoDB-Sicherheit deaktiviert und No Authentication gewählt worden war. Diese Details sind Hinweise, kein Beleg für eine einzige gemeinsame Ursache.

Warum kann Status 6654 auch bei MongoDB No Authentication auftreten?

Status 6654 kann weiterhin ein Credential-Problem sein, denn der No-Authentication-Modus von NetBackup bedeutet nicht „keine Anmeldedaten irgendwo". Veritas dokumentiert für den NOAUTH-Fall eine Credential-Datei, die für den MongoDB-Knoten weiterhin HostUser, HostPassword und HostRsaKey enthält.

Diese Unterscheidung erklärt, warum das Abschalten der MongoDB-Authentifizierung den Fehler möglicherweise nicht verändert. Datenbank-Authentifizierung und Host-Zugriff sind zwei verschiedene Dinge. NetBackup braucht weiterhin einen vertrauenswürdigen Weg, um den MongoDB-Host zu erreichen und darauf zu arbeiten. Fehlt diese Host-Identität, stimmt sie nicht überein oder ist sie unter einem anderen Hostnamen gespeichert als von der Policy erwartet, kann die Datenbank vollständig offen sein und das Backup trotzdem fehlschlagen.

Veritas dokumentiert außerdem einen konkreten Fall von Status 6654, der durch uneinheitliche Host-Benennung verursacht wurde. Die Anmeldedaten waren unter einer Form des Hostnamens gespeichert, während Policy oder Konfiguration eine andere verwendeten. Ein Kurzname an der einen Stelle und ein FQDN an der anderen reichten aus, um den Abruf der Anmeldedaten zu verhindern.

Die erste Prüfung bei 6654 ist deshalb unspektakulär, aber wertvoll: Notieren Sie sich die exakten Host-Strings, die in tpconfig, in der Backup-Policy, in der NetBackup-Identität des Clients und in mongodb.conf verwendet werden. Sie sollten alle konsistent denselben Knoten beschreiben.

Was sollte zuerst in tpconfig geprüft werden?

Der tpconfig-Eintrag sollte auf den richtigen Application Server, den Authentifizierungstyp, den Host User, den RSA-Schlüssel und das exakte Hostname-Format geprüft werden. Veritas gibt an, dass die Anmeldedaten des MongoDB-Knotens für den Application Server hinzugefügt werden, der im Reiter „Clients" der Backup-Policy angegeben ist.

Bei einem Replica Set oder einem Standalone-Deployment legt die Credential-Konfiguration den Hostnamen und Port von mongod fest. Ein Sharded Cluster kann mehrere mongod- und mongos-Endpunkte enthalten. Wenn die Policy einen Namen angibt, die Anmeldedaten aber einem anderen zugeordnet sind, kann NetBackup an der falschen Stelle suchen, selbst wenn beide Namen per DNS auflösbar sind.

Auch der Host User spielt eine Rolle. Die aktuelle Veritas-Anleitung für Cluster, die unter einem mongod-Service-Account laufen, rät davon ab, diesen mongod-Service-Account selbst als Host User in tpconfig zu verwenden. Empfohlen wird ein sudofähiges Non-Root-Host-Konto mit eigenem Home-Verzeichnis und Besitzrechten an den in mongodb.conf referenzierten Verzeichnissen.

Das macht die Beobachtung „root hat einen Fehler behoben" aus dem Administratorfall nachvollziehbar, ohne root zu einer Empfehlung zu machen. Root hat möglicherweise ein Berechtigungshindernis beseitigt, wodurch Status 6625 verschwand. Die sicherere langfristige Aufgabe besteht darin, zu ermitteln, welche Berechtigung dem vorgesehenen Host-Konto fehlt, und das unterstützte Non-Root-Modell korrekt zu konfigurieren.

Was sagen Status 6601 und 6625 im geschilderten Fall aus?

Dass Status 6625 im geschilderten Fall nach einer Änderung der Anmeldedaten verschwand, zeigt, dass die Konfigurationsänderung den Fehlerpfad beeinflusst hat. Es belegt nicht, dass jedes Auftreten von Status 6625 durch dasselbe Berechtigungsproblem verursacht wird, und die Diskussion lieferte nicht genug Belege, um die eigentliche Ursache von Status 6601 zu bestimmen.

Genau deshalb sollte die Fehlersuche jedes Testergebnis festhalten. Notieren Sie den ursprünglichen Fehler, ändern Sie eine Variable, führen Sie dasselbe Backup erneut aus und prüfen Sie, ob sich der Status ändert. Wird aus 6625 ein 6601, ist das System weit genug gekommen, um auf eine andere Bedingung zu stoßen. Werden mehrere Konfigurationsänderungen gleichzeitig vorgenommen, geht dieser Beleg verloren.

Zu den sinnvollen Prüfungen gehören die exakten NetBackup- und MongoDB-Versionen, die MongoDB-Topologie, der gewählte Policy-Typ, der Backup-Host, der Deployment-Status des Plug-ins, mongodb.conf, der Credential-Eintrag, der Host-RSA-Schlüssel, die Konsistenz der Hostnamen sowie die Berechtigungen für jedes Verzeichnis, das NetBackup benötigt.

Läuft MongoDB in einer virtuellen Maschine, halten Sie das Anwendungsproblem von der Maschinen-Absicherung getrennt. Der Proxmox-Backup-Vergleich veranschaulicht den größeren Unterschied zwischen dem Schutz einer VM als Objekt und dem Schutz des Anwendungszustands darin. Ein VM-Wiederherstellungspunkt beantwortet nicht jede Frage zur Datenbank-Wiederherstellung.

Muss der NetBackup-Client auf dem MongoDB-Server installiert sein?

Ein NetBackup-Client ist nicht automatisch auf jedem MongoDB-Knoten erforderlich, nur weil ein Backup fehlschlägt. Die richtige Architektur hängt vom MongoDB-Plug-in-Workflow und der NetBackup-Version ab, einschließlich der Frage, welches System als Backup-Host fungiert.

Die Veritas-Dokumentation beschreibt einen NetBackup-Client ausdrücklich als möglichen Backup-Host. Wird ein Client in dieser Rolle eingesetzt, muss er über die Konfiguration APP_PROXY_SERVER in die Allowed List des Primary Servers aufgenommen werden. Das ist etwas anderes, als zu sagen: „Installieren Sie den Client überall."

Diese Unterscheidung ist wichtig, weil das Installieren zusätzlicher Software auf dem Datenbankserver den Eindruck von Fortschritt erwecken kann, während der eigentliche Konfigurationsfehler unangetastet bleibt. Bevor Sie einen weiteren Client installieren, zeichnen Sie den unterstützten Ablauf auf: Primary Server, Backup-Host, MongoDB-Knoten, Plug-in, Anmeldedaten, Policy und Datenpfad. Prüfen Sie dann, welche Komponente für das jeweilige NetBackup-Release auf welche Maschine gehört.

Dasselbe Denken in Wiederherstellungsebenen findet sich im Proxmox-Backup-Server-Leitfaden. Host-Schutz und anwendungsbewusste Wiederherstellung lösen verwandte Probleme, sind aber nicht austauschbar.

Wie sollten Hostname-Abweichungen getestet werden?

Hostname-Abweichungen sollten durch den Vergleich der buchstäblichen Strings getestet werden, nicht dadurch, dass DNS-Auflösung funktioniert. Auflösung beweist nur, dass ein Name irgendwohin zeigt. Der Credential-Lookup von NetBackup kann weiterhin von dem Identitäts-String abhängen, der beim Speichern der Anmeldedaten verwendet wurde.

Beginnen Sie mit dem Wert des Application Server in der Policy. Vergleichen Sie ihn mit dem in tpconfig verwendeten Hostnamen. Vergleichen Sie beide mit dem Clientnamen und jedem Hostnamen in mongodb.conf. Ist der FQDN der Standard in der Umgebung, verwenden Sie ihn durchgängig. Erwartet ein dokumentierter Workflow einen Kurznamen, verwenden Sie stattdessen durchgängig diesen.

Prüfen Sie anschließend die Forward- und Reverse-Auflösung von den am Backup beteiligten Systemen aus. Kontrollieren Sie, dass keine doppelten Aliase auf unterschiedliche Schnittstellen zeigen oder veraltete Einträge vorhanden sind. Wurde der Knoten umbenannt, stellen Sie sicher, dass die NetBackup-Konfiguration aktualisiert wurde, statt sich darauf zu verlassen, dass DNS-Aliase den Unterschied verdecken.

Das ist einer jener Fehler, bei denen „das Netzwerk funktioniert" wahr sein kann und das Backup trotzdem falsch läuft.

Was ist die sicherste Reihenfolge bei der Fehlersuche?

Die sicherste Reihenfolge ist: zuerst die Identität, dann die Plug-in-Platzierung, dann Policy- und Anwendungskonfiguration, dann die Datenbewegung. Bestätigen Sie unterstützte Versionen und Topologie. Bestätigen Sie die exakten MongoDB-Knoten. Bestätigen Sie die Hostnamen. Bestätigen Sie die Anmeldedaten und RSA-Schlüssel in tpconfig. Bestätigen Sie, dass der Host User die dokumentierten Anforderungen erfüllt. Bestätigen Sie die Pfade und Besitzrechte in mongodb.conf. Bestätigen Sie, dass der gewählte Backup-Host vom Primary Server zugelassen ist. Erst danach weiten Sie die Suche auf Netzwerk-, Storage- und Anwendungsverhalten aus.

Deaktivieren Sie MongoDB-Sicherheit nicht als ersten Schritt der Fehlersuche. Der Fall von Status 6654 zeigt, warum das Zeit kosten kann. NOAUTH lässt die NetBackup-Host-Anmeldedaten weiterhin im Pfad bestehen, und das Entfernen der Datenbank-Authentifizierung schafft lediglich einen neuen Sicherheitszustand, ohne irgendetwas über die Host-Identität zu beweisen, die NetBackup abzurufen versucht.

Ich würde außerdem davon absehen, root als dauerhaften Workaround beizubehalten, nur weil ein Fehlercode verschwindet. Nutzen Sie das als Beleg dafür, dass Berechtigungen eine Rolle spielen, und bewegen Sie sich dann in Richtung des am wenigsten privilegierten Host-Kontos, das die NetBackup-MongoDB-Anleitung unterstützt.

Das Ziel ist nicht, einen Job mit allen verfügbaren Mitteln grün werden zu lassen. Das Ziel ist zu verstehen, welche Identität, welchen Host und welche Konfiguration NetBackup verwendet, damit die Lösung vorhersehbar bleibt, wenn der nächste Knoten, das nächste Replica Set oder die nächste Wiederherstellung hinzukommt.