BookinglyTech News
Infraestructura

Un admin denuncia corrupción de ficheros al sincronizar con Tiger Bridge

Un administrador de sistemas relata en r/sysadmin que la herramienta corrompe hojas de Excel de 60 MB al sincronizarlas con AWS y que su responsable de datos lo achaca a un mal uso sin explicarlo

2 min de lecturar/sysadmin0 vistas

Cada cierto tiempo alguien descubre que su capa de sincronización no se lleva bien con los ficheros que le echan. Esta vez le ha tocado a Tiger Bridge, y el relato lo firma un administrador de sistemas en r/sysadmin.

Su organización migró hace unos meses a un sistema híbrido que usa Tiger Bridge para sincronizar el almacenamiento local con una instancia en AWS. El equipo de analítica trabaja con hojas de Excel de unos 60 MB y, según este administrador, la sincronización las corrompe. No sería un caso puntual: sostiene que ocurre cada vez con más frecuencia.

El problema y la respuesta

El equipo llevaba tiempo avisando de que Excel y Access no son la herramienta adecuada para consolidar el trabajo de analítica, una queja que arrastran desde hace más de diez años y que la dirección del departamento nunca ha querido abordar. Ahora el fallo llega por otro lado, y cuando preguntaron al responsable central de gestión de datos qué estaban haciendo mal, la respuesta fue que la herramienta no funciona así y que la estaban usando mal. No hubo más detalle: ni qué configuración era incorrecta, ni qué patrón de uso esperaba ver. La alternativa que planteó fue moverse a SQL Server o a SharePoint, algo con lo que el propio administrador está de acuerdo, pero que no explica la corrupción que tiene delante.

Conviene mirar el material con lupa antes de sacar conclusiones. El mensaje es de un usuario anónimo. No incluye versión de Tiger Bridge, ni cómo está montada la sincronización, ni si hablamos de escritura simultánea, de ficheros abiertos durante el copiado o de bloqueo de ficheros mal gestionado. Nadie del fabricante ha respondido en el hilo y no hay una reproducción independiente del fallo. Todo lo que hay es el testimonio de una persona, sin cifras de cuántos ficheros se han estropeado ni de cuándo empezó exactamente.

Para quien opera almacenamiento híbrido, el asunto merece atención igualmente. El tiering hacia la nube es justo el punto donde una corrupción silenciosa se paga cara: el fichero se abre, parece correcto y el daño aparece cuando alguien lo presenta en una reunión. Saber si el origen está en la herramienta, en la configuración del cliente o en el patrón de acceso de ficheros grandes cambia por completo la respuesta, y ninguna de esas tres hipótesis se puede descartar con lo que hay publicado.