El backup que nunca existió

Fertec Iberia había crecido de forma constante durante casi dos décadas. Empezaron en un taller de 400 metros cuadrados con cinco personas. En 2026 tenían tres naves industriales, contratos con fabricantes de automoción europeos y un ERP personalizado que gestionaba desde los pedidos a proveedores hasta la trazabilidad de cada pieza producida.

La tecnología, sin embargo, había crecido de forma orgánica y algo caótica. Un servidor comprado en 2019. Un segundo servidor añadido en 2021. Varios discos externos. Un NAS en el despacho de Rodrigo que «alguien» había instalado para «las copias de seguridad». Y un técnico de sistemas, Iñaki, que hacía milagros siendo el único responsable de toda la infraestructura de una empresa de 140 personas.

Cuando en el consejo de administración alguien preguntaba por los backups, la respuesta era siempre tranquilizadora: «Sí, tenemos copias de seguridad automáticas cada noche.» Era verdad. Hasta que dejó de serlo.

«Nadie me preguntó nunca si los backups funcionaban de verdad. Me preguntaban si los teníamos. Y sí, los teníamos. Pero en catorce meses nunca comprobé que se estuvieran ejecutando correctamente. Ese error fue mío.»

El problema se había originado en marzo del año anterior, cuando migraron parte del ERP a un nuevo servidor. Durante la migración, la tarea programada que ejecutaba las copias de seguridad nocturnas quedó apuntando a una ruta de red que ya no existía. El script se ejecutaba cada noche puntualmente, escribía un log sin errores visibles, y no copiaba absolutamente nada. Los archivos de log parecían correctos. Solo una revisión minuciosa habría detectado que los ficheros de destino no aumentaban de tamaño.

Iñaki lo descubrió cuando el servidor falló y fue a buscar la copia de la noche anterior. Y no estaba. Ni la de esa noche, ni la de la semana pasada, ni la de los catorce meses anteriores.

El servidor principal de Fertec tenía una configuración RAID-5 con tres discos. Teóricamente, el RAID-5 permite que falle un disco sin pérdida de datos, porque la información se distribuye con paridad entre los tres. Es una solución robusta. Pero tiene un punto débil del que mucha gente no habla: cuando falla un disco y el RAID reconstruye con el disco de repuesto, durante ese proceso de reconstrucción la carga sobre los discos restantes es enorme. Y si otro disco tiene sectores defectuosos —cosa frecuente en discos viejos que trabajan bajo estrés— puede fallar también durante la reconstrucción.

Eso fue exactamente lo que ocurrió. El Viernes Santo por la mañana falló el disco número dos. Iñaki recibió la alerta, pero era festivo, estaba de viaje y decidió gestionarlo el martes tras las vacaciones. «El RAID-5 aguanta un disco caído, total era fin de semana largo.» El sábado por la tarde, mientras el sistema seguía funcionando con dos discos, el disco número tres —que llevaba meses con sectores defectuosos sin que nadie lo supiera— cedió definitivamente.

Cuando Rodrigo volvió de la sierra el lunes por la tarde, se encontró con la empresa paralizada. El ERP no arrancaba. Los técnicos de producción no podían acceder a los planos de fabricación. El departamento comercial no tenía acceso a los pedidos activos. Los datos de los clientes, los proyectos en curso, las órdenes de fabricación, los registros de calidad, los históricos de proveedores… todo estaba en esos dos discos fallidos.

Rodrigo contrató ese mismo lunes a una empresa especializada en recuperación de datos. El diagnóstico no fue alentador: los discos tenían daño físico en los cabezales de lectura. La recuperación sería parcial en el mejor de los casos, y llevaría entre dos y cuatro semanas.

Las semanas del colapso

Cómo se desarrolló el peor mes en la historia de la empresa

Rodrigo había pensado que el problema de los servidores sería caro pero manejable. Quizás unos miles de euros en hardware nuevo y un par de días de caos. Lo que nadie le había explicado nunca es que el coste de perder los datos de una empresa no es el coste de los discos. Es el coste de todo lo que depende de esos datos.

Para contextualizarlo: una solución de backup profesional en la nube con monitorización, copias inmutables y pruebas de restauración automáticas habría costado a Fertec entre €180 y €350 al mes para su volumen de datos. En doce meses, entre 2.160 y 4.200 euros. Frente a 204.500 euros de pérdida directa y dos contratos perdidos.

Pero el impacto más difícil de cuantificar fue otro: la pérdida de la trazabilidad de 14 meses de fabricación. Fertec tenía contratos con fabricantes de automoción que exigen trazabilidad total de cada componente producido. Sin esos registros, la empresa tuvo que demostrar retroactivamente —con documentos físicos, emails, certificados de proveedor— que sus piezas cumplían los estándares de calidad requeridos. Fue un proceso que duró meses y que puso en riesgo varios certificados de calidad.

«Lo más duro no fue el dinero. Lo más duro fue llamar a nuestros clientes principales el martes después de Semana Santa y decirles que no podíamos garantizarles los plazos de entrega porque habíamos perdido las órdenes de fabricación. Que habíamos perdido sus datos. Esa llamada no se la olvida a nadie.»

Sería fácil culpar al disco duro. O a Iñaki por no actuar el Viernes Santo. O al script de backup mal configurado. Pero el verdadero problema de Fertec no era técnico. Era organizativo. Era cultural. Era la suma de una serie de decisiones —o ausencias de decisiones— que se acumularon durante años hasta que un día coincidieron todas en el peor momento posible.

Ninguna de las medidas que habrían evitado este desastre requería un presupuesto de gran empresa ni un equipo técnico especializado. Eran —son— prácticas estándar al alcance de cualquier pyme con una mínima voluntad de implementarlas.

Si tienes más de 10 empleados y tus datos están en servidores locales o en la nube, este artículo va dirigido a ti. No hace falta ser una empresa grande para perder todo. Hace falta, simplemente, no haber comprobado nunca si tu backup funciona de verdad.