Problema

En entornos donde Veeam Backup & Replication se ejecuta como appliance y los workers son VMs en Proxmox, es frecuente que, tras una actualización o una recreación de workers, los backups fallen porque los workers no pueden comunicarse con el servidor de backup. El síntoma típico es:

  • El test de conectividad del worker devuelve “OK”, pero la descarga del bundle local falla.
  • Los logs indican pérdida de la etiqueta VLAN configurada en la NIC del worker.
  • En algunos casos el worker se elimina automáticamente después de intentar descargar el bundle.

Este patrón se repite tanto después de actualizaciones de Veeam (por ejemplo, de 13 a 13.1) como al crear workers nuevos mediante el wizard de Veeam. El problema no está limitado a una versión concreta; cualquier combinación de Veeam appliance + Proxmox + NIC virtio puede presentar el mismo comportamiento.

Causa

  1. NIC virtio no soportada por el wizard de Veeam
    El asistente de creación de workers en Veeam elige virtio como modelo de interfaz por defecto. En Proxmox, virtio funciona bien para tráfico interno, pero cuando la NIC lleva una etiqueta VLAN (por ejemplo, VLAN 2) el driver puede perder la tag al reiniciar la VM o al aplicar una actualización del appliance.

  2. Pérdida de la VLAN tag al aplicar cambios de configuración
    Proxmox guarda la etiqueta VLAN en la definición de la interfaz. Si la NIC se vuelve a crear (por ejemplo, al reinstalar el worker) sin especificar explícitamente la tag, el motor de Proxmox la elimina. Veeam no vuelve a añadirla automáticamente.

  3. Incompatibilidad entre el modelo de NIC y el driver de red del appliance
    El appliance de Veeam está basado en Linux con un kernel optimizado para e1000/rtl8139. Cuando la NIC es virtio, el driver del appliance puede no reconocer correctamente la VLAN, provocando que el tráfico salga sin la tag o sea descartado por el switch.

  4. Comportamiento del wizard de Veeam al crear workers
    Después de crear la VM, Veeam ejecuta automáticamente una prueba de conectividad y, si falla la descarga del bundle, elimina la VM para evitar “workers huérfanos”. Si la NIC sigue siendo virtio, la prueba falla y el worker desaparece.

Solución

1. Forzar el uso de NIC modelo E1000 (o rtl8139) en los workers

Al crear o modificar un worker, especifica explícitamente el modelo de NIC y la VLAN tag. En Proxmox CLI:

qm set <VMID> -net0 model=e1000,bridge=vmbr0,tag=2

Reemplaza <VMID> por el ID de la VM del worker. Si la VM ya existe con una NIC virtio, elimina la interfaz y crea una nueva con el modelo correcto:

qm set <VMID> -delete net0
qm set <VMID> -net0 model=e1000,bridge=vmbr0,tag=2

2. Verificar la persistencia de la VLAN tag

Después de aplicar los cambios, revisa el archivo de configuración de la VM (/etc/pve/qemu-server/<VMID>.conf) y confirma que la línea net0 contiene tag=2. Si la tag desaparece tras un reinicio, añade la opción tag=2 al script de arranque del worker o crea una plantilla de VM con la NIC ya configurada.

3. Desactivar la auto‑eliminación del worker en Veeam

En la versión 13.1 el wizard sigue intentando borrar workers que fallan la descarga del bundle. La forma más sencilla de evitarlo es desactivar temporalmente la prueba automática:

  1. Accede al WebGUI del appliance Veeam.
  2. Navega a Configuration → Workers.
  3. Desmarca la opción “Run test after creation”.
  4. Guarda y crea el worker.

Una vez creado, cambia la NIC a E1000 y vuelve a ejecutar manualmente la prueba desde la UI.

4. Aplicar los mismos pasos después de una actualización de Veeam

Las actualizaciones de Veeam pueden volver a sobrescribir la definición de la NIC del worker. Después de cada upgrade:

  • Revisa los workers existentes con qm list | grep worker.
  • Ejecuta el comando qm set para re‑aplicar el modelo E1000 y la VLAN tag.
  • Ejecuta la prueba de conectividad y, si pasa, ejecuta una copia de seguridad de prueba.

5. Automatizar la corrección con un script de post‑upgrade

Para entornos con varios workers, crea un script que recorra todos los IDs y aplique la configuración correcta:

#!/bin/bash
for vmid in $(qm list | awk '/worker/ {print $1}'); do
  qm set "$vmid" -net0 model=e1000,bridge=vmbr0,tag=2
  echo "Worker $vmid configurado con E1000 y VLAN 2"
done

Ejecuta este script justo después de la actualización de Veeam o después de crear nuevos workers.

Cuándo aplicar esta solución

  • Síntomas: backups fallan después de crear o actualizar workers, logs indican “cannot download bundle”, o la VM del worker desaparece automáticamente.
  • Entorno: Veeam Backup & Replication appliance (versión 13 o 13.1) con workers desplegados como VMs en Proxmox, y uso de VLANs en la red de backup.
  • Exclusiones: si la infraestructura usa exclusivamente interfaces de tipo e1000 o rtl8139 desde el inicio, el problema no se presentará; la solución no es necesaria. Asimismo, si la red de backup no depende de VLANs, la pérdida de la tag no afecta.

Verificación

  1. Comprobación de la NIC

    qm config <VMID> | grep net0

    Debería devolver algo como net0: e1000=00:11:22:33:44:55,bridge=vmbr0,tag=2.

  2. Test de conectividad desde Veeam
    En el WebGUI, selecciona el worker y pulsa “Test”. El resultado debe ser “Success” y la descarga del bundle debe completarse sin errores.

  3. Ejecución de backup real
    Inicia una tarea de backup que incluya al menos una VM protegida por el worker. Verifica que el job finaliza con estado “Success”.

  4. Persistencia tras reinicio
    Apaga y enciende el worker (qm shutdown <VMID> y qm start <VMID>). Repite el paso 1 para confirmar que la tag sigue presente.

Notas adicionales

  • En algunos hipervisores, la opción tag solo funciona con puentes (bridge) configurados en modo VLAN aware. Asegúrate de que vmbr0 tenga vlan-aware: yes en /etc/network/interfaces.
  • Si tu entorno requiere alta disponibilidad, considera crear una plantilla de worker con la NIC ya configurada como E1000 y la VLAN tag. Así cada nuevo worker hereda la configuración correcta y evita la fase manual.
  • Los logs de Veeam (/opt/veeam/Backup/Logs/Worker.log) suelen contener la cadena “VLAN tag missing” cuando la NIC virtio pierde la etiqueta. Busca esa frase para confirmar la causa antes de aplicar la solución.
  • En caso de que la red de backup use trunking y múltiples VLANs, repite el proceso para cada VLAN necesaria, creando interfaces adicionales (net1, net2, …) con sus respectivas tags.