¿Ejecutas PBS en el mismo host? Por qué tus backups van lentos

Tienes un servidor impresionante con 24 núcleos, 256 GB de memoria DDR5 y un disco NVMe Gen5 para centro de datos capaz de dejar atrás a casi cualquier SSD sin despeinarse. Y aun así... tu Proxmox Backup Server (PBS) avanza a unos penosos 200MB/s al respaldar máquinas virtuales. ¿Qué está pasando?

Este es justo el quebradero de cabeza con el que se topó un usuario tras decidir alojar PBS dentro de una VM en el mismo nodo de Proxmox que pretendía respaldar. Sobre el papel, la configuración prometía un rendimiento descomunal. En la práctica, la gráfica de velocidad recordaba más a una tortuga en una cinta de correr.

A continuación analizamos por qué ocurre esto y por qué ninguna cantidad de potencia bruta en hardware puede librarte de cuellos de botella virtuales si te descuidas.

El problema: cuando el hardware puntero rinde por debajo de lo esperado

En este caso, el servidor cumplía todos los requisitos de rendimiento: almacenamiento NVMe ultrarrápido (Kingston DC3000ME Gen5), memoria de sobra y margen de CPU para dar y tomar. No había carga apreciable en el sistema ni cuellos de botella evidentes de E/S, y sin embargo las copias de seguridad se estancaban en torno a 350MB/s de lectura y escritura.

Lo peor era que las especificaciones oficiales de la unidad prometían más de 10,000MB/s en ambas direcciones. Uno espera backups instantáneos, no un atasco monumental. ¿Adónde se estaba yendo toda esa velocidad?

La red de la VM: el primer sospechoso

Aquí llega el punto revelador: ejecutar PBS dentro de una VM en el mismo host de Proxmox obliga a que todo el tráfico de backup viaje a través de capas virtualizadas, incluidas tarjetas de red virtuales que pueden mermar el rendimiento sin dejar rastro visible.

El usuario de Reddit sospechó de esto y no se equivocaba. La interfaz de red virtual (probablemente configurada por defecto como VirtIO) introduce una sobrecarga que, al respaldar cientos de gigabytes, se nota con fuerza. Las interfaces virtuales no siempre alcanzan el mismo rendimiento que las físicas nativas, especialmente si no se optimizan con soporte multiqueue o tramas jumbo (MTU 9000).

Otro participante en el debate aportó una recomendación: iguala el valor multiqueue de tu tarjeta de red al número de vCPU y sube el tamaño de la MTU. Puede que no suene a fórmula mágica, pero a menudo ofrece mejoras inmediatas.

La sobrecarga de LVM y el disco virtual

Un análisis más detallado de la configuración revela que la VM de PBS utiliza un disco virtual SCSI con emulación de SSD activada, montado sobre LVM. Suena atractivo, pero es una capa de abstracción de más. El rendimiento suele resentirse cuando mueves datos entre múltiples volúmenes virtualizados, en especial cuando los flujos de lectura y escritura se cruzan entre diferentes niveles de LVM.

Aunque SCSI funciona bien en general, canalizar una E/S pesada por este conducto virtual sobre un LVM en el host añade latencia tanto en lectura como durante la amplificación de escritura, las sincronizaciones y la compresión. Y todo esto antes de entrar a considerar la carga de trabajo que suponen la deduplicación y la división en bloques propia de PBS.

¿CPU y RAM? Probablemente no sean el problema

El sistema apenas registraba un 30% de uso de CPU y un 3% de consumo de RAM durante la copia, de modo que la falta de potencia bruta no era el problema.

Lo que probablemente estás presenciando es un cuello de botella a nivel de software, donde la E/S virtualizada y los mecanismos internos de PBS no se entienden bien. Si la CPU apenas trabaja, el bloqueo suele originarse antes en el trayecto, casi siempre en la ruta de datos entre la VM de origen y el almacenamiento de PBS.

La alternativa: instalación bare metal o híbrida

Varios comentarios en el hilo coincidían en la misma duda: «¿Por qué no instalar PBS directamente en el nodo de Proxmox?».

Resulta que es posible y además muy eficiente. Puedes instalar PBS junto a Proxmox en el mismo servidor físico mediante un simple comando apt install proxmox-backup-server tras añadir el repositorio correspondiente. De este modo, PBS accede de forma directa al disco y te ahorras por completo la sobrecarga de la VM.

Si no quieres optar por una instalación bare metal completa, una alternativa híbrida con contenedores LXC y bind mounts puede ser el punto intermedio idóneo. Un usuario destacó el mejor rendimiento de PBS en un LXC frente a una VM completa, probablemente porque los contenedores prescinden de las capas de disco virtual y acceden directamente al almacenamiento del host.

«¿Y si se muere el nodo?»

Es una inquietud comprensible. Ejecutar PBS y Proxmox en el mismo servidor parece arriesgado, porque si el host falla por completo, ¿qué ocurre con tus copias de seguridad?

Aquí es donde entra en juego una buena disciplina de almacenamiento. Varios usuarios solucionan esto alojando el almacenamiento de los backups en una unidad de disco totalmente independiente, aislada del disco del sistema de Proxmox. De ese modo, aunque el sistema operativo quede inutilizable, puedes reinstalar y montar de nuevo tu volumen de copias sin perder ningún dato.

Otros van más allá y despliegan múltiples instancias de PBS en nodos separados, sincronizando las copias entre ellas. Es cierto que resulta más complejo, pero aporta redundancia real, y la tranquilidad lo compensa con creces.

Pruebas con FIO: medir en lugar de adivinar

¿Quieres datos concretos? Un participante con experiencia compartió un comando de FIO para medir el rendimiento real del disco desde dentro de la VM de PBS. Esta prueba te permite comprobar si el cuello de botella está en la E/S de disco o en otra parte.

Este es el tipo de comando recomendado:

fio --name=seq-read128k --ioengine=io_uring --rw=read --bs=128k --size=2g --numjobs=8 --iodepth=64 --runtime=20 --time_based --group_reporting

Ejecútalo dentro de tu VM y compara el resultado con el rendimiento en el host. Si la VM es significativamente más lenta, ya has localizado al culpable.

En resumen: por qué tu VM de PBS va lenta

• La sobrecarga de la tarjeta de red virtual puede limitar el rendimiento. Prueba con tramas jumbo (MTU 9000) y multiqueue.
• Un disco virtual sobre LVM añade latencia innecesaria. Valora el acceso directo al disco o los bind mounts.
• Ejecutar PBS en una VM dentro del mismo nodo hace que el tráfico de backup pase por capas virtuales redundantes.
• Instalar PBS en el host (bare metal o en contenedor) suele ser más rápido y a veces más simple.
• Discos separados para el sistema y para el almacenamiento de backup reducen riesgos y mejoran la velocidad.
• Realizar pruebas con FIO te muestra los límites reales de tu E/S.

Reflexiones finales

Alojar PBS dentro de una VM parece una forma elegante de mantener las cosas modularizadas. En la práctica, sin embargo, suele provocar cuellos de botella de rendimiento que malgastan tu tiempo y el potencial de tu hardware.

Si te estás dando contra el mismo muro de velocidad, examina con lupa cómo has organizado las capas de tu infraestructura. A veces la solución no pasa por añadir más hardware, sino por eliminar las capas intermedias que te están frenando.