El test de los 3 minutos que predice si tu pyme va a perder todos sus datos (y por qué “backup completado” no significa nada)

Si solo tienes 1 minuto, lee esto

Esta semana Tailscale (la VPN que usan miles de PYMEs) descubrió que un fallo silencioso de 16 años en una pieza de software llamada SQLite les había estado corrompiendo la base de datos de logs. El sistema decía “backup completado”. El restore llevaba años fallando. Si tu pyme usa cualquier servicio en la nube, ese mismo patrón aplica — y nadie te lo va a contar hasta que lo necesites. El test del restore del domingo son 3 minutos que separan una pyme que recupera sus datos de una que los pierde.

Qué ha pasado realmente (en 2 niveles)

El caso técnico es sencillo cuando lo despojas de jerga. SQLite es, literalmente, una libreta de direcciones interna que usan miles de aplicaciones — desde la app de tu móvil hasta sistemas internos de empresa — para anotar y releer datos. Esa libreta tiene un mecanismo llamado “WAL” (siglas en inglés de “registro de escritura anticipada”): imagina que cada vez que alguien escribe algo en la libreta, se hace antes una copia de seguridad en una hoja aparte, para no perder lo anterior.

Tailscale, la empresa que construye una de las VPN más usadas por PYMEs para que sus empleados trabajen desde fuera de la oficina, descubrió que un fragmento de ese mecanismo llevaba 16 años comportándose mal: cuando se reiniciaba el sistema en ciertos momentos, la copia de seguridad quedaba “pegada” a un estado anterior. El sistema seguía funcionando. Los logs decían “OK”. Pero la copia estaba desfasada. Y cuando alguien intentaba restaurar desde ella, recibía datos incompletos o directamente vacíos.

Lo crítico no es el bug en sí. Es que:

  • El sistema reportó “todo OK” durante años.
  • El log de backups marcaba cada noche “completado” con éxito.
  • El primer aviso real fue cuando alguien necesitó los datos y no estaban.

Esto es lo que en ciberseguridad se llama un “fallo silencioso”: no avisa, no pita, no sale en ningún panel. Solo se manifiesta cuando ya es tarde.

Por qué tu pyme tiene (casi seguro) el mismo patrón

Tu pyme probablemente no usa Tailscale, ni SQLite directamente. Pero el patrón es idéntico al de cualquier servicio cloud que tengas contratado: el CRM donde guardas los datos de tus clientes, el programa de facturación, la herramienta de citas online, el correo electrónico profesional, las copias en la nube del servidor. Cada uno de ellos tiene, escondido en algún lugar, su propio “WAL” — su propio sistema de protección interna — que:

  • Se reinicia periódicamente (actualizaciones del proveedor, mantenimiento nocturno, fallos eléctricos).
  • Tiene una copia de seguridad que se sobreescribe cada noche.
  • Te dice “OK” porque el archivo existe, pero no verifica que dentro haya datos válidos.

Según las estadísticas públicas del sector cloud, entre el 30% y el 40% de las PYMEs europeas descubren que su backup está roto solo cuando intentan usarlo. No es un caso raro. Es el patrón más común de incidente de datos en PYMEs.

El test del restore del domingo (5 pasos, 3 minutos)

No necesitas conocimientos técnicos. Necesitas 3 minutos un domingo por la tarde — cuando nadie te molesta — y un café. Estos son los 5 pasos:

  • Pide a tu proveedor el último backup. Un email tipo: “Hola, ¿me podéis enviar el último backup completo de mi cuenta, en formato que pueda abrir yo en mi ordenador?” Si te dicen “no podemos” o “hay que pagar”, tienes un problema de raíz.
  • Abre el archivo que te manden. Si es una hoja de cálculo: ábrela y mira que tenga filas reales (clientes, facturas, productos). Si es una base de datos: ábrela con la herramienta que uses habitualmente y verifica que aparecen datos.
  • Cuenta 5 registros y compáralos con tu sistema actual. Por ejemplo: coge los 5 últimos clientes que tengas. ¿Están en el backup? ¿Con los datos correctos (teléfono, email, dirección)? Si falta alguno, el backup está incompleto.
  • Verifica la fecha. El backup debería tener datos de, como mucho, 24-48 horas de antigüedad. Si te dicen “el último backup es del mes pasado”, tienes un problema mayor: nadie sabe qué ha pasado en tu sistema desde entonces.
  • Haz una foto de pantalla al archivo abierto y guárdala. Esto es tu “evidencia de que el backup funciona”. El día que tengas un incidente real, esa foto será la diferencia entre recuperar tu negocio o perder semanas de trabajo.

Si cualquiera de estos pasos falla, no entres en pánico: significa que tienes un problema silencioso, pero todavía estás a tiempo de arreglarlo. Un backup que nunca se ha verificado no es un backup: es una hipótesis.

Tu Quick Win de hoy

Antes del próximo lunes, envía el email del paso 1 a tu proveedor cloud principal (CRM, facturación, correo). Cuando te respondan, dedica 3 minutos del domingo a los pasos 2-5. Si descubres algo roto, anótalo y plantéate una auditoría seria de tu stack — porque lo que se rompe en silencio una vez, se rompe otra vez. Tres minutos el domingo pueden salvarte semanas de trabajo.

¿Y si el problema no está solo en tu backup, sino en cómo conectan entre sí tu CRM, tu correo y tu facturación?

Solicitar Diagnóstico Gratuito