NetBackup SAN Transport Fails on NVMe over FC

A RHEL media server being able to see an NVMe over Fibre Channel datastore does not prove that NetBackup SAN transport can open VMware snapshot disks through that path. In a reported NetBackup 10.2.1 environment, the storage was visible to RHEL 9.8 but SAN transport still failed with “cannot open snapshot,” which points to a compatibility or data-path problem that needs to be isolated layer by layer.

The setup was specific: HPE Gen11 servers, QLogic HBAs configured for NVMe over FC, Dell PowerStore storage, vSphere 8, and VMFS datastores presented over NVMe FC. That specificity matters. “Fibre Channel works” is too broad a conclusion when the protocol presented through the fabric is NVMe rather than classic SCSI.

Why does datastore visibility not prove SAN transport will work?

Datastore visibility only proves that the operating system and its NVMe FC stack can discover and access the storage presentation. NetBackup VMware SAN transport adds VMware snapshot handling, VDDK, device discovery, permissions, multipathing, and supported topology requirements on top of that basic visibility.

Veritas describes SAN transport as a path where a physical VMware backup host accesses the SAN containing the VM's virtual disks. Its best-practice guidance says the datastore LUNs must be accessible to the VMware backup host. That is necessary. It is not sufficient evidence for every newer storage protocol combination.

The reported administrator had already cleared the first obvious hurdle: RHEL could see the NVMe FC datastores. Yet the backup still failed when it tried to open the snapshot. That narrows the investigation. The failure is no longer simply “the host cannot see storage.” It may be how VDDK identifies the snapshot device, whether the protocol combination is supported for the installed releases, how paths are presented, or how the array and HBA expose the namespace to the backup host.

Treat each of those as a testable boundary.

Is NVMe over FC officially supported for this exact setup?

The verified documentation I found does not explicitly confirm the exact NetBackup 10.2.1, RHEL 9.8, vSphere 8, QLogic, PowerStore, NVMe over FC combination from the reported case. Veritas documentation describes SAN transport for Fibre Channel or iSCSI, but that wording should not be stretched into a guarantee for every NVMe FC implementation.

This is where the compatibility matrix matters more than a forum answer. Check the NetBackup version, VMware version, backup-host operating system, VDDK support, HBA driver and firmware, array presentation, and storage protocol as one combination. If the matrix does not clearly list the path, open a vendor support case before spending days on zoning experiments.

That is especially important with NetBackup 10.2.1 because “upgrade until it works” is not a troubleshooting method. A newer release may add support, change bundled components, or fix a defect, but the starting version for the desired topology should come from documented compatibility information, not guesswork.

The unresolved nature of the case is useful. It shows where operators should stop improvising and demand a support statement.

What should be checked in the SAN data path?

The SAN data path should be checked from the backup host toward the datastore, not only from ESXi toward storage. Veritas says SAN transport requires the VMware backup host to have access to the SAN containing the virtual disks. In practical terms, confirm that the physical media or backup host sees the same storage objects in the form VDDK expects to use.

Check HBA mode, zoning, array host definitions, namespace or LUN presentation, path count, multipathing state, permissions, and whether the host can identify the devices consistently before and after a VMware snapshot is created. Record WWPNs, NQNs where relevant, host mappings, and the exact device names seen by the operating system.

Do not assume the media server needs only connectivity to ESXi. SAN transport is designed to read virtual disk data from shared storage without sending the full data stream through the ESXi network path. The backup host therefore needs the storage access required by that design.

Also avoid presenting an excessive number of paths. Veritas notes that too many zoned paths can slow VDDK device-path selection. More connectivity is not automatically better connectivity.

Should the HBA be in NVMe mode or classic FC mode?

The correct HBA mode depends on how the datastore is presented and what the supported backup path expects. An NVMe FC datastore is not transformed into a classic FC SCSI LUN just because the same physical Fibre Channel fabric carries both protocols.

This is one of the central questions in the reported case. The administrator had QLogic HBAs operating in NVMe FC mode because the PowerStore datastore was NVMe FC. RHEL could see it. The unresolved question was whether NetBackup SAN transport and the relevant VDDK stack could consume that presentation in the same way.

Changing the HBA to classic FC without changing the storage presentation may simply make the namespace disappear. Presenting a second SCSI path might create a supported route, but that becomes an array architecture decision and should be validated with Dell, VMware, and NetBackup guidance.

The same protocol-layer discipline matters in other virtualization stacks. Mr.PlanB's article on Proxmox backup choices is a useful reminder that the visible VM layer sits on top of a storage path whose behavior can decide whether backup succeeds.

How can NBD or NBDSSL isolate the failure?

NBD or NBDSSL can be used as a diagnostic transport because they move VM data through the ESXi network path instead of requiring the backup host to read the datastore directly over SAN. Veritas documents both modes and notes that NBD is normally slower than Fibre Channel SAN transport.

If the same VM backs up successfully with NBD or NBDSSL, several parts of the workflow have been validated: policy selection, vCenter communication, snapshot creation, and a usable network data path. The remaining suspicion moves toward SAN device access and compatibility.

If NBD also fails at snapshot creation, the SAN is less likely to be the only problem. Investigate VMware snapshot state, permissions, changed block tracking where relevant, VM configuration, and vCenter or ESXi errors.

This is why fallback transport is useful even if you never intend to keep it in production. It divides the problem.

For a broader recovery design, the Proxmox Backup Server guide makes the same operational point in another ecosystem: data-path performance matters, but a slower working recovery path is more valuable than a theoretically faster path that has never completed successfully.

What logs and evidence should be captured before changing zoning?

Capture the failure while the original topology is still intact. Record the NetBackup job details, exact “cannot open snapshot” context, VMware events, VDDK-related logs, media-server kernel and HBA messages, multipath or NVMe subsystem state, and storage-array host mapping.

Then create a small test matrix. Try one VM on the affected NVMe FC datastore. Test SAN only. Test NBD or NBDSSL. If possible, test a VM on a known classic FC or other supported datastore using the same backup host. Change one variable at a time.

That matrix can answer questions that a long log file cannot. If SAN works on classic FC and fails on NVMe FC, protocol support becomes the leading question. If SAN fails everywhere, the media server configuration is more suspect. If only one datastore fails, array mapping or presentation deserves attention.

Do not start by changing zoning, HBA personality, drivers, NetBackup versions, and VMware settings together. A successful job after five simultaneous changes teaches almost nothing.

What would I do before putting this into production?

I would require written compatibility confirmation for the exact NVMe over FC path, then prove it with a controlled backup and restore test. Until that exists, I would keep a supported network transport available so protection does not stop while the SAN path is being investigated.

If the business needs SAN performance, build the test around the real hardware and firmware stack. Validate backup throughput, snapshot cleanup, multipathing behavior, failover, and restore, not just one successful backup. A data path that works only when every FC path is healthy is not ready.

Most importantly, do not let Linux device visibility become the acceptance test. It proves that one layer works. NetBackup SAN transport crosses several more layers before a VM image becomes a usable recovery point.