¿Veeam es bloatware? Por qué los admins lo ven más difícil

Veeam sigue siendo un producto de copias de seguridad capaz, pero varias conversaciones entre administradores apuntan a un problema de complejidad cada vez mayor a su alrededor. Un usuario veterano llamó "bloatware frustrante" a la que había sido una de sus aplicaciones favoritas. Otro se quejó de que una actualización de la interfaz mostraba menos información en el mismo espacio de pantalla. Un tercero pasó diez minutos en la web de Veeam y aun así no fue capaz de identificar con seguridad el nombre del producto de backup que quería investigar.

Son tres quejas distintas, y tienen más sentido leídas juntas. La complejidad de un producto va más allá del número de funciones. Es toda la fricción que hay entre un administrador y la respuesta que necesita: qué producto comprar, qué pantalla usar, qué job falló, qué ajuste cambió y con qué rapidez puede recuperarse el operador cuando algo sale mal.

¿Qué quería decir el administrador al llamar bloatware a Veeam?

La queja más dura venía de un entorno Hyper V con unas 30 VMs repartidas en cinco o seis hosts. El administrador contó que Veeam había sido una de sus aplicaciones favoritas, pero que con los años se había vuelto tan frustrante que estaba buscando activamente un sustituto.

No decía que Veeam hubiera dejado de funcionar. La queja era por el tiempo que hacía falta para que cooperara. En operaciones de infraestructura esa diferencia cuenta, porque un producto puede estar lleno de funciones y funcionar bien técnicamente y, aun así, comerse demasiada atención del administrador.

Las respuestas no se pusieron de acuerdo en un sustituto obvio. Rubrik recibió muchos elogios, pero varias personas avisaron enseguida del precio. Commvault salió como una opción mucho más cara. Otros administradores defendieron Veeam y dijeron que las alternativas podían ser más difíciles de gestionar.

Esa reacción dice mucho, porque la complejidad es relativa. Una plataforma que parece inflada en una empresa con 30 VMs en Hyper V puede resultar adecuadamente capaz en una gran empresa que necesita muchos tipos de repositorio, restauraciones que entienden las aplicaciones, almacenamiento de objetos, cinta, cargas de trabajo en la nube, informes, separación de roles y controles de cumplimiento.

¿Por qué la nueva interfaz de Veeam enfadó a los administradores?

La queja sobre la interfaz era concreta: el mismo tamaño de letra, más espacio vacío, menos información visible y más desplazamiento para ver datos que antes cabían en una sola pantalla. El administrador no pedía letra más pequeña ni una interfaz fea. Quería una consola de operaciones que priorizara la densidad de información.

Muchos comentaristas estuvieron de acuerdo. Uno resumió la herramienta ideal de un sysadmin como una pantalla que mete información útil en un diseño ordenado en lugar de esconderla para que quede más limpia. Otros culparon al diseño responsive y a las interfaces pensadas para funcionar en pantallas de distintos tamaños.

Ese compromiso aparece por todas partes en el software moderno, pero las herramientas de infraestructura tienen requisitos poco habituales. Un operador de backup puede necesitar comparar a la vez el estado de los jobs, el de los repositorios, las marcas de tiempo, los avisos, la capacidad y los errores de muchos objetos, y el espacio en blanco de más tiene un coste real cuando empuja el quinto job fuera de la vista en pleno incidente.

La densidad máxima a cualquier precio tampoco sería el objetivo correcto. Lo que necesitan los operadores es una densidad que se pueda recorrer con la vista: datos relacionados agrupados, jerarquía conservada y suficiente contexto visible para que un operador con experiencia no tenga que abrir una cadena de paneles anidados.

¿Por qué la web de Veeam confundía incluso a un comprador de TI?

Un responsable de decisiones de TI en una organización mediana oyó hablar de las pruebas de recuperación automatizadas de Veeam y quiso saber más. Tras navegar por la web, dijo que ni siquiera sabía si el producto de backup seguía llamándose Veeam Backup & Replication o si lo habían renombrado dentro de Veeam Data Platform.

La conversación se dividió en dos bandos. Varios administradores coincidieron en que las webs de software empresarial actuales complican sin necesidad las preguntas básicas: qué hace el producto, cómo funciona y cuánto cuesta. Otros encontraron rápido la página de producto correspondiente y defendieron que la información estaba ahí.

Las dos cosas pueden ser ciertas. La documentación actual de Veeam sigue usando claramente el nombre Veeam Backup & Replication, y Veeam Data Platform es el paraguas más amplio de productos y la estructura de ediciones. Un usuario con experiencia que conoce los nombres puede ir directo a la documentación o a las descargas. Un comprador nuevo que llega desde la descripción de una función puede toparse con nombres de plataforma, ediciones, productos específicos por carga de trabajo, servicios de data cloud y páginas de marketing antes de llegar a la respuesta técnica. Esa complejidad para descubrir el producto golpea antes incluso de instalar el software.

¿Cómo se volvió Veeam más complicado?

Parte de la respuesta es el alcance. Veeam Backup & Replication protege hoy cargas de trabajo virtuales, físicas, en la nube, recursos compartidos de archivos y almacenamiento de objetos desde un entorno centralizado. La documentación actual describe copias de seguridad a nivel de imagen, protección de máquinas físicas, cargas de trabajo en la nube, recursos compartidos de archivos, repositorios de objetos, operaciones de restauración, replicación e integraciones alrededor del producto principal.

Un alcance más amplio trae más componentes, más asistentes, más dudas de licencias y más sitios donde la misma palabra significa algo un poco distinto según la carga de trabajo. Ese crecimiento puede merecer la pena cuando una empresa quiere una única plataforma de protección para varios tipos de infraestructura.

También puede crear un desajuste. Un entorno Hyper V pequeño quizá no saque provecho de la amplitud que necesita una gran empresa, pero el administrador sigue cargando con las consecuencias de la arquitectura del producto más grande aunque solo use una fracción de sus funciones.

La comparativa de backup para VMware y la guía de backup para Proxmox de Mr.PlanB muestran por qué esto importa al elegir plataforma. Compara las herramientas de backup con tu entorno real, no con el número máximo de funciones que un fabricante puede meter en una tabla.

¿Son de verdad más sencillas las alternativas?

A veces, aunque no siempre. El hilo sobre competidores chocaba una y otra vez con el mismo compromiso: los productos elogiados por dar una mejor experiencia suelen costar más, mientras que los más baratos pueden tener capacidades más limitadas u otras concesiones operativas.

Un administrador dijo que, tras usar ambos, Rubrik era el mejor producto, mientras que otro contó que otra plataforma empresarial había sido más difícil de gestionar y que por eso su equipo se pasó a Veeam. Otro comentarista señaló que muchas de las alternativas propuestas eran excesivas para un entorno de solo unas 30 VMs.

Es el contrapeso más útil a la acusación de bloatware. Sustituir Veeam porque parece demasiado grande puede dejarte en una plataforma más grande, más cara o menos conocida.

Antes de cambiar, mide la fricción. ¿Cuántos casos de soporte se abren cada trimestre? ¿Cuánto se tarda en diagnosticar un job fallido? ¿Cuántas pantallas exige una restauración habitual? ¿Cuántas funciones no se usan? ¿Cuánto tiempo del equipo se va en mantener proxies, repositorios, agentes, certificados y actualizaciones? Esas respuestas convierten el "bloat" de una sensación en un coste operativo.

¿Cuándo se convierte la complejidad de Veeam en un motivo para irse?

La complejidad pasa a ser un motivo de migración cuando reduce de forma real la confianza en la recuperación o consume más tiempo del equipo del que justifican las capacidades de la plataforma. Un producto puede ser molesto sin que merezca la pena sustituirlo, y la migración también tiene coste y riesgo.

Si el entorno sigue perdiendo horas por comportamientos inexplicables de los jobs, escalados al soporte, fricción en la interfaz o componentes que ya no encajan con la estrategia de infraestructura, comparar alternativas es lo racional. Si la queja es sobre todo que una pantalla nueva tiene más espacio en blanco, adaptarse probablemente sale más barato que reconstruir todo el entorno de backup.

Con los nombres de producto pasa lo mismo. Una web confusa es un problema de ventas y no dice nada sobre si las cadenas de backup son fiables.

Antes de decidir, ordena la fricción por categorías: descubrimiento del producto, licencias, interfaz, resolución de problemas, soporte, fiabilidad y capacidad de recuperación. Solo algunas justifican mover datos protegidos a una plataforma nueva.

¿Qué haría yo en un entorno Veeam pequeño que parece inflado?

Primero recortaría el entorno a las funciones que de verdad hacen falta. Elimina jobs abandonados y objetos de infraestructura obsoletos, documenta las rutas de restauración que importan y confirma si los repositorios, proxies, agentes y copias de backup siguen teniendo un propósito. Un despliegue de Veeam limpio puede resultar muy distinto de uno que ha acumulado años de experimentos y migraciones.

Después evaluaría una alternativa en un entorno de pruebas con las mismas tareas de recuperación: proteger una VM representativa, restaurar un archivo, recuperar un elemento de aplicación si hace falta, probar el comportamiento de la copia externa y medir el esfuerzo del operador.

Si la alternativa es claramente más sencilla para la carga de trabajo necesaria y los números cuadran, la migración tiene argumentos. Si el sustituto solo traslada la complejidad a un appliance nuevo, otras licencias y un proceso de soporte nuevo, la queja de bloatware sigue ahí con otro nombre.