Trabajos de Veeam: archivos bloqueados y fallos con checkpoints

Archivos de backup bloqueados y fallos en la limpieza de checkpoints de Hyper-V pueden convertir un único problema de Veeam en varios trabajos atascados. En una reclamación en producción de 2026, un administrador explicó que los archivos de backup se bloqueaban sin motivo aparente, los flujos de trabajo en cinta se detenían a continuación y los fallos al eliminar checkpoints ocurrían a diario.

Lo que complica esto es el efecto en cascada. Los sistemas de backup son canalizaciones: un backup principal genera puntos de restauración, los trabajos de copia de backup dependen de esos puntos, los trabajos en cinta pueden depender de los archivos locales de backup, y la retención y la limpieza dependen de que las sesiones previas finalicen correctamente. Cuando una etapa retiene un archivo o deja un checkpoint atrás, el fallo visible puede manifestarse en cualquier otra parte.

¿Cómo puede un solo archivo bloqueado en Veeam frenar varios trabajos?

Un archivo de backup que continúa en uso puede impedir que otro proceso lo lea, mueva, transforme, elimine o copie como se esperaba. En el entorno reportado, el administrador señaló que otros trabajos podían quedarse atascados hasta que alguien se percatara, mencionando específicamente la cinta como uno de los flujos posteriores afectados.

Eso no demuestra por qué el archivo estaba bloqueado. El debate original no identifica el proceso propietario, un antivirus, el comportamiento del almacenamiento, un componente de Veeam u otra causa, y tratar cualquiera de estas opciones como un hecho comprobado iría más allá de las pruebas disponibles.

El primer paso correcto es identificar al propietario en el momento del fallo. Recopila la sesión del trabajo, los registros de Veeam, los eventos de Windows, los registros del repositorio y la información de identificadores de archivo del sistema operativo antes de reiniciar los servicios. Si el bloqueo desaparece tras reiniciar, las pruebas pueden desaparecer con él.

Aquí es donde el monitoreo cobra valor. Un trabajo atascado que espera hasta el siguiente día hábil es muy distinto de un trabajo que emite una alerta tras un intervalo determinado sin progreso. El centro de almacenamiento de Mr.PlanB enfoca los sistemas de recuperación en torno al comportamiento operativo, y "¿cuánto tiempo puede pasar un trabajo sin avanzar antes de que alguien lo sepa?" es uno de esos comportamientos clave.

¿Por qué importan los fallos al eliminar checkpoints de Hyper-V?

Veeam Backup & Replication utiliza checkpoints de producción de Microsoft Hyper-V para realizar backups online en las versiones compatibles de Hyper-V. La documentación actual de Veeam 13 describe un proceso en el que Veeam solicita un checkpoint de producción, lee los datos de la VM y luego fusiona el checkpoint temporal de nuevo con la VM original tras el procesamiento.

Esto convierte los fallos diarios al eliminar checkpoints en algo más que mero ruido en la consola. Checkpoints residuales o que fallan repetidamente pueden consumir almacenamiento, complicar el estado de la VM e indicar que el proceso de backup no se completa de forma limpia.

El administrador de 2026 indicó que los fallos al eliminar checkpoints ocurrían todos los días. El soporte le pidió bajar CheckpointRemovalParallelism a 32 desde el valor predeterminado indicado de 64. El objetivo probable de ese experimento era modificar la cantidad de tareas de limpieza realizadas en paralelo, pero la fuente no demuestra el diagnóstico interno definitivo.

No copies ese valor solo porque apareció en un debate público. Tómalo como un ejemplo de resolución de problemas controlada: cambia una sola variable, reproduce la misma carga de trabajo y mide si el síntoma varía.

¿Qué conviene registrar antes de reiniciar los servicios de Veeam?

Recopila suficientes pruebas para responder a tres preguntas: qué está atascado, quién lo retiene y qué ocurrió inmediatamente antes del bloqueo.

En el lado de Veeam, exporta los detalles de la sesión del trabajo y los registros relevantes. Registra la compilación del servidor de backup, la del servidor de repositorio, los roles de proxy, el modo de transporte, el nombre del trabajo, el punto de restauración y las marcas de tiempo exactas.

Para Hyper-V, anota la VM, el host, el nodo del clúster, el estado del checkpoint, el almacenamiento disponible, los eventos de VSS y los eventos de Hyper-V VMMS. Si la VM migró entre nodos del clúster en torno al momento del fallo, incluye también ese dato.

En el caso de un archivo de repositorio bloqueado, identifica el identificador de proceso si es posible. Comprueba también si algún antivirus, EDR, servicio de indexación, deduplicación, replicación o software de almacenamiento está accediendo a la ruta del repositorio. Revisar estos elementos permite acotar el bloqueo del archivo, independientemente de si alguno termina estando involucrado o no.

Si la primera acción al solucionar problemas siempre es "reiniciar Veeam", el entorno puede recuperarse mientras la causa raíz permanece invisible.

¿Pueden los puntos de restauración inaccesibles generar más fallos de copia?

Sí. La documentación actual de Veeam advierte de que cuando los puntos de restauración de una cadena de backup resultan inaccesibles, las operaciones de copia de backup o de restauración que dependen de ellos pueden verse afectadas. El producto ofrece métodos específicos para olvidar o eliminar puntos ausentes de la configuración, con advertencias claras sobre la integridad de la cadena.

Esa documentación no debe confundirse con el caso reportado de bloqueo de archivos, ya que un archivo bloqueado no es automáticamente un archivo ausente. La conexión práctica es de carácter arquitectónico: los trabajos posteriores dependen de la integridad y accesibilidad de los puntos de restauración previos.

Por eso el monitoreo de backups debe supervisar cadenas completas además de los resultados de trabajos individuales. Un backup principal en verde no sirve de nada si la copia está atascada, una copia correcta no ayuda si la cinta nunca comienza, y una escritura completada en cinta no vale nada si nadie ha probado la restauración.

Para una plataforma de virtualización diferente, la guía de backup de Proxmox en Mr.PlanB establece la misma distinción entre crear copias de seguridad y demostrar la recuperación real.

¿Cómo aislar los fallos de checkpoints en un clúster?

Empieza con una única VM afectada y determina si el problema sigue a la máquina virtual o al host. Si los fallos ocurren solo en un nodo de Hyper-V, inspecciona el VSS, el almacenamiento, el nivel de parches y el estado de Hyper-V en ese nodo. Si la misma VM falla tras moverse a otro nodo, la propia VM o su carga de trabajo pasan a ser el punto de interés.

Separa también el procesamiento con reconocimiento de aplicaciones de la operación básica del checkpoint. Si una prueba simple con coherencia frente a caídas o sin reconocimiento de aplicaciones se comporta de forma distinta al trabajo habitual, eso permite acotar la capa afectada. No cambies la política de protección en producción de forma permanente solo para que el error desaparezca de la vista.

Comprueba el espacio libre donde se crean y fusionan los datos del checkpoint, busca checkpoints antiguos y archivos AVHDX residuales, y confirma que la latencia del almacenamiento no se dispare durante la ventana de fusión. Registra si el fallo ocurre durante el procesamiento del trabajo o después de que los datos de backup ya se hayan transferido.

Sobre todo, prueba un cambio a la vez. Los ajustes en el registro, los parches del host, el firmware del almacenamiento, las exclusiones de antivirus y los cambios en la concurrencia de trabajos no deberían aplicarse juntos en una misma ventana de mantenimiento, a menos que exista un motivo operativo independiente para hacerlo.

¿Por qué la cinta puede exponer un problema originado en otro lugar?

La cinta suele ubicarse en una fase posterior al backup en disco, por lo que puede convertirse en el lugar donde se manifiesta un fallo previo. En el entorno reportado, los trabajos en cinta leían desde backups en disco local y no extraían datos de S3, pero el administrador aún así veía que los trabajos en cinta se quedaban bloqueados cuando los archivos de backup estaban retenidos.

Ese detalle es útil porque demuestra por qué culpar a la vía de almacenamiento de objetos de cada síntoma sería simplista. Algunos fallos afectaban a la disponibilidad de los archivos locales de backup de forma independiente a la recuperación desde S3.

Dibuja el grafo de dependencias. El backup principal de la VM crea archivos, la copia de backup los consume, la cinta consume los backups locales y la retención y la limpieza modifican las cadenas más adelante. Cuando un trabajo se detiene, rastrea hacia atrás hasta encontrar la primera dependencia con problemas. Eso resulta mucho más fiable que leer el mensaje de error final y asumir que el último componente causó el fallo.

¿Qué corregiría primero en este entorno?

Priorizaría la visibilidad antes que los ajustes finos. Cada trabajo que pueda quedarse atascado necesita una alerta por falta de progreso, cada fallo diario de checkpoint necesita un recuento monitorizado por VM y por host, y cada bloqueo recurrente de archivos exige registrar la propiedad del proceso antes de reiniciar los servicios.

Luego reproduciría un fallo de checkpoint y un evento de bloqueo de archivos bajo una concurrencia reducida. Si el soporte pide modificar CheckpointRemovalParallelism, documenta el resultado del antes y el después. Si no se observa una mejora medible, restaura el valor original salvo que el fabricante indique lo contrario.

Por último, realizaría una restauración a partir de una cadena de backup que haya experimentado el problema. Lograr que la consola vuelva a mostrarse en verde importa menos que saber si la carga de trabajo protegida aún puede recuperarse limpiamente tras estas interrupciones reiteradas. Un trabajo atascado es deuda operativa, y los trabajos atascados a diario son un problema directo de fiabilidad.