Backup no es lo mismo que recuperación probada

La mayoría de empresas que sufren una caída grave sí tenían backup. Lo que no tenían era la certeza de poder restaurarlo dentro de un plazo aceptable. Son dos cosas distintas, y solo una de ellas sostiene la operación.

El dato que resume el problema

Según la IT Resilience Survey de Gartner para 2026, el 78 % de las organizaciones ya implementó —o está implementando— un entorno de recuperación aislado (IRE): una réplica separada de la red productiva desde la que volver a levantar los sistemas si todo lo demás cae.

La cifra suena bien hasta que se lee la siguiente: el 53 % de esas mismas organizaciones no tiene respaldos inmutables ni imágenes maestras.

Dicho de otro modo: hay un lugar limpio al que volver, pero lo que se va a restaurar ahí puede estar cifrado o alterado. Se invirtió en la mitad cara del problema y se dejó abierta la barata.

Por qué la inmutabilidad es el eslabón que falta

El ransomware actual no llega y cifra. Se instala, escala privilegios, y dedica días —a veces semanas— a localizar y destruir las copias de seguridad antes de lanzar el cifrado. Es la forma más eficaz de eliminar la alternativa a pagar.

Un respaldo inmutable, basado en WORM (write once, read many), no se puede modificar ni borrar durante el periodo de retención definido, ni siquiera con credenciales de administrador. Ese matiz es todo el punto: asume que el atacante ya es administrador, porque a esas alturas normalmente lo es.

Las tres preguntas que un esquema debe responder

• ¿Cuánto tardo en volver a operar? Es el RTO. Si nadie lo midió con un ensayo real, no es un dato: es una suposición.
• ¿Cuánta información pierdo? Es el RPO, y lo define la frecuencia de las copias, no el tamaño del disco donde se guardan.
• ¿Quién ejecuta la restauración? Si depende de una sola persona, el plan tiene un punto único de falla que no está en ningún servidor.

Por qué fallan las restauraciones

Las copias se detienen sin que nadie lo note porque las alertas llegan a un buzón que ya nadie revisa. Se respalda la base de datos pero no la configuración que la hace arrancar. O el respaldo vive en el mismo dominio que el sistema comprometido, y se cifra junto con todo lo demás.

Ese último caso es el que la inmutabilidad resuelve de raíz.

Qué cambia con un ensayo

Un simulacro convierte suposiciones en números. Se restaura un servicio en un entorno aislado, se cronometra y se documenta qué faltó. La primera vez casi siempre aparecen sorpresas; esa es exactamente la razón de hacerlo antes del incidente y no durante.

Nuestra recomendación es probar la restauración de al menos un sistema crítico cada trimestre, con registro de cuánto tardó y qué se perdió. Con eso, la continuidad deja de ser una promesa del proveedor y pasa a ser un dato tuyo.

Es parte de lo que cubrimos en Seguridad 360: respaldo inmutable con Acronis o Veeam, políticas de retención y simulacros de recuperación con resultados documentados.