Errores 6601, 6625 y 6654 de NetBackup con MongoDB: qué comprobar primero

Los errores 6601, 6625 y 6654 de NetBackup con MongoDB no deben catalogarse como un único fallo genérico de base de datos. Casos recientes muestran cómo los errores cambian a medida que se modifican las credenciales y la configuración del host. Además, la documentación de Veritas trata la autenticación de MongoDB, el acceso al host, la resolución de nombres, las claves RSA, los hosts de backup y las políticas como capas completamente separadas.

La regla de oro consiste en identificar qué capa falla antes de alterar la siguiente. Un administrador vio desaparecer el estado 6625 tras corregir las credenciales de host en tpconfig, solo para quedarse bloqueado con el estado 6601. Otro se encontró con el estado 6654, "Unable to retrieve credentials", incluso después de deshabilitar la seguridad en MongoDB y seleccionar No Authentication. Esos indicios aportan pistas valiosas, aunque no demuestran una única causa raíz común.

¿Por qué ocurre el estado 6654 aun sin autenticación en MongoDB?

El estado 6654 puede seguir respondiendo a un problema de credenciales porque el modo No Authentication de NetBackup sigue dependiendo de credenciales. Veritas documenta un archivo de credenciales para el caso NOAUTH que requiere HostUser, HostPassword y HostRsaKey para el nodo de MongoDB.

Esto explica por qué desactivar la autenticación en MongoDB puede dejar el fallo intacto. El acceso a la base de datos y el acceso al host son planos distintos. NetBackup sigue necesitando una vía de confianza para conectar y operar en el host de MongoDB. Si esa identidad de host falta, difiere o está registrada con un nombre distinto al que espera la política, la base de datos puede estar completamente abierta y el backup seguirá fallando.

Veritas documenta asimismo un caso concreto de estado 6654 originado por inconsistencias en los nombres de host. Las credenciales se guardaron usando un formato de nombre de host, mientras que la política o la configuración empleaban otro: un nombre corto en un lado y un FQDN en el otro bastaron para romper la recuperación de credenciales.

Por tanto, la primera comprobación para el 6654 es metódica pero necesaria: anota las cadenas exactas de host registradas en tpconfig, en la política de backup, en la identidad de NetBackup del cliente y en mongodb.conf. Todas deben describir el mismo nodo de forma coherente.

¿Qué revisar primero en tpconfig?

Revisa la entrada de tpconfig para verificar el servidor de aplicaciones correcto, el tipo de autenticación, el usuario de host, la clave RSA y el formato exacto del nombre de host. Veritas indica que las credenciales del nodo de MongoDB se asocian al servidor de aplicaciones especificado en la pestaña Clients de la política de backup.

Para un replica set o un despliegue independiente, la configuración de credenciales identifica el nombre de host y el puerto de mongod. Un clúster particionado (sharded) puede incorporar múltiples extremos de mongod y mongos. Si la política apunta a un nombre mientras las credenciales están vinculadas a otro, NetBackup buscará en el lugar equivocado aunque ambos nombres resuelvan en el DNS.

El usuario de host también es determinante. Las directrices actuales de Veritas para clústeres que corren bajo una cuenta de servicio mongod indican no utilizar la propia cuenta de servicio mongod como usuario de host en tpconfig. Recomiendan una cuenta de host no root con privilegios de sudo, directorio de inicio propio y permisos sobre las rutas indicadas en mongodb.conf.

Esto aclara por qué recurrir a root solucionó temporalmente un error en el caso del administrador, aunque no justifique recomendar su uso. Root pudo despejar un obstáculo de permisos y hacer desaparecer el estado 6625. La solución duradera consiste en averiguar qué permiso le falta a la cuenta designada y configurar el modelo no root con soporte oficial.

¿Qué indican los estados 6601 y 6625 en el caso reportado?

En el incidente analizado, que el estado 6625 desapareciera tras ajustar credenciales demuestra que ese cambio afectó a la ruta del fallo. No confirma que todo evento con estado 6625 comparta el mismo conflicto de permisos, y el debate no aportó evidencias suficientes para determinar la causa raíz del estado 6601.

Por ello conviene registrar cada prueba. Anota el error inicial, modifica una sola variable, relanza la misma tarea de backup y comprueba si el código de estado varía. Si 6625 pasa a 6601, el proceso avanzó lo bastante como para toparse con una condición distinta. Aplicar varios cambios a la vez destruye esa pista.

Las revisiones útiles abarcan las versiones exactas de NetBackup y MongoDB, la topología del motor, el tipo de política elegido, el host de backup, el estado de despliegue del plugin, mongodb.conf, el registro de credenciales, la clave RSA de host, la coherencia de los nombres y los permisos en cada directorio que NetBackup deba utilizar.

Si MongoDB corre dentro de una máquina virtual, separa el problema aplicativo de la protección del equipo. La comparativa de backup en Proxmox refleja la diferencia de fondo entre proteger una VM como objeto y respaldar el estado aplicativo interno; un punto de recuperación de VM no resuelve todas las dudas sobre la base de datos.

¿Debe residir el cliente de NetBackup en el servidor de MongoDB?

Que un backup falle no implica necesariamente que cada nodo de MongoDB deba tener instalado un cliente de NetBackup. La arquitectura adecuada depende del flujo de trabajo del plugin de MongoDB y de la versión de NetBackup, incluyendo qué equipo ejerce de host de backup.

La documentación de Veritas contempla de forma explícita que un cliente de NetBackup actúe como host de backup. Cuando un cliente asume esa función, debe incluirse en la lista de autorizados del servidor principal mediante la directiva APP_PROXY_SERVER, lo cual dista mucho de tener que instalar el cliente en todas partes.

Este matiz importa porque añadir software al servidor de base de datos puede dar una falsa sensación de avance mientras el error de configuración de fondo sigue intacto. Antes de desplegar otro cliente, mapea el flujo con soporte: servidor principal, host de backup, nodo de MongoDB, plugin, credenciales, política y ruta de datos. Confirma luego qué componente debe residir en cada equipo según tu versión concreta de NetBackup.

La guía de Proxmox Backup Server aplica el mismo razonamiento sobre las capas de recuperación. La protección del host y el respaldo con reconocimiento de aplicaciones resuelven problemas relacionados, pero ninguno sustituye al otro.

¿Cómo verificar las discrepancias en nombres de host?

Verifica las diferencias de nombres contrastando cadenas literales, ya que la resolución DNS solo prueba que un nombre apunta a una IP. La búsqueda de credenciales en NetBackup suele depender de la cadena exacta utilizada cuando se almacenaron.

Comienza por el valor del servidor de aplicaciones en la política y compáralo con el nombre de host configurado en tpconfig. Contrasta ambos con el nombre del cliente y con cada host listado en mongodb.conf. Si el estándar del entorno es FQDN, utiliza el FQDN en todos los puntos. Si un procedimiento documentado exige un nombre corto, sé coherente con esa opción en todo el circuito.

Verifica después la resolución directa e inversa desde los equipos que intervienen en el backup y descarta alias duplicados que apunten a interfaces distintas o registros obsoletos. Si el nodo cambió de nombre, confirma que la configuración de NetBackup se actualizó en lugar de confiar en que los alias DNS maquillen la disparidad. Este es uno de esos fallos donde la red funciona bien y, sin embargo, el backup sigue roto.

¿Cuál es el orden más seguro para la resolución del problema?

Prioriza primero la identidad, luego la ubicación del plugin, después la configuración de la política y de la aplicación, y por último la transferencia de datos. Confirma las versiones y la topología compatibles, los nodos de MongoDB y los nombres de host. Valida las credenciales en tpconfig, las claves RSA y que el usuario de host cumpla las pautas documentadas. Verifica las rutas y permisos en mongodb.conf, y que el servidor principal reconozca al host de backup. Solo entonces amplía la búsqueda a la red, el almacenamiento y el comportamiento interno de la base de datos.

No desactives la seguridad de MongoDB como primer paso de diagnóstico. El caso del estado 6654 demuestra cómo se pierde el tiempo: NOAUTH sigue manteniendo las credenciales de host de NetBackup en la ecuación, y quitar la autenticación de la base de datos introduce un nuevo escenario de riesgo sin demostrar nada sobre la identidad de host que NetBackup intenta recuperar.

Evita asimismo conservar root como apaño permanente solo porque un código de error desaparezca. Tómalo como una prueba de que los permisos importan y avanza hacia la cuenta de host con los mínimos privilegios que contemple la guía de NetBackup para MongoDB.

El objetivo consiste en entender con exactitud qué identidad, qué host y qué configuración utiliza NetBackup, de modo que la solución resulte predecible al añadir un nuevo nodo, otro replica set o abordar una restauración futura. Una tarea que se pintó de verde por casualidad no aporta ninguna de esas certezas.