Si le preguntan a cualquier empresa si tiene backup, casi todas dicen que sí. Es la respuesta más fácil de dar y la menos verificada de todas: el informe automático llega en verde cada mañana, y nadie intenta abrir el archivo que dice haber guardado.
El informe de Tendencias de Ransomware 2025, de Veeam, encuestó a 1.300 organizaciones en todo el mundo, de las cuales 900 habían sido atacadas por ransomware —el secuestro de datos, donde un programa cifra los archivos de la empresa y piden un rescate para devolverlos— en el año anterior. Entre esas 900, solo el 10% logró recuperar más del 90% de los datos afectados, y el 57% recuperó menos de la mitad. El backup existía. La recuperación, no.
Para quien aprueba el presupuesto, ese número cambia la pregunta. Ya no es "¿la empresa hace backup?" —casi todas ya responden que sí a eso—. Es "¿alguien ya intentó traer los datos de vuelta, de verdad, antes del día en que sea obligatorio?". Mientras la respuesta sea no, lo que existe es una suposición bien guardada, no una garantía.
Un informe en verde no prueba nada
El CERT.br, el grupo brasileño de respuesta a incidentes de seguridad, recomienda como base la regla 3-2-1: tres copias de los datos, guardadas en dos tipos de medios diferentes, con al menos una fuera del sitio o desconectada. Es un buen punto de partida, pero esa regla describe dónde guardar la copia, no si alguien ya intentó traerla de vuelta. Las dos preguntas no son la misma cosa.
Una copia de seguridad puede terminar sin errores y, aun así, no servir de nada al momento de restaurar: un archivo dañado, la versión equivocada, una parte del sistema que quedó fuera. El proceso que corre por la noche prueba que los datos se copiaron. No prueba que alguien pueda traerlos de vuelta.
Un estudio global de Unitrends en 2025, con más de 3.000 profesionales de TI en todo el mundo, midió exactamente esa distancia entre creer y saber. Más del 60% creía que la empresa podría volver a operar en cuestión de horas tras una caída. En la práctica, solo el 35% logró hacerlo dentro de ese plazo.
El mismo estudio encontró el motivo más evidente de esa distancia: el 25% de las empresas encuestadas prueba la recuperación de desastres una vez al año o menos. El resto del tiempo, la confianza en el backup viene solo del informe automático, nunca de un intento real de traer los datos de vuelta.
El informe de Veeam mostró el mismo problema desde otro ángulo. De las empresas atacadas, el 98% tenía un plan escrito de respuesta a ransomware, pero menos de la mitad de ese plan incluía los elementos considerados esenciales: solo el 44% incluía un paso de verificación del backup antes de declarar terminada la recuperación. Tener el plan por escrito y probar lo que describe son cosas distintas.
La propia norma estadounidense de seguridad de sistemas (NIST) trata esta prueba como una obligación, no como una buena práctica opcional: pide que se use una muestra de los datos de backup para restaurar partes del sistema dentro del plan de contingencia, con el resultado verificado antes de cualquier emergencia real. No hace falta que sea todo de una vez. Hace falta que sea de verdad.
Lo que hace hoy la mayoría de las empresas
El camino habitual, en la práctica, es este: el backup corre por la noche, el informe llega por la mañana, y nadie vuelve a tocarlo hasta el día en que los archivos desaparecen. Quien se ocupa de TI —a veces alguien de otra área, a veces un proveedor que solo aparece cuando lo llaman, a veces la persona del equipo que "entiende más de computadoras"— trata "el backup está corriendo" como si fuera sinónimo de "la empresa está protegida". Nadie pregunta si esa misma persona alguna vez intentó restaurar, ni qué pasaría si estuviera de vacaciones el día de la caída.
La guía de respuesta a ataques de ransomware del gobierno de Estados Unidos es directa sobre por qué esa confianza es riesgosa: buena parte de las variantes de ransomware busca y borra o cifra cualquier copia de seguridad accesible por la red. Si el backup permanece conectado y visible todo el tiempo, queda en la mira del mismo ataque que devastó los archivos originales.
El resultado es una trampa silenciosa. La empresa se siente cubierta porque el correo llega en verde, y solo descubre que no lo está en el único momento en que eso importa de verdad: en medio de una caída, con gente esperando, un cliente llamando y nadie sabiendo cuánto falta para que el sistema vuelva.
Lo que tiene que existir en la práctica
Un backup a prueba de un mal día se define por mecanismos verificables, no por el color de un informe.
Una restauración completa, simulada aparte. No basta con copiar un archivo aislado para ver si abre; hay que montar el sistema entero en una copia separada de producción y ver si arranca y funciona como el original.
Verificación de que lo restaurado funciona de verdad, no solo que el proceso terminó. Alguien confirma que la planilla abre, que la base de datos arranca, que el sistema reconoce los datos. "Terminó sin errores" y "funciona de verdad" son cosas distintas, y solo la segunda cuenta.
Tiempo de restauración cronometrado, no estimado. Medir cuánto tardó realmente el proceso en esa prueba, y compararlo con cuánto tiempo hasta que la empresa vuelva a operar promete el plan. Sin esa medición, el plan es una opinión sobre el futuro, no un número probado.
Un escenario en que la copia más reciente está comprometida. La prueba también debe prever que el ataque llegó hasta el backup más nuevo, y que la restauración parte de una copia anterior, guardada fuera del alcance de quien entró sin autorización.
Registro de cada prueba, con fecha y lo que no funcionó. Sin eso, cada intento empieza de cero, y el recuerdo de "ya lo probamos una vez" vale cada vez menos con el paso de los meses.
Así es como trabaja Skills IT: con simulaciones de recuperación periódicas, hechas aparte del entorno de producción, y con el registro de cada prueba y de lo que hubo que ajustar después.
Lo que gana la empresa con esto
La ganancia más directa aparece en el peor momento posible para notarla: cuando el sistema realmente cae, el equipo ya conoce los pasos y ya tiene una idea real de cuánto suele tardar el regreso, en lugar de descubrir todo eso bajo presión, con el cliente al teléfono.
Hay una ganancia financiera que va de la mano. Una empresa que ya probó su restauración puede estimar, con cierta precisión, cuánto cuesta cada hora de caída, y decidir con esa información si conviene invertir en una recuperación más rápida para un sistema específico o si el plazo actual ya es aceptable. Quien nunca probó decide a ciegas, casi siempre comprando otro producto después del susto. Multiplique eso por hora de caída, pedido no facturado y empleados parados esperando que el sistema vuelva, y la cuenta queda clara: probar tiene un costo previsible y pequeño; no probar solo muestra su costo en la peor hora, y sin avisar.
También hay un efecto sobre quien decide. El dueño o director que recibe una prueba de restauración documentada —qué funcionó, qué no funcionó, cuánto tardó— tiene algo concreto para conversar con el área financiera y con clientes que preguntan por la continuidad. Quien solo tiene el informe en verde del backup tiene una frase hecha, no una respuesta.
Una hoja de ruta para empezar
Antes de la próxima reunión sobre continuidad, estas cuatro preguntas ponen el tema en su lugar:
- Pida ver una restauración en acción, no solo el informe. Organice una demostración real: traer de vuelta un archivo o sistema no crítico, desde cero, frente a quien aprueba el presupuesto.
- Pregunte cuándo fue la última vez que alguien la probó. Si la respuesta es "nunca" o "no recuerdo", esa ya es la respuesta que la empresa necesita escuchar.
- Averigüe si la prueba contempla un escenario de ataque, no solo una falla técnica. Un disco que se quema es distinto de un intruso que borró la copia más reciente antes de salir.
- Ponga la próxima simulación en el calendario, con fecha fija. Una prueba sin fecha se vuelve promesa; una fecha marcada se vuelve rutina.
