Soporte de Veeam: cuándo seis meses ya es demasiado

Un caso de soporte de copias de seguridad de seis meses es demasiado tiempo cuando el problema sin resolver sigue interrumpiendo los flujos normales de protección. En un entorno de Veeam de 2026, el administrador informó de fallos repetidos en S3, errores de organización por niveles en Scale-Out Backup Repository, archivos de backup bloqueados, tareas de cinta atascadas y errores diarios al eliminar checkpoints. Para entonces, la queja había pasado de ser un simple ticket a una pérdida de confianza en el sistema de recuperación.

Por la descripción del administrador, no se trataba de un laboratorio pequeño. Indicó que disponía de almacenamiento de objetos tanto en el centro de datos principal como en un sitio de recuperación ante desastres, con fibra dedicada de 10 Gb entre sitios y un rendimiento medido de aproximadamente 900 a 980 MB/s hacia cada appliance. El soporte de Veeam había solicitado modificaciones en el registro y registros adicionales, pero los fallos operativos continuaban, y en ese punto un problema de soporte se transforma en un problema de infraestructura.

¿Cuándo se convierte un soporte lento en un riesgo para el backup?

El soporte lento se convierte en un riesgo para las copias de seguridad cuando las tareas fallidas siguen sin resolverse el tiempo suficiente como para que los operadores dejen de confiar en la cadena de protección. Un producto de backup es un software peculiar porque el fallo puede permanecer oculto hasta el día en que hace falta restaurar, lo que encarece cualquier incertidumbre.

El administrador que inició la conversación describió múltiples síntomas, mucho más allá de un fallo estético o de un asistente confuso, que afectaban al almacenamiento de objetos, las copias de backup, la cinta y la limpieza de checkpoints de Hyper-V. Algunas tareas se quedaban atascadas hasta que alguien se daba cuenta, de modo que el monitoreo humano se había convertido en parte del flujo de trabajo de copia de seguridad.

Existe una diferencia práctica entre una experiencia de soporte molesta y una que resulta insegura. Una respuesta retrasada sobre el formato de un informe puede esperar. Una condición recurrente que bloquea el backup copy, retrasa la cinta o hace que la limpieza de checkpoints falle a diario merece una vía de escalación definida.

La comparativa de backup para Proxmox de Mr.PlanB plantea ese mismo enfoque centrado en la recuperación desde otra plataforma. Las listas de funciones importan, pero la plataforma se gana su puesto solo cuando los operadores pueden explicar cómo se detecta, se diagnostica y se restaura una tarea fallida a un estado correcto conocido.

¿Qué pruebas debe incluir una escalación de Veeam?

Una escalación útil debe contener una cronología que otro ingeniero pueda reproducir. Lo más sólido de la queja de 2026 fue la cantidad de detalles operativos que el administrador acabó facilitando.

El almacenamiento S3 estaba on premises en dos ubicaciones. La ruta de recuperación ante desastres utilizaba fibra dedicada de 10 Gb. Las pruebas de rendimiento alcanzaron aproximadamente de 900 a 980 MB/s hacia cada appliance. Existían varios buckets, cada uno limitado a un máximo de dos tareas. La mayoría de las copias primarias se guardaban en disco local y luego se copiaban a S3 mediante tareas de backup copy. Las tareas de cinta leían del disco local en lugar de recuperar los datos desde el almacenamiento de objetos.

El soporte también había pedido modificaciones en la ruta del registro de Veeam Backup & Replication. El administrador redujo CheckpointRemovalParallelism del valor predeterminado indicado de 64 a 32, activó S3VerboseLoggingMode y aumentó S3RequestTimeoutSec del valor predeterminado indicado de 120 segundos a 600 segundos.

Esos valores no deben copiarse a ciegas en otro entorno. Tienen valor como prueba de que el soporte ya había superado el diagnóstico de primer nivel y estaba evaluando la concurrencia, el nivel de detalle de los registros y el comportamiento de los tiempos de espera.

¿Por qué "la red es rápida" no es una prueba suficiente?

Una prueba de rendimiento rápida no demuestra que un flujo de trabajo con almacenamiento de objetos esté sano, aunque sí implica que una explicación simple como "la WAN va lenta a todas luces" necesita más justificación.

El almacenamiento de objetos se comporta de forma muy distinta a una copia de archivos secuencial de gran tamaño. Veeam gestiona metadatos y objetos de datos de copia de seguridad, y la documentación actual de Veeam describe el almacenamiento de objetos como un destino compatible para tareas de backup, tareas de backup copy y niveles de Scale-Out Backup Repository. Por tanto, la carga de trabajo puede implicar numerosas operaciones de API, actualizaciones de metadatos, creación de objetos, lógica de retención y concurrencia de tareas.

Al resolver problemas, ten en cuenta que una transferencia masiva a 900 MB/s puede parecer excelente mientras la carga de trabajo sigue sufriendo latencia en las peticiones, limitaciones de tasa (throttling), tiempos de espera agotados, contención de metadatos, comportamiento propio del almacenamiento o una ruta de software que falla bajo concurrencia.

Un buen plan de pruebas separa las capas. Confirma primero las pérdidas básicas y la latencia de red, luego el comportamiento de DNS y TLS, y después el estado del almacenamiento de objetos con el fabricante del storage. Reproduce el fallo con un único bucket y una sola tarea antes de elevar la concurrencia, y compara flujos de trabajo exclusivos sobre disco local frente a flujos respaldados por objetos.

El artículo de Mr.PlanB sobre el coste real y el comportamiento del almacenamiento tipo S3 aporta un contexto útil, ya que el almacenamiento de objetos tiene supuestos operativos distintos a los del almacenamiento de bloques local. Tratar cada incidencia como un problema de ancho de banda oculta esas diferencias.

¿Deben tratarse los cambios de registro de soporte como soluciones definitivas?

No. Trata cualquier cambio de registro solicitado durante el diagnóstico como un experimento hasta que los resultados demuestren lo contrario. Cada cambio necesita un responsable, un motivo, el valor original, el valor nuevo, la fecha y una condición de reversión.

El diagnóstico de emergencia se acumula, y por eso esta disciplina merece el esfuerzo. Seis meses después, un entorno puede albergar varios parámetros ocultos de los que nadie se acuerda. Una actualización futura puede comportarse de manera distinta debido a un ajuste introducido durante un caso antiguo. Otro ingeniero puede ver ese valor no predeterminado y asumir que forma parte del diseño soportado.

En el entorno reportado se apreciaban tres cambios: menor paralelismo en la eliminación de checkpoints, registro detallado de S3 y un tiempo de espera de petición S3 más prolongado. Cada uno apunta a una hipótesis, y ninguno demuestra por sí solo la causa raíz.

Tras cada cambio experimental, ejecuta la misma carga de trabajo de prueba y registra si el síntoma cambia. Si el fallo se vuelve menos frecuente, es una prueba. Si nada cambia, restaura el valor original a menos que el soporte indique de forma explícita que el ajuste debe permanecer.

¿Cómo saber cuándo conviene probar una alternativa?

Prueba una alternativa cuando la plataforma actual sufra un problema material de fiabilidad y no exista un plazo creíble para resolverlo. Hacer pruebas dista mucho de migrar producción de inmediato.

Empieza con una prueba de concepto representativa. Protege una máquina virtual, una carga de trabajo de aplicación, una copia externa y una ruta de restauración. Incluye cinta, almacenamiento de objetos y clústeres de failover si tu entorno depende de ellos, y luego compara el esfuerzo operativo necesario para lograr el mismo resultado de recuperación.

La conversación en torno a la queja sobre Veeam mencionó varias alternativas, pero la prueba importa más que los nombres de los productos. Un reemplazo que parezca más limpio durante la instalación puede fallar igualmente en el primer ejercicio serio de recuperación. Otro producto puede resolver el problema específico con S3 a cambio de encarecer las licencias, exigir nuevos appliances o imponer un modelo de soporte más complejo.

Utiliza el centro de almacenamiento de Mr.PlanB para analizar la parte de almacenamiento de forma independiente a la elección del software de backup. Los medios del repositorio, el almacenamiento de objetos, la cinta y el diseño de la red pueden generar síntomas que parecen fallos de la propia aplicación de copia de seguridad.

¿Qué haría yo tras seis meses sin una solución?

Dejaría de tratar la situación como un único ticket de soporte y crearía un informe técnico similar al de un incidente grave, con la compilación exacta de Veeam, el firmware del almacenamiento, la ruta de red, la estructura de buckets, los tipos de tareas que fallan, los registros, los cambios en el registro de Windows, las marcas de tiempo de los fallos y el último periodo en el que todo funcionó correctamente.

A continuación pondría en marcha dos vías simultáneas. La primera sería una escalación formal con un único fallo reproducible y la exigencia de un siguiente paso de diagnóstico claro; la segunda, una pequeña prueba de sustitución utilizando la misma carga de trabajo y los mismos requisitos de restauración.

También eliminaría dependencias ocultas basadas en que alguien "se dé cuenta" de una tarea atascada. Las alertas deberían identificar la organización por niveles fallida, las copias detenidas, los retrasos en cinta y los problemas de limpieza de checkpoints antes de la siguiente jornada laboral.

Una mala interacción con el soporte resulta frustrante, pero seis meses de inestabilidad sin resolver en la infraestructura de recuperación representan un problema mayor. En ese punto, la organización necesita pruebas de que la plataforma actual puede volver a ser fiable, o pruebas de que otra plataforma puede hacer el trabajo mejor.