Por qué falla NetBackup SAN transport en almacenes de datos NVMe over FC

Que un servidor de medios RHEL pueda ver un datastore de NVMe over Fibre Channel no garantiza que NetBackup SAN transport sea capaz de abrir los discos de las snapshots de VMware a través de esa ruta. En un entorno reportado con NetBackup 10.2.1, el almacenamiento era accesible para RHEL 9.8 pero el transporte SAN seguía fallando con el error «cannot open snapshot», lo que apunta a un problema de compatibilidad o de la ruta de datos que debe aislarse capa por capa.

La configuración era muy concreta: servidores HPE Gen11, HBA QLogic configuradas para NVMe over FC, almacenamiento Dell PowerStore, vSphere 8 y datastores VMFS presentados mediante NVMe FC. Esos detalles resultan determinantes, porque afirmar que «Fibre Channel funciona» es una conclusión demasiado amplia cuando el protocolo entregado en el fabric es NVMe en lugar de SCSI clásico.

¿Por qué la visibilidad del datastore no garantiza el funcionamiento de SAN transport?

La visibilidad del datastore solo demuestra que el sistema operativo y su pila de NVMe FC pueden descubrir y acceder a la presentación del almacenamiento. El transporte SAN de NetBackup para VMware añade la gestión de snapshots de VMware, VDDK, el descubrimiento de dispositivos, permisos, multipathing y los requisitos de topologías con soporte por encima de esa visibilidad básica.

Veritas describe el transporte SAN como un mecanismo donde un host de backup físico de VMware accede a la SAN que contiene los discos virtuales de la VM. Sus directrices de buenas prácticas indican que las LUN del datastore deben ser accesibles para dicho host. Ese requisito es indispensable, pero cumplirlo no constituye una prueba suficiente en cualquier combinación reciente de protocolos de almacenamiento.

El administrador del caso ya había superado la primera barrera evidente: RHEL podía ver los datastores NVMe FC. Sin embargo, el backup fallaba al intentar abrir la snapshot, lo que circunscribe el problema más allá de si el host ve o no el almacenamiento. El origen puede residir en cómo VDDK identifica el dispositivo de snapshot, si la combinación de protocolos cuenta con soporte para las versiones desplegadas, cómo se presentan las rutas o de qué forma la cabina y la HBA exponen el namespace al host de backup. Conviene tratar cada uno de estos aspectos como una frontera comprobable.

¿Existe soporte oficial para NVMe over FC en este entorno concreto?

La documentación verificada no valida de forma explícita la combinación concreta de NetBackup 10.2.1, RHEL 9.8, vSphere 8, QLogic, PowerStore y NVMe over FC descrita en el incidente. Veritas documenta el transporte SAN sobre Fibre Channel o iSCSI, pero esa formulación no debe extrapolarse como una garantía universal para cualquier implementación de NVMe FC.

En este punto, la matriz de compatibilidad pesa más que las opiniones en un foro. Contrasta la versión de NetBackup, la versión de VMware, el sistema operativo del host de backup, el soporte de VDDK, el controlador y firmware de la HBA, la presentación de la cabina y el protocolo de almacenamiento como un conjunto indisociable. Si la matriz no refleja con claridad esa ruta, abre un caso de soporte con el fabricante antes de invertir días en pruebas de zonificado.

Esto cobra especial relevancia con NetBackup 10.2.1, dado que «actualizar hasta que funcione» no es un procedimiento metódico de diagnóstico. Una versión posterior puede incorporar soporte, renovar componentes integrados o resolver un defecto, pero la versión inicial de referencia para la topología pretendida debe apoyarse en información documentada de compatibilidad y no en conjeturas.

El caso continúa sin resolución definitiva, y eso lo vuelve didáctico: enseña el momento exacto en que los administradores deben dejar de improvisar y solicitar una confirmación oficial de soporte.

¿Qué se debe comprobar en la ruta de datos SAN?

Revisa la ruta de datos SAN tanto desde el host de backup hacia el datastore como desde ESXi hacia la cabina. Veritas señala que el transporte SAN exige que el host de backup de VMware disponga de acceso a la SAN que alberga los discos virtuales. En la práctica, esto supone verificar que el servidor de medios o host de backup físico identifique los mismos objetos de almacenamiento en el formato que VDDK espera utilizar.

Comprueba el modo de la HBA, el zonificado, la definición de hosts en la cabina, la presentación de LUN o namespaces, el recuento de rutas, el estado del multipathing, los permisos y si el host identifica los dispositivos con coherencia antes y después de crear una snapshot de VMware. Registra WWPN, NQN cuando proceda, mapeos de host y los nombres exactos de dispositivo detectados por el sistema operativo.

La conectividad con ESXi no basta por sí sola para el servidor de medios. El transporte SAN está ideado para leer datos de discos virtuales desde el almacenamiento compartido sin saturar la red de ESXi, por lo que el host de backup necesita el acceso específico al almacenamiento que requiere esa arquitectura.

Evita además presentar un número excesivo de rutas. Veritas advierte de que demasiadas rutas zonificadas pueden ralentizar la selección de rutas de dispositivos en VDDK; por tanto, mayor conectividad no equivale necesariamente a un mejor funcionamiento.

¿Debe operar la HBA en modo NVMe o en modo FC clásico?

El modo adecuado de la HBA depende de cómo esté presentado el datastore y de qué espere la ruta de backup admitida. Un datastore NVMe FC no se transforma en una LUN SCSI clásica sobre FC por el mero hecho de que el mismo fabric físico de Fibre Channel canalice ambos protocolos.

Esta es una de las preguntas clave en el caso reportado. El administrador disponía de HBA QLogic en modo NVMe FC porque el datastore de PowerStore era NVMe FC y RHEL podía verlo. La duda no resuelta era si NetBackup SAN transport y la pila de VDDK correspondiente podían consumir esa presentación de idéntica manera.

Cambiar la HBA a FC clásico sin modificar la presentación del almacenamiento puede provocar simplemente que el namespace deje de ser visible. Presentar una segunda ruta SCSI podría abrir una vía compatible, pero eso pasa a ser una decisión de arquitectura de la cabina que debe validarse con la documentación de Dell, VMware y NetBackup.

El mismo rigor protocolario se aplica en otras plataformas de virtualización. La revisión de opciones de backup en Proxmox de Mr.PlanB recuerda oportunamente que la capa visible de las máquinas virtuales descansa sobre una ruta de almacenamiento cuyo comportamiento determina si el backup tiene éxito.

¿Cómo pueden NBD o NBDSSL aislar el problema?

NBD o NBDSSL pueden utilizarse como métodos de transporte de diagnóstico porque transfieren los datos de la VM a través de la red de ESXi en lugar de exigir que el host de backup lea el datastore directamente por la SAN. Veritas documenta ambos modos y señala que NBD resulta habitualmente más lento que el transporte SAN por Fibre Channel.

Si la misma VM se respalda sin errores con NBD o NBDSSL, quedan validados varios tramos del flujo: la selección de la política, la comunicación con vCenter, la creación de snapshots y la existencia de una ruta de datos utilizable por red. Las sospechas se concentran entonces en el acceso y compatibilidad con los dispositivos SAN.

Si NBD falla también durante la creación de la snapshot, es poco probable que la SAN sea el único causante. Habrá que investigar el estado de las snapshots en VMware, los permisos, el Changed Block Tracking (CBT) si aplica, la configuración de la VM y los registros de vCenter o ESXi.

Por esta razón, disponer de un transporte de respaldo resulta provechoso aunque no pienses mantenerlo en producción: permite dividir el problema en dos mitades.

En un diseño más amplio de recuperación, la guía de Proxmox Backup Server insiste en la misma realidad operativa dentro de otro ecosistema: el rendimiento del canal de datos es importante, pero una ruta funcional algo más lenta vale más que una teóricamente rápida que jamás completa un trabajo.

¿Qué registros y evidencias recopilar antes de modificar el zonificado?

Captura el fallo mientras la topología original permanezca inalterada. Guarda el detalle del trabajo en NetBackup, el contexto exacto del mensaje «cannot open snapshot», los eventos de VMware, las trazas de VDDK, los mensajes del kernel y de la HBA en el servidor de medios, el estado del subsistema multipath o NVMe y el mapeo de hosts en la cabina de almacenamiento.

Diseña después una pequeña matriz de pruebas. Prueba una VM en el datastore NVMe FC afectado utilizando únicamente SAN y luego con NBD o NBDSSL. Si resulta factible, prueba una VM en un datastore con FC clásico conocido u otro con soporte oficial utilizando el mismo host de backup, modificando una sola variable cada vez.

Esa matriz responderá dudas que un archivo de registro interminable no puede aclarar. Si SAN opera bien en FC clásico y falla en NVMe FC, el soporte del protocolo pasa a ser la hipótesis principal. Si SAN falla en cualquier escenario, la configuración del servidor de medios cobra mayor sospecha. Si solo falla un datastore concreto, la atención debe centrarse en el mapeo o la presentación de la cabina.

No empieces variando a la vez el zonificado, el modo de la HBA, los controladores, las versiones de NetBackup y los parámetros de VMware. Un trabajo que termine bien tras cinco alteraciones simultáneas apenas aporta aprendizaje alguno.

¿Qué haría antes de llevar esta solución a producción?

Exigiría confirmación por escrito de la compatibilidad oficial para la ruta exacta de NVMe over FC y la validaría mediante pruebas controladas de backup y restauración. Hasta disponer de esa certeza, mantendría operativo un transporte por red con soporte para asegurar la continuidad de la protección mientras se esclarece el canal SAN.

Si la empresa exige rendimiento SAN, plantea las pruebas sobre el hardware y firmware reales. Valida la tasa de transferencia del backup, la liberación de snapshots, la respuesta del multipathing, la tolerancia a fallos y la restauración, ya que un único backup completado con éxito no demuestra gran cosa. Una ruta de datos que solo responda cuando todos los caminos de FC están impecables no está lista para producción.

Por encima de todo, no permitas que la visibilidad del dispositivo en Linux actúe como prueba de aceptación definitiva. Acredita que una capa funciona, pero NetBackup SAN transport atraviesa bastantes más capas antes de que una imagen de VM se convierta en un punto de recuperación plenamente utilizable.