← Volver al blog
INFRAESTRUCTURA & DR

Tienes backup. Eso no significa que tengas recuperación

5 min de lectura

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.

Vale la pena decirlo con claridad: ese artículo es contenido patrocinado por N-able, un fabricante que vende justamente el producto que la pieza recomienda. Eso no invalida el argumento — lo hace verificable contra otras fuentes. Y el argumento aguanta.

El dato que citan, tomado del informe de costo de brechas de IBM del año pasado: el 76% de las organizaciones necesitó más de 100 días para recuperarse de un ciberataque aun teniendo los respaldos intactos. Ciento tres 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:

  • El 57% de las empresas de entre 20 y 100 empleados calcula que una hora de caída les cuesta más de $100,000.
  • Una pyme que factura $10 millones al año pierde alrededor de $55,000 por día detenido.
  • Una de cada cinco pymes cerraría con $10,000 de daño por un ataque.
  • El mercado de recuperación como servicio (DRaaS) pasó de $18.89 mil millones en 2025 a una proyección de $83.15 mil millones para 2034.

Ese último número no es una métrica de marketing. Es el mercado diciendo, con dinero, que la gente 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 cambio de idea

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 artículo 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:

  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 ya dejas de operar con una suposición y pasas a operar con un dato. Que es exactamente de lo que se trata.

¿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.

Bibliografía

Fuente principal

Fuentes de verificación y ampliación

Nota de transparencia: el artículo de The Register es contenido patrocinado por N-able. Las cifras de downtime y tamaño de mercado citadas provienen de esa pieza; las de IBM fueron contrastadas contra la fuente original.

Cómo trabajamos

HABLEMOS POR WHATSAPPESCRIBIR UN CORREO