Tienes backup. Eso no significa que tengas recuperación.

Tu job de respaldo terminó anoche a las 2:14 a.m. Estado: verde. Sin errores. Sin alertas en el correo.

Eso no te dice absolutamente nada sobre si mañana puedes volver a operar.

Son dos preguntas distintas y casi nadie las separa. La primera es ¿existe una copia de mis datos?. La segunda es ¿cuánto tardo en tener el negocio funcionando otra vez?. La primera la responde una consola. La segunda solo la responde un ensayo real.

El hueco entre tener copia y volver a operar

The Register publicó el 1 de julio un análisis que pone el dedo justo ahí: los sistemas de backup tradicionales fueron diseñados para fallas de hardware y borrados accidentales, no para un operador de ransomware que entra a tu red, se toma su tiempo, y ataca primero la infraestructura de respaldo antes de tocar producción.

El dato que citan, tomado del informe de costo de brechas de IBM: el 76% de las organizaciones necesitó más de 100 días para recuperarse de un ciberataque aun teniendo los respaldos intactos. Cien días de operación degradada con los datos ahí, disponibles, guardados correctamente.

Ese es el hueco. No falta el dato. Falta el proceso para devolverlo a producción a la velocidad que el negocio necesita.

Los números que hacen que esto importe

Cuando el downtime se traduce a dinero, la conversación cambia de tono.

Y un número que no es de marketing sino de mercado: la recuperación como servicio (DRaaS) pasó de $18.89 mil millones en 2025 a una proyección de $83.15 mil millones para 2034. Es la gente diciendo, con dinero, que ya entendió que el backup solo no alcanza.

Por qué el RTO de tu documentación es ficción

Casi toda empresa mediana tiene un RTO y un RPO escritos en algún lado. Cuatro horas. Ocho horas. Un día.

Pregunta incómoda: ¿de dónde salió ese número?

En la mayoría de los casos salió de una plantilla, de una reunión de cumplimiento, o de lo que sonaba razonable el día que se firmó el contrato. No salió de un cronómetro.

Restaurar un servidor completo desde una copia tradicional toma horas o días. Restaurar veinte servidores en orden de dependencia — con Active Directory arriba primero, con DNS resolviendo, con las aplicaciones reconectando a sus bases de datos — toma mucho más. Y ese ejercicio casi nunca se hace completo, porque hacerlo completo exige apagar cosas o levantar un ambiente paralelo, y ninguna de las dos opciones es cómoda.

Entonces el RTO se queda en el papel. Y el día del incidente descubres el número real, que es el único que existía.

El backup es un archivo. La recuperación es un proceso. Y los procesos que nunca se ensayan no funcionan.

Esa frase es la diferencia entre un plan de continuidad y una carpeta con procedimientos.

Lo que el análisis de The Register propone —arquitecturas con réplicas continuamente actualizadas, almacenamiento inmutable fuera del alcance del atacante, failover automatizado, pruebas automáticas como función estándar y no como servicio adicional— no es una lista de features de un fabricante. Es la descripción de lo que hace falta para que el número del papel y el número del cronómetro coincidan.

Después de siete años trabajando en protección de datos y continuidad, tres de ellos dentro de Veeam, la conclusión que me llevo es más simple de lo que suena: la mayoría de los desastres de recuperación no fueron desastres de tecnología. Fueron desastres de suposición. Alguien asumió que funcionaría porque la consola estaba verde.

Qué puedes hacer esta semana

No necesitas un proyecto de seis meses para cerrar la mayor parte de este hueco. Necesitas tres cosas, y ninguna cuesta dinero.

1. Elige un sistema crítico y restáuralo completo en un ambiente aislado. No un archivo. El sistema. Con cronómetro corriendo.
2. Escribe el número real que salió. Compáralo con el RTO documentado. La distancia entre los dos es tu riesgo actual, medido.
3. Verifica que al menos una copia sea inmutable y esté fuera del dominio. Si el atacante entra con credenciales de administrador y llega a tus respaldos, no tienes respaldos: tienes archivos esperando ser cifrados.

Con eso dejas de operar con una suposición y pasas a operar con un dato. Que es exactamente de lo que se trata.

Si el escenario que te preocupa es el de identidad —alguien que entra con credenciales válidas en lugar de romper nada— ese caso tiene su propia conversación en el artículo sobre Microsoft 365 y Entra ID.

¿Cuándo fue la última vez que restauraste un sistema completo de principio a fin, con cronómetro, y comparaste el resultado contra el RTO que tienes escrito?

Si la respuesta es «nunca» o «hace bastante», esa es la conversación que vale la pena tener antes del incidente, no durante.