Por qué los backups de tu PYME fallan en silencio y cómo saberlo

Los backups de tu PYME pueden fallar en silencio cuando el proceso se ejecuta sin errores visibles pero el archivo resultante está corrupto o apunta a una ruta que ya no existe. Sin pruebas de restauración periódicas, nadie lo detecta hasta el incidente. En más del 55% de auditorías IT que realizamos en PYMEs españolas encontramos al menos un fallo crítico no detectado en el sistema de backup. Esta no es una amenaza futura: es un riesgo activo en cientos de empresas con backup «activo». La pregunta no es si tienes backup, sino si ese backup es recuperable.

El backup zombie: proceso OK, datos muertos

El «backup zombie» es el fallo más común y más traicionero: el scheduler lanza el job a las 2 de la madrugada, el log marca «completado», y nadie sabe que el archivo lleva semanas sin datos reales porque la unidad de destino cambió de ruta tras una actualización de Windows Server o una migración de almacenamiento. Este patrón aparece especialmente cuando la persona que configuró el backup ya no está en la empresa, o cuando un cambio de infraestructura no incluyó actualizar las rutas de destino de las copias. La diferencia entre «tener backup» y «tener backup que funciona» es exactamente una prueba de restauración en un entorno aislado. La mayoría de soluciones de backup envían alertas solo cuando el proceso falla completamente, no cuando el archivo generado tiene 0 bytes o está truncado. En auditorías reales hemos encontrado archivos de backup de 2-3 KB donde debería haber entre 40 y 80 GB, y llevaban meses en ese estado sin que nadie lo hubiera detectado.

La credencial caducada: el fallo invisible que el dashboard no muestra

El segundo mecanismo silencioso es la credencial caducada o el permiso revocado: cuando alguien cambia la contraseña del usuario de servicio que ejecuta los backups —por política de seguridad, rotación de personal o simplemente porque tocaba—, el job puede quedar en un estado intermedio donde parece ejecutarse pero escribe en un directorio temporal local que se sobrescribe con cada ejecución. Este patrón es frecuente en entornos con Active Directory donde las políticas de caducidad de contraseñas no tienen excepción documentada para cuentas de servicio críticas. El resultado es que el backup más reciente válido tiene 90, 180 o incluso 300 días de antigüedad, pero el dashboard del software muestra verde porque el proceso técnicamente «termina» sin error fatal. Sin una alerta basada en la fecha real del último backup verificable —no en si el proceso se ejecutó, sino en si el archivo resultante contiene datos— este fallo puede pasar desapercibido indefinidamente. Es un fallo de diseño del sistema de monitorización, no del backup en sí, y requiere una capa adicional de verificación activa que pocas PYMEs tienen implementada.

• El tamaño del archivo de backup no varía en semanas, aunque la base de datos crezca.
• Los reportes automáticos van a una carpeta de correo que nadie revisa activamente.
• La última restauración de prueba documentada data de más de seis meses.
• El destino del backup está en el mismo servidor físico o rack que los datos originales.
• No existe documentación escrita sobre qué datos se incluyen y cuáles quedan fuera del scope.
• El técnico que configuró el sistema de backup ya no trabaja en la empresa.

El coste de descubrir que el backup falla durante un incidente real —ransomware, fallo de hardware, borrado accidental— va mucho más allá del precio de haber contratado antes una solución verificada. Las estimaciones de Gartner para empresas medianas sitúan el coste medio de downtime entre 5.000 y 12.000€ por hora, sin contar impacto reputacional ni posibles sanciones regulatorias. En España, el RGPD obliga a demostrar que los datos personales están protegidos y son recuperables: un backup no verificado no cumple este requisito y puede derivar en sanciones de la AEPD de hasta el 4% de la facturación anual global. Hemos acompañado a PYMEs del sector industrial y retail que tardaron entre 4 y 9 días laborables en recuperar operaciones tras un incidente, con pérdidas que superaron los 30.000€ en facturación no realizada y contratos en riesgo. La ironía es que el coste de una auditoría de backup y un test de restauración trimestral representa una fracción mínima de lo que cuesta un solo día de paralización operativa.

En la mayoría de proyectos donde auditamos el backup, la empresa no necesita contratar una solución más cara ni aumentar la capacidad de almacenamiento: lo que necesita es ejecutar una restauración de prueba completa sobre lo que ya tiene, documentarla y repetirla trimestralmente. Si tu solución actual pasa esa prueba, tienes un backup funcional; solo hay que formalizar el proceso y asignar un responsable. Esto lo decimos aunque significa que en algunos proyectos nuestra recomendación final sea «lo que tienes ya funciona; hay que testearlo y documentarlo». No siempre salimos de un proyecto con un contrato de servicios adicionales. Pero el cliente que confía en nosotros para decirle cuándo no necesita gastar más vuelve cuando sí lo necesita, y eso es lo que queremos construir.

En más de una auditoría hemos terminado con la conclusión de que el cliente tenía una solución de backup perfectamente válida. El problema era que nadie había ejecutado nunca un simulacro de recuperación real. Una tarde de trabajo resolvió tres años de riesgo acumulado.

• Localiza el último archivo de backup generado y comprueba su tamaño real contra el volumen de datos que debería contener.
• Revisa el log del último backup: ¿cuánto tiempo tardó? ¿Hay warnings aunque el estado final sea OK?
• Identifica quién es hoy el responsable de verificar que el backup funciona. Si no hay nadie designado, ese es el primer problema a resolver.
• Realiza una restauración de prueba de al menos un directorio o base de datos en un entorno aislado y documenta el resultado con fecha.
• Verifica que el destino del backup es físicamente distinto del origen: otro servidor, otra ubicación geográfica, o cloud con cifrado en reposo.
• Comprueba que las credenciales del usuario de servicio del backup no han caducado ni caducarán en los próximos 30 días.
• Revisa si los backups están cifrados, especialmente si contienen datos personales de clientes o empleados sujetos al RGPD.