Restauraciones lentas en Proxmox: 8 cuellos de botella

Una restauración lenta en Proxmox suele ser un problema de todo el recorrido que ningún ajuste de Proxmox por sí solo va a arreglar. La velocidad efectiva de restauración la limita la etapa más lenta entre el repositorio de copias de seguridad, el worker de backup, la red y el almacenamiento de destino en Proxmox.

Mide esas etapas antes de cambiar la MTU, añadir tarjetas de red o culpar al hipervisor. Un enlace de 25 GbE no garantiza una restauración a 25 GbE si un núcleo de CPU, un repositorio con deduplicación o el datastore de destino ya están saturados.

Esta guía surgió a raíz de un informe en el foro de I+D de Veeam en agosto de 2026, en el que una restauración en Proxmox rondaba los 500 Mbps pese a tener enlaces duales de 25 GbE y almacenamiento NVMe rápido. Es el informe de un solo operador y no debe leerse como un límite universal de Veeam. El método de diagnóstico de abajo se basa en la documentación actual de Veeam sobre los workers de Proxmox y en las indicaciones de almacenamiento de Proxmox, en lugar de suponer que el caso del foro tiene un único arreglo mágico.

¿Qué deberías medir antes de ponerte a diagnosticar?

Mide a la vez el rendimiento de lectura del repositorio, la CPU del worker, la RAM del worker, el rendimiento de la red y la latencia de escritura del almacenamiento de destino. Una cifra de velocidad de restauración por sí sola no identifica el cuello de botella.

Anota cinco valores durante una restauración representativa:

1. El rendimiento de restauración que indica el trabajo de copia de seguridad.
2. El uso de CPU por núcleo en el worker y en el servidor de backup.
3. El rendimiento de red en el worker y en el host Proxmox.
4. El rendimiento de lectura y la latencia en el repositorio de copias de seguridad.
5. El rendimiento de escritura y la latencia en el almacenamiento de destino.

Haz la misma prueba con una sola VM grande antes de probar varias restauraciones simultáneas, porque la concurrencia puede ocultar el comportamiento de una única ruta de datos.

Si todavía estás decidiendo cómo proteger el entorno, la guía de backup de Proxmox compara los enfoques principales antes de que optimices el rendimiento de las restauraciones.

1. ¿Está el worker de Veeam para Proxmox limitado por CPU?

El worker es el primer sitio donde yo miraría cuando la capacidad de red es alta pero el rendimiento de restauración es inesperadamente bajo. Veeam dice que los workers de Proxmox procesan las cargas de backup y distribuyen el tráfico de copias de seguridad entre el entorno virtual y los repositorios.

El tamaño predeterminado documentado del worker es de 6 vCPU, 6 GB de RAM y 100 GB de disco. Un worker predeterminado puede gestionar hasta 4 tareas simultáneas de copia de seguridad y restauración.

Las seis vCPU no van a estar necesariamente igual de ocupadas en cada restauración, así que mira el uso por núcleo. Una vCPU saturada con los demás núcleos casi ociosos es un problema distinto de tener los seis núcleos al 80 por ciento.

Si la CPU es el techo, recoge los logs del trabajo y las métricas del worker antes de cambiar ajustes no documentados. Veeam advierte expresamente de que no se modifiquen a mano las VM de los workers en la interfaz de Proxmox y remite a los administradores a editar los ajustes del worker desde Veeam.

Así que comprueba si la CPU del worker se estanca en el mismo momento que el rendimiento.

2. ¿Están los límites de tareas simultáneas creando contención?

Más tareas no significan automáticamente más rendimiento total, y pueden empeorar la latencia del almacenamiento, la contención de CPU y las colas de red.

Veeam documenta un máximo predeterminado de 4 tareas simultáneas de copia de seguridad y restauración por worker. Por cada tarea adicional, sus indicaciones de dimensionamiento piden 1 vCPU y 1 GB de RAM más.

Haz dos pruebas: primero restaura una VM y luego varias. Si una VM se restaura a 800 Mbps y cuatro VM juntas siguen dando más o menos 800 Mbps, probablemente hay un recurso compartido saturado. Si el rendimiento total escala de forma significativa, el factor limitante puede ser la ruta de una sola tarea.

Revisa también el lado del repositorio, ya que un repositorio de copias de seguridad tiene sus propios límites de concurrencia y de recursos. Un worker de Proxmox perfectamente dimensionado no puede leer los datos más deprisa de lo que el repositorio es capaz de servirlos.

3. ¿Es el repositorio de copias de seguridad el verdadero cuello de botella?

Un repositorio puede ser lento aunque sus discos parezcan rápidos sobre el papel. La deduplicación, la compresión, la recuperación de objetos, el comportamiento de la caché, la fragmentación y los trabajos simultáneos pueden cambiar el rendimiento de la restauración.

Prueba el repositorio por separado de Proxmox si tu software de backup te ofrece una forma admitida de hacerlo. Mira el rendimiento de lectura física, la latencia y la CPU del repositorio durante la ventana de restauración.

Las lecturas de backup se comportan de forma distinta a un benchmark secuencial con una herramienta sintética, porque una restauración puede tener que reconstruir los datos a partir de cadenas de backup comprimidas o deduplicadas antes de que nada llegue a Proxmox. Si el repositorio está al máximo, ajustar el hipervisor de destino no servirá de nada.

4. ¿Usa el worker la ruta de red que crees?

Tener una tarjeta de red rápida en la máquina demuestra poco, así que confirma la ruta real que sigue el tráfico de restauración. Veeam admite conectar los workers de Proxmox a varias redes y documenta expresamente el uso de una red concreta para la transferencia hacia y desde los repositorios de copias de seguridad. Es útil cuando las redes de gestión, backup y producción están separadas.

Revisa los contadores de interfaz del worker mientras se ejecuta el trabajo, y también los del host Proxmox. Verifica el enrutamiento, las VLAN, la negociación del enlace y si el tráfico atraviesa un firewall o un segmento enrutado más lento.

Revisa también las reglas de tráfico de red de Veeam. La limitación de tráfico existe precisamente para acotar cuánto ancho de banda consumen los trabajos, y una regla olvidada puede hacer que una infraestructura rápida parezca misteriosamente limitada.

Yo no empezaría por las jumbo frames. Demuestra primero que los dos extremos usan la interfaz esperada y que no hay ninguna limitación explícita.

5. ¿Está saturado el almacenamiento de destino en Proxmox?

El almacenamiento de destino tiene que absorber los discos de VM reconstruidos. Un gran ancho de banda de red no sirve de nada si el datastore solo aguanta una fracción de esa tasa de escritura con el patrón de E/S actual, así que vigila el propio destino además del host.

En ZFS local, mira la latencia del pool y el comportamiento de los dispositivos. En Ceph, revisa la salud del clúster, el uso de los OSD, la actividad de recuperación y la contención de red. En NFS o iSCSI compartidos, revisa tanto el lado iniciador de Proxmox como la cabina de almacenamiento.

Las indicaciones de Proxmox para Ceph recomiendan redes de almacenamiento rápidas y SSD o NVRAM adecuados cuando importa el rendimiento. La arquitectura exacta importa más que la etiqueta "Ceph".

Si no tienes claro qué hace Ceph dentro de Proxmox, empieza por qué es Proxmox Ceph.

Una prueba de diagnóstico útil es restaurar la misma VM en otro backend de almacenamiento. Si la velocidad cambia mucho, has acotado el problema.

6. ¿Te estás topando con una limitación de formato o de almacenamiento en la restauración?

La compatibilidad también puede afectar a la ruta de restauración. El documento actual de limitaciones de Veeam para Proxmox enumera casos no admitidos, entre ellos BTRFS y el almacenamiento de destino personalizado para restaurar VM.

También documenta una interacción importante de Proxmox VE 9 con los snapshots como cadenas de volúmenes. Las VM que usan una versión anterior de QEMU no se pueden restaurar en un almacenamiento con el ajuste correspondiente de cadena de volúmenes activado, en el escenario que describe Veeam. No trates cada fallo o cada ruta lenta como un simple problema de rendimiento.

Anota la plataforma de origen, el formato del disco de origen, el tipo de almacenamiento de destino, el firmware del invitado, la generación de QEMU y si la VM viene de VMware o de otro hipervisor. Una restauración entre plataformas puede implicar trabajo de conversión de drivers y discos que una restauración nativa no tiene.

Cuanto más inusual sea la VM, más importante es probarla antes de una caída real.

7. ¿Compite la restauración con la recuperación de Ceph, el backup o el tráfico de migración?

Una restauración suele ejecutarse en el peor momento posible. Ha fallado un nodo, Ceph está rebalanceando, los usuarios esperan y alguien lanza tres trabajos de recuperación más porque el primero parece lento, lo que convierte un cuello de botella manejable en un incidente.

Separa el tráfico de recuperación del almacenamiento del tráfico de restauración de VM donde tu diseño lo permita. Vigila la salud de Ceph y la actividad de backfill. Comprueba si los trabajos de backup, la replicación, las operaciones de scrub o las migraciones en vivo usan los mismos enlaces.

Si el entorno está degradado, deja de perseguir el máximo rendimiento de benchmark y recupera primero, de forma estable, las cargas de trabajo más importantes.

La guía de almacenamiento de Mr.PlanB puede ayudarte si el clúster obliga de forma habitual a que el tráfico de backup, migración y almacenamiento pase por el mismo diseño limitado.

8. ¿Deberías usar Instant Recovery en lugar de esperar a una restauración completa?

A veces la optimización correcta es cambiar el objetivo de recuperación. Veeam admite Instant Recovery a Proxmox VE, que permite ejecutar una carga de trabajo directamente desde un backup comprimido y deduplicado mientras continúa el proceso de recuperación.

Eso puede reducir el tiempo hasta que un servicio vuelve a estar disponible, aunque no haga más rápida la transferencia de almacenamiento subyacente.

Hay una contrapartida: ejecutar desde el almacenamiento de backup no se comporta igual que ejecutar en el datastore de producción definitivo, y el rendimiento durante el estado temporal depende del repositorio de copias de seguridad y de la arquitectura de recuperación.

Usa Instant Recovery cuando el tiempo de recuperación importe más que el rendimiento estable inmediato. Usa una restauración completa cuando la carga de trabajo pueda seguir fuera de línea el tiempo suficiente para aterrizar directamente en su almacenamiento definitivo.

¿Qué cambiaría yo primero?

No cambiaría nada hasta haber capturado una sola restauración con la CPU del worker, las lecturas del repositorio, el rendimiento de red y las escrituras de destino en una misma línea temporal. El primer componente que se satura cuando el rendimiento se aplana es tu principal sospechoso.

Si el worker está al máximo, investiga con Veeam el dimensionamiento del worker y el comportamiento del software. Si lo está el repositorio, arregla el repositorio. Si la red está limitada, rastrea la ruta real y las reglas de tráfico. Si se dispara la latencia del almacenamiento, trabaja sobre el datastore de destino.

Solo experimentaría con la MTU, el paralelismo y ajustes más profundos una vez que exista esa referencia.

Una prueba de restauración tiene éxito cuando demuestra el objetivo de recuperación, acabe en el panel la cifra que acabe. Si el negocio necesita recuperar una VM en 15 minutos, diseña y prueba para ese resultado, y recuerda que un puerto de 25 GbE es solo un componente de un camino más largo.