Error 156 de NetBackup en Hyper-V: arreglar los snapshots

El estado 156 de NetBackup en Hyper-V significa que la operación de snapshot falló, pero no apunta a una única causa universal. Cuando el fallo deja discos AVHD o AVHDX sin consolidar y los checkpoints posteriores también fallan, deja de tratarlo como un simple reintento de copia de seguridad y ponte a diagnosticar la propia cadena de snapshots de Hyper-V.

Un administrador contó que tenía más de 100 servidores afectados después de que los intentos de snapshot de NetBackup devolvieran el 156. Su hipótesis era que la contraseña de una cuenta de servicio de NetBackup había cambiado sin actualizarse en los hosts Hyper-V, y que las operaciones fallidas habían dejado discos que no se consolidaban.

¿Qué significa de verdad el error 156 de NetBackup en Hyper-V?

NetBackup documenta el estado 156 como "snapshot error encountered". La guía actual de Hyper-V enumera varias causas posibles en lugar de una solución directa, entre ellas nombres de VM incorrectos en la política, espacio libre insuficiente para el snapshot y componentes de integración de Hyper-V ausentes o incorrectos. Dicho de otro modo, el código de estado te dice dónde falló el trabajo, y cada entorno puede fallar ahí por sus propios motivos.

Empieza por reunir los detalles del trabajo de NetBackup y los registros de eventos de Hyper-V de una VM afectada. Identifica el primer error de snapshot, el host que lo inició y si Hyper-V puede crear un checkpoint por su cuenta, fuera de NetBackup. Si un checkpoint manual de Hyper-V también falla, el problema está por debajo de la capa de políticas de NetBackup, así que arregla la VM de Hyper-V, VSS, el almacenamiento o el estado de los checkpoints antes de lanzar otra copia de seguridad.

¿Puede una contraseña caducada de una cuenta de servicio causar la cadena de fallos?

Sí, unas credenciales incorrectas pueden romper el descubrimiento o las operaciones de API, pero el caso original no demuestra que el cambio de contraseña sea la única causa de todos los problemas de AVHDX que quedan. Un comentarista señaló que, en algunas configuraciones, NetBackup para Hyper-V depende de una identidad de dominio para las operaciones de la API de Windows, y sugirió comprobar si el descubrimiento sigue funcionando.

Eso te da una división útil. Si NetBackup no puede explorar ni descubrir los recursos de Hyper-V, hay que revisar de inmediato la autenticación y la configuración de la cuenta. Si el descubrimiento funciona pero la creación del snapshot falla, sigue con el diagnóstico de snapshots y VSS.

Después de actualizar la contraseña de una cuenta de servicio, comprueba la credencial en todos los sitios donde esté guardada o delegada, y prueba con un host y una VM antes de reactivar la protección en toda la flota. Arreglar la credencial no repara por sí solo una cadena de checkpoints que ya quedó en mal estado. La autenticación puede explicar la operación fallida inicial, mientras que Hyper-V sigue teniendo que fusionar o limpiar los discos diferenciales resultantes.

¿Por qué los discos AVHDX sin consolidar pueden bloquear checkpoints futuros?

Los checkpoints de Hyper-V usan discos diferenciales, normalmente archivos AVHDX, que forman una cadena padre-hijo con los discos virtuales de la VM. Cuando se elimina un checkpoint, Hyper-V normalmente fusiona los datos diferenciales de vuelta en la cadena padre.

Si esa fusión no termina, la VM puede quedarse con un checkpoint o una cadena de discos que impide crear snapshots nuevos limpios, y los trabajos posteriores de NetBackup pueden volver a fallar aunque ya se haya corregido la causa original. Eso encaja con el patrón repetido de estado 156 que vio el administrador: el primer snapshot fallido creó un estado de la infraestructura que hacía más probable que fallara el siguiente.

No borres a mano archivos AVHDX del sistema de archivos, porque puedes romper la cadena y dejar la VM sin poder arrancar. Usa Hyper-V Manager, PowerShell, los registros de eventos y los procedimientos de fusión o reparación de checkpoints con soporte de Microsoft, según la relación real entre los discos.

¿Deberías reiniciar más de 100 VM para consolidar los discos?

En algunos sistemas puede parecer que un reinicio ayuda, pero reiniciar todo el entorno es una mala primera estrategia de reparación. El administrador del caso señaló que reiniciar los servidores consolidaba los discos, y comprensiblemente no quería reiniciar más de 100 máquinas.

Usa una muestra. Elige una VM afectada que no sea crítica, documenta el árbol de checkpoints y la cadena AVHDX antes del reinicio y después comprueba exactamente qué cambia. Si el reinicio desencadena una limpieza con soporte, ya tienes una prueba. Si no, te has ahorrado un mantenimiento masivo sin ningún beneficio.

Para el resto de la flota, agrupa las VM por síntoma. Algunas pueden tener checkpoints obsoletos, otras fallos de VSS, otras poco espacio, y a algunas puede que solo haga falta arreglarles la credencial.

La concurrencia de la política de backup también importa aquí. Una gran oleada de operaciones de snapshot puede sobrecargar los hosts, el almacenamiento y los componentes de gestión, así que limita el trabajo concurrente a un nivel que el clúster Hyper-V pueda absorber, en lugar de dejar que todas las VM protegidas creen snapshots a la vez.

¿Qué otras causas del estado 156 deberías revisar?

Comprueba el espacio libre dentro de los volúmenes de la VM que correspondan y en el almacenamiento de Hyper-V, ya que la guía de NetBackup para Hyper-V indica que la falta de espacio libre puede hacer fallar el snapshot. Confirma también que los nombres o identificadores de VM de la política siguen coincidiendo con el inventario real de Hyper-V. Verifica los componentes de integración de Hyper-V en el invitado cuando la configuración con soporte los exija, y después comprueba el estado de los escritores VSS dentro de los invitados Windows que necesiten snapshots coherentes con las aplicaciones.

Ten cuidado con los consejos copiados de casos de VMware. En el hilo de Reddit se habló brevemente de un proveedor VSS de Veritas que se aplica a ciertos flujos de estado de aplicaciones en VMware, y otro participante señaló con razón que no arregla un caso de Hyper-V. Mantén claras las fronteras entre plataformas: el comportamiento de los snapshots de Hyper-V, el de los snapshots de VMware y el backup con reconocimiento de aplicaciones en el invitado pueden producir síntomas de "snapshot" aunque usen componentes distintos.

Para una comparación más amplia de backup en virtualización, consulta las opciones de backup de Proxmox. Las plataformas son distintas, pero se aplica la misma regla. La tecnología de snapshots forma parte de la pila del hipervisor y del almacenamiento, así que un producto de backup puede lanzar la operación sin ser responsable de cada fallo que ocurra por debajo.

¿Cómo evitas otro incidente masivo de snapshots?

Corrige la condición que lo inició y después reduce el radio de impacto. Gestiona el ciclo de vida de las cuentas de servicio para que los cambios de contraseña lleguen a las integraciones de backup antes del siguiente trabajo programado, y monitorea los fallos de descubrimiento y autenticación por separado de los fallos de snapshot.

Configura límites de recursos razonables en NetBackup y la concurrencia de las unidades de almacenamiento. Las operaciones de snapshot tienen un coste: generan trabajo de gestión, de almacenamiento y de fusión que puede notarse durante una ventana de backup grande.

Vigila los checkpoints y archivos AVHDX que se quedan colgados después de fallos de backup. Un informe diario que identifique las VM con checkpoints antiguos o cadenas de discos diferenciales poco habituales puede detectar el problema secundario antes de que llegue a 100 servidores.

La guía de Proxmox Backup Server aporta un contexto útil desde otra plataforma, porque trata la salud del backup y la salud del hipervisor como señales separadas. Un trabajo fallido puede ser un problema de configuración del backup, de la VM o del almacenamiento.

¿Qué haría yo con la flota afectada?

Congelaría los reintentos de backup del grupo afectado, porque otro intento de snapshot no sirve de nada mientras la cadena de discos no esté sana. Después arreglaría la cuenta de servicio sospechosa y demostraría que el descubrimiento de recursos y las operaciones de API funcionan en un host Hyper-V.

A continuación elegiría una VM afectada y averiguaría si Hyper-V puede crear y eliminar un checkpoint a mano. Revisaría VSS, el espacio libre, los registros de eventos y las relaciones padre de los AVHDX, y después usaría el método con soporte de Hyper-V para fusionar o limpiar la cadena de checkpoints.

Una vez demostrada una vía de reparación, automatiza el inventario y repite el procedimiento validado en lotes controlados. Solo cuando las VM estuvieran sanas volvería a activar la protección de NetBackup.

El estado 156 da la alarma. El trabajo de recuperación consiste en identificar qué dependencia del snapshot falló de verdad y en limpiar el estado del hipervisor antes de la siguiente ventana de backup.