NetBackup SAN Transport schlägt bei NVMe over FC fehl

Dass ein RHEL-Medienserver einen NVMe-over-Fibre-Channel-Datastore sehen kann, beweist noch nicht, dass NetBackup SAN Transport über diesen Pfad VMware-Snapshot-Disks öffnen kann. In einer gemeldeten NetBackup-10.2.1-Umgebung war der Storage für RHEL 9.8 sichtbar, aber SAN Transport schlug trotzdem mit „cannot open snapshot" fehl — ein Hinweis auf ein Kompatibilitäts- oder Datenpfadproblem, das Schicht für Schicht eingegrenzt werden muss.

Das Setup war spezifisch: HPE-Gen11-Server, für NVMe over FC konfigurierte QLogic-HBAs, Dell-PowerStore-Storage, vSphere 8 und über NVMe FC präsentierte VMFS-Datastores. Diese Spezifität ist wichtig. „Fibre Channel funktioniert" ist eine zu pauschale Schlussfolgerung, wenn das über das Fabric präsentierte Protokoll NVMe statt klassisches SCSI ist.

Warum beweist die Sichtbarkeit des Datastores nicht, dass SAN Transport funktioniert?

Die Sichtbarkeit des Datastores beweist nur, dass das Betriebssystem und sein NVMe-FC-Stack die Storage-Präsentation erkennen und darauf zugreifen können. NetBackup VMware SAN Transport fügt zu dieser grundlegenden Sichtbarkeit noch VMware-Snapshot-Verarbeitung, VDDK, Geräteerkennung, Berechtigungen, Multipathing und Anforderungen an eine unterstützte Topologie hinzu.

Veritas beschreibt SAN Transport als einen Pfad, bei dem ein physischer VMware-Backup-Host auf das SAN zugreift, das die virtuellen Disks der VM enthält. Die Best-Practice-Anleitung besagt, dass die Datastore-LUNs für den VMware-Backup-Host zugänglich sein müssen. Das ist notwendig. Es ist aber kein ausreichender Beleg für jede neuere Storage-Protokoll-Kombination.

Der Administrator im gemeldeten Fall hatte die erste offensichtliche Hürde bereits genommen: RHEL konnte die NVMe-FC-Datastores sehen. Trotzdem schlug das Backup beim Versuch, den Snapshot zu öffnen, weiterhin fehl. Das grenzt die Untersuchung ein. Der Fehler lautet nicht mehr einfach „der Host sieht den Storage nicht". Es kann daran liegen, wie VDDK das Snapshot-Gerät identifiziert, ob die Protokoll-Kombination für die installierten Releases unterstützt wird, wie Pfade präsentiert werden, oder wie Array und HBA den Namespace dem Backup-Host gegenüber offenlegen.

Behandeln Sie jeden dieser Punkte als testbare Grenze.

Wird NVMe over FC für dieses exakte Setup offiziell unterstützt?

Die von mir geprüfte Dokumentation bestätigt die exakte Kombination aus NetBackup 10.2.1, RHEL 9.8, vSphere 8, QLogic, PowerStore und NVMe over FC aus dem gemeldeten Fall nicht ausdrücklich. Die Veritas-Dokumentation beschreibt SAN Transport für Fibre Channel oder iSCSI, aber diese Formulierung sollte nicht zu einer Garantie für jede NVMe-FC-Implementierung ausgeweitet werden.

Hier zählt die Kompatibilitätsmatrix mehr als eine Forenantwort. Prüfen Sie NetBackup-Version, VMware-Version, Betriebssystem des Backup-Hosts, VDDK-Unterstützung, HBA-Treiber und -Firmware, Array-Präsentation und Storage-Protokoll als eine einzige Kombination. Listet die Matrix den Pfad nicht eindeutig auf, eröffnen Sie einen Support-Fall beim Hersteller, bevor Sie Tage mit Zoning-Experimenten verbringen.

Das ist bei NetBackup 10.2.1 besonders wichtig, denn „so lange upgraden, bis es funktioniert" ist keine Methode zur Fehlersuche. Ein neueres Release kann Unterstützung hinzufügen, gebündelte Komponenten ändern oder einen Fehler beheben, aber die Startversion für die gewünschte Topologie sollte aus dokumentierten Kompatibilitätsangaben stammen, nicht aus Vermutungen.

Dass der Fall ungeklärt bleibt, ist an sich aufschlussreich. Er zeigt, an welcher Stelle Administratoren aufhören sollten zu improvisieren und stattdessen eine verbindliche Aussage vom Support verlangen sollten.

Was sollte im SAN-Datenpfad geprüft werden?

Der SAN-Datenpfad sollte vom Backup-Host in Richtung Datastore geprüft werden, nicht nur von ESXi in Richtung Storage. Veritas gibt an, dass SAN Transport voraussetzt, dass der VMware-Backup-Host Zugriff auf das SAN hat, das die virtuellen Disks enthält. Bestätigen Sie in der Praxis, dass der physische Medien- oder Backup-Host dieselben Storage-Objekte in der Form sieht, die VDDK erwartet.

Prüfen Sie HBA-Modus, Zoning, Array-Host-Definitionen, Namespace- oder LUN-Präsentation, Anzahl der Pfade, Multipathing-Status, Berechtigungen sowie ob der Host die Geräte vor und nach der Erstellung eines VMware-Snapshots konsistent identifizieren kann. Notieren Sie WWPNs, wo relevant NQNs, Host-Mappings sowie die exakten, vom Betriebssystem gesehenen Gerätenamen.

Gehen Sie nicht davon aus, dass der Medienserver nur Konnektivität zu ESXi braucht. SAN Transport ist so konzipiert, dass virtuelle Disk-Daten aus dem gemeinsam genutzten Storage gelesen werden, ohne den vollständigen Datenstrom über den ESXi-Netzwerkpfad zu senden. Der Backup-Host braucht deshalb den Storage-Zugriff, den dieses Design voraussetzt.

Vermeiden Sie außerdem eine übermäßige Anzahl präsentierter Pfade. Veritas weist darauf hin, dass zu viele gezonte Pfade die Geräte-Pfad-Auswahl von VDDK verlangsamen können. Mehr Konnektivität ist nicht automatisch bessere Konnektivität.

Sollte der HBA im NVMe-Modus oder im klassischen FC-Modus laufen?

Der richtige HBA-Modus hängt davon ab, wie der Datastore präsentiert wird und was der unterstützte Backup-Pfad erwartet. Ein NVMe-FC-Datastore wird nicht allein dadurch zu einer klassischen FC-SCSI-LUN, dass dasselbe physische Fibre-Channel-Fabric beide Protokolle transportiert.

Das ist eine der zentralen Fragen im gemeldeten Fall. Der Administrator hatte QLogic-HBAs im NVMe-FC-Modus, weil der PowerStore-Datastore NVMe FC war. RHEL konnte ihn sehen. Die ungeklärte Frage war, ob NetBackup SAN Transport und der zugehörige VDDK-Stack diese Präsentation auf dieselbe Weise verarbeiten können.

Wird der HBA auf klassisches FC umgestellt, ohne die Storage-Präsentation zu ändern, kann der Namespace dadurch schlicht verschwinden. Das Präsentieren eines zweiten SCSI-Pfads könnte einen unterstützten Weg schaffen, das wird dann aber zu einer Array-Architektur-Entscheidung und sollte mit Dell, VMware und der NetBackup-Anleitung abgestimmt werden.

Dieselbe Disziplin auf Protokollebene ist auch in anderen Virtualisierungs-Stacks wichtig. Der Artikel von Mr.PlanB zu Proxmox-Backup-Optionen erinnert daran, dass die sichtbare VM-Ebene auf einem Storage-Pfad aufsetzt, dessen Verhalten darüber entscheiden kann, ob das Backup gelingt.

Wie können NBD oder NBDSSL den Fehler eingrenzen?

NBD oder NBDSSL lassen sich als diagnostischer Transport nutzen, weil sie VM-Daten über den ESXi-Netzwerkpfad bewegen, statt zu verlangen, dass der Backup-Host den Datastore direkt über SAN liest. Veritas dokumentiert beide Modi und weist darauf hin, dass NBD normalerweise langsamer ist als SAN Transport über Fibre Channel.

Lässt sich dieselbe VM erfolgreich mit NBD oder NBDSSL sichern, sind mehrere Teile des Workflows validiert: Policy-Auswahl, vCenter-Kommunikation, Snapshot-Erstellung und ein nutzbarer Netzwerk-Datenpfad. Der verbleibende Verdacht richtet sich dann auf den SAN-Gerätezugriff und die Kompatibilität.

Schlägt auch NBD bereits bei der Snapshot-Erstellung fehl, ist das SAN vermutlich nicht das einzige Problem. Untersuchen Sie den VMware-Snapshot-Status, Berechtigungen, wo relevant Changed Block Tracking, die VM-Konfiguration sowie vCenter- oder ESXi-Fehler.

Deshalb ist ein Fallback-Transport auch dann nützlich, wenn Sie ihn nie dauerhaft im Produktivbetrieb einsetzen wollen. Er zerlegt das Problem in einzelne Teile.

Für ein umfassenderes Recovery-Design macht der Proxmox-Backup-Server-Leitfaden denselben operativen Punkt in einem anderen Ökosystem: Die Performance des Datenpfads spielt eine Rolle, aber ein langsamerer, funktionierender Wiederherstellungspfad ist wertvoller als ein theoretisch schnellerer Pfad, der noch nie erfolgreich abgeschlossen wurde.

Welche Logs und Belege sollten vor einer Änderung des Zonings gesichert werden?

Erfassen Sie den Fehler, solange die ursprüngliche Topologie noch intakt ist. Notieren Sie die NetBackup-Job-Details, den genauen Kontext von „cannot open snapshot", VMware-Events, VDDK-bezogene Logs, Kernel- und HBA-Meldungen des Medienservers, den Status von Multipath oder NVMe-Subsystem sowie das Host-Mapping des Storage-Arrays.

Erstellen Sie dann eine kleine Testmatrix. Probieren Sie eine VM auf dem betroffenen NVMe-FC-Datastore. Testen Sie ausschließlich SAN. Testen Sie NBD oder NBDSSL. Testen Sie nach Möglichkeit eine VM auf einem bekannten klassischen FC- oder einem anderen unterstützten Datastore mit demselben Backup-Host. Ändern Sie jeweils nur eine Variable.

Diese Matrix kann Fragen beantworten, die eine lange Logdatei nicht beantworten kann. Funktioniert SAN bei klassischem FC und schlägt bei NVMe FC fehl, wird die Protokollunterstützung zur zentralen Frage. Schlägt SAN überall fehl, ist eher die Konfiguration des Medienservers verdächtig. Schlägt nur ein Datastore fehl, verdient das Array-Mapping oder die Präsentation Aufmerksamkeit.

Beginnen Sie nicht damit, Zoning, HBA-Personality, Treiber, NetBackup-Versionen und VMware-Einstellungen gleichzeitig zu ändern. Ein erfolgreicher Job nach fünf gleichzeitigen Änderungen lehrt so gut wie nichts.

Was würde ich vor dem Produktiveinsatz tun?

Ich würde eine schriftliche Kompatibilitätsbestätigung für den exakten NVMe-over-FC-Pfad verlangen und sie dann mit einem kontrollierten Backup- und Restore-Test belegen. Bis das vorliegt, würde ich einen unterstützten Netzwerktransport verfügbar halten, damit der Schutz nicht ausgesetzt wird, während der SAN-Pfad untersucht wird.

Braucht das Unternehmen die Performance von SAN, bauen Sie den Test um den realen Hardware- und Firmware-Stack herum auf. Validieren Sie Backup-Durchsatz, Snapshot-Bereinigung, Multipathing-Verhalten, Failover und Restore — nicht nur ein einziges erfolgreiches Backup. Ein Datenpfad, der nur funktioniert, wenn jeder FC-Pfad einwandfrei ist, ist nicht produktionsreif.

Am wichtigsten: Lassen Sie die Gerätesichtbarkeit unter Linux nicht zum Abnahmetest werden. Sie beweist nur, dass eine Ebene funktioniert. NetBackup SAN Transport durchquert noch mehrere weitere Ebenen, bevor aus einem VM-Image ein nutzbarer Wiederherstellungspunkt wird.