Veeam con S3 y SOBR: por qué fallan los trabajos de tiering

Los fallos de tiering con S3 y SOBR en Veeam pueden persistir incluso cuando las pruebas de red más evidentes parecen correctas. Un administrador reportó en 2026 seis meses de problemas sin resolver mientras sus appliances S3 locales aún alcanzaban rendimientos de prueba de entre 900 y 980 MB/s sobre un enlace dedicado de 10 Gb en el centro de datos.

El informe no demuestra que S3 sea poco fiable ni que Veeam sea incapaz de utilizar almacenamiento de objetos, y la documentación actual de Veeam Backup & Replication 13 respalda explícitamente el almacenamiento de objetos compatible con S3 y los niveles de capacidad de Scale-Out Backup Repository. Lo que este caso pone de manifiesto es que el backup hacia almacenamiento de objetos cuenta con más piezas móviles de las que una simple prueba de ancho de banda puede validar.

¿Qué fallaba realmente en el entorno de Veeam con S3?

El administrador describió fallos repetidos en los flujos de trabajo de tiering y copias de backup de Veeam Scale-Out Backup Repository. El almacenamiento de objetos estaba implementado de forma local en el centro de datos principal y en una sede de recuperación ante desastres. Una conexión dedicada de fibra de 10 Gb unía ambas ubicaciones para la replicación de datos.

El diseño utilizaba múltiples buckets y el administrador limitó cada bucket a un máximo de dos trabajos. La mayoría de los trabajos de backup principales tenían como destino inicial el disco local, y luego los trabajos de copia de backup transferían los datos de protección hacia S3. Los trabajos en cinta permanecían en la ruta de disco local y no leían datos desde S3.

Esa topología acota el problema. El administrador no ejecutaba cada backup directamente contra un bucket remoto en la nube sobre un enlace deficiente de internet. El backup en disco local formaba parte del diseño, mientras que la capa de objetos generaba complicaciones durante las operaciones de copia secundaria y de tiering.

El soporte de Veeam solicitó un registro detallado de S3 y un incremento de S3RequestTimeoutSec a 600 segundos frente al valor predeterminado indicado de 120. Tras seis meses con el caso abierto, el administrador todavía no consideraba estable el entorno.

¿Por qué 900 MB/s pueden ocultar un problema en el almacenamiento de objetos?

El rendimiento bruto es solo una de las propiedades de la conexión. Una prueba de transferencia masiva responde a "¿con qué rapidez puede cruzar este enlace un flujo grande bajo estas condiciones?", pero deja sin respuesta "¿cómo se comporta este almacenamiento a lo largo de miles de operaciones de objetos y metadatos bajo la concurrencia propia del backup?".

La documentación actual de Veeam describe los niveles de capacidad como extensiones de almacenamiento de objetos vinculadas a un Scale-Out Backup Repository. Los datos de backup pueden copiarse o moverse allí, y la extensión de capacidad mantiene bloques de datos, metadatos, información de checkpoints y otros objetos auxiliares.

Esa estructura genera múltiples capas potenciales de fallo. La red puede sufrir pérdidas de paquetes o picos de latencia, el appliance de objetos puede ralentizarse bajo la carga de metadatos y las peticiones a la API pueden agotar su tiempo de espera. El DNS o TLS pueden fallar de forma intermitente, el firmware del almacenamiento puede comportarse de manera errática con concurrencia alta y un componente de Veeam puede toparse con un caso límite. El informe de Reddit no demuestra ninguna de estas causas por sí sola, pero con esta topología cada una debe aislarse metódicamente en lugar de basarse en conjeturas.

La guía de costes y comportamiento de S3 en Mr.PlanB resulta muy útil en este punto, ya que el almacenamiento de objetos es un modelo gestionado mediante API y debe tratarse como tal en lugar de considerarlo un simple disco duro remoto.

¿Cómo aislar un problema de SOBR en Veeam?

Simplifica el entorno hasta que la operación que falla sea reproducible a voluntad. La resolución de problemas es mucho más sencilla cuando un único trabajo, un bucket, una ruta de proxy y un destino de objetos pueden fallar bajo demanda.

Comienza registrando la compilación de Veeam, el firmware del almacenamiento, la configuración del bucket, los roles de gateway o proxy, los ajustes de cifrado, la configuración de inmutabilidad, la resolución DNS, la cadena de certificados y la sincronización horaria. A continuación, anota el paso exacto del trabajo en el que se produce el error.

Ejecuta una copia de backup pequeña hacia un solo bucket sin otros trabajos compitiendo por recursos. Si se completa con éxito de forma repetida, añade un segundo trabajo. Si los fallos aparecen solo con la concurrencia, habrás delimitado una frontera muy útil. Si una sede falla y la otra no, compara las rutas. Si ambas fallan del mismo modo, busca la capa común en Veeam o en el almacenamiento de objetos.

El administrador ya había limitado los buckets a dos trabajos, lo que indica que la concurrencia ya estaba en el radar de diagnóstico. El soporte también solicitó un tiempo de espera de S3 más amplio y registros detallados. Eran experimentos razonables, pero el siguiente paso siempre debe fundamentarse en las pruebas obtenidas de la comprobación anterior.

¿Qué dice la documentación actual de Veeam sobre SOBR?

A fecha de July 2026, la documentación de Veeam Backup & Replication 13 describe Scale-Out Backup Repository como un sistema de repositorio lógico capaz de combinar almacenamiento de rendimiento con niveles de capacidad y de archivo. El nivel de capacidad puede utilizar almacenamiento de objetos en la nube o local, y los backups se pueden restaurar directamente desde él.

Veeam documenta también el almacenamiento compatible con S3 como un tipo de repositorio de almacenamiento de objetos soportado. Los repositorios de objetos pueden servir como destino para trabajos de backup y de copia de backup, además de participar en los niveles de SOBR.

Ten esto presente al leer un informe de error antiguo o específico de una versión. Un fallo en producción sobre una funcionalidad soportada significa que la implementación, el entorno, la versión, el destino de almacenamiento o la interacción entre esas capas requieren un diagnóstico riguroso.

Para los equipos que comparan arquitecturas, la guía de backup de Proxmox en Mr.PlanB muestra un punto de diseño diferente: el almacenamiento nativo de backup, las soluciones de terceros y las copias externas resuelven problemas similares por distintas vías. La arquitectura adecuada depende de los modos de fallo que tu equipo sea capaz de gestionar.

¿Cuándo deberías sospechar del appliance de objetos en vez de Veeam?

Sospecha del almacenamiento cuando los fallos coincidan con la carga del bucket, la tasa de peticiones, cambios de firmware, una sola sede, un solo nodo, un comportamiento específico de la API o un patrón de error en el propio sistema de almacenamiento. Sospecha de Veeam cuando el mismo destino funcione sin problemas con herramientas independientes pero falle de forma sistemática en una operación concreta de Veeam.

El cruce de acusaciones entre fabricantes no debe determinar la conclusión. Reúne registros de ambos lados para la misma marca temporal. El appliance de objetos debe mostrar las peticiones, los códigos de respuesta, la latencia, las limitaciones de tasa o los fallos internos. Los registros de Veeam deben reflejar qué operación intentó realizar y qué respuesta obtuvo.

Si el problema desaparece cuando la misma copia de backup se dirige a otro destino compatible con S3, es una prueba de enorme peso. Si acompaña a Veeam a través de diferentes plataformas de objetos, apunta en otra dirección, y si se repite en un único appliance con independencia del software de backup utilizado, ese dato resulta igualmente revelador. Una buena matriz de diagnóstico cambia una sola capa a la vez.

¿Por qué reconstruir el servidor de Veeam es una mala primera reacción?

Reinstalar o reconstruir el servidor cambia muchas variables al mismo tiempo y puede colisionar con el almacenamiento inmutable. El administrador manifestó explícitamente que no podía reconstruir el servidor y purgar una ubicación externa cada vez que el entorno tuviera un mal día.

Es una objeción muy razonable, puesto que la inmutabilidad está pensada precisamente para dificultar las modificaciones destructivas. Una plataforma de recuperación debe disponer de un método documentado para reconectar, importar o recuperar la configuración sin tratar cada fallo sin explicación como una autorización para borrar el historial protegido.

Antes de reconstruir, protege el backup de configuración de Veeam, las contraseñas de cifrado, las definiciones de repositorios y la relación exacta con el almacenamiento de objetos. Confirma cómo la versión de destino importa o sincroniza los datos existentes. La documentación actual del nivel de capacidad de Veeam describe el comportamiento de sincronización cuando un repositorio de objetos ya contiene datos transferidos previamente.

El centro de almacenamiento de Mr.PlanB resulta relevante aquí porque la capacidad de recuperación del almacenamiento abarca tanto los metadatos y la información del plano de control como los propios bytes alojados en el dispositivo.

¿Qué haría yo ante un fallo de SOBR de seis meses?

Construiría un entorno de reproducción controlado en torno a un único flujo de objetos que falle, con un backup de origen, una copia de backup, un bucket, un appliance de destino y una ventana temporal concreta, recopilando los registros de Veeam y del almacenamiento para esa misma ejecución.

Después realizaría cuatro comparaciones: sede principal frente a sede de DR, un trabajo frente a dos, el appliance de objetos actual frente a otro destino compatible con S3, y la compilación actual de Veeam frente a la versión de mantenimiento soportada por el fabricante si existe una actualización disponible y aprobada.

Mantendría saludable la ruta de protección en disco local mientras se investiga la capa de objetos, y comprobaría además que otra copia externa o desconectada continúe cumpliendo con los requisitos de recuperación del negocio.

Los enlaces rápidos son útiles, pero no diagnostican nada por sí mismos. En el backup hacia almacenamiento de objetos, el camino más corto hacia una respuesta consiste en dejar de probar toda la arquitectura a la vez y obligar a una sola capa a demostrar su funcionamiento.