Imagina un lunes cualquiera. A media mañana empiezan a sonar los teléfonos en cascada: “No funciona nada”. “No puedo entrar”. “La base de datos está caída”. En minutos llega el diagnóstico: ransomware, cifrado masivo, servicios parados. Toca restaurar.
El IT Manager respira hondo. Está tranquilo: las copias siguen las buenas prácticas, el viernes hubo backup full sintetizado, el lunes se hizo la prueba semanal de restauración de una VM y todo fue bien. El repositorio de backup se compró el año pasado; las especificaciones hablaban de deduplicación 90:1 y “ahorro espectacular” de capacidad. “Vamos sobrados para los puntos de recuperación que pide el negocio”, pensó entonces. Pulsa “Restaurar”: 300 VMs.
Pasan las horas. Los sistemas no levantan. Las restauraciones van a paso de tortuga. El RTO se dispara de horas a días. Nadie puede trabajar, los clientes presionan, Dirección exige explicaciones, las pérdidas crecen. El IT Manager abre el panel del repositorio: CPU desbocada, discos al 100 %, IOPS al máximo, colas de operaciones. ¿Cómo es posible si las copias eran rápidas? La respuesta es tan simple como incómoda:
Se diseñó para ingestar de forma eficiente, no para servir datos masivamente y a la vez.
Empezamos a entenderlo tarde, y de la peor forma.
La trampa de la deduplicación “milagrosa”: el día de la restauración todo se paga
La deduplicación inline, la compresión agresiva y los bloques diminutos son fantásticos para guardar mucho en poco. Pero, cuando hay que rehidratar y leer al mismo tiempo cientos de flujos aleatorios, aparecen los peajes:
- Rehidratación: reconstruir cada bloque “único” a partir de referencias dispersas. Eso multiplica accesos aleatorios y castiga IOPS.
- Single-threading encubierto: algunos dispositivos escalan mal en lecturas concurrentes; brillan sumando backups (secuenciales), sufren sirviendo restores masivos (aleatorios).
- Cifrado/compresión: lo que ahorra espacio consume CPU cuando se recupera.
- Erasure coding/objetos fríos: fantástico para durabilidad; no para RTO agresivos si la capa no está dimensionada para lectura de choque.
El resultado práctico es que el “90:1” se convierte en cientos de miles de I/O para recomponer unos pocos terabytes “lógicos”. Y ese número, no el ratio, es el que te hunde el RTO.
Regla de oro: compra para restaurar; el ahorro de espacio viene después.
El cálculo que nadie hace: throughput efectivo de recuperación
Haga el ejercicio antes de comprar el próximo repositorio:
- Datos a restaurar: ¿cuánto de verdad habrá que levantar en un incidente? No es lo mismo “toda la granja” que “20 VMs críticas” + “datos vivos del último día”.
- Concurrencia: ¿cuántas VMs simultáneas necesita el negocio para estar operativo?
- Throughput efectivo del repositorio sirviendo (no el de backup): MB/s por flujo rehidratando + latencia bajo carga + límite de streams.
- Red y proxies: cuellos de botella de 10 GbE saturados, proxies de backup sin CPU, datastores compartidos.
Un ejemplo burdo: si tu objetivo es recuperar 50 TB efectivos y tu plataforma sirve 600 MB/s reales con rehidratación y concurrencia, estás en ≈ 25 horas solo para mover datos, sin contar colas, montajes, rescans de hipervisor, boot storms ni verificaciones. Si son 100 TB, dobla la cifra. ¿El negocio aguanta?
Diseñar para recuperación (no para marketing)
Quien toma decisiones de backup debe interiorizar esto: la foto que salva la empresa no es la del dashboard de ahorro de TB, es la del reloj del RTO. Algunas ideas prácticas:
1) Separa “almacenar” de “recuperar”
- Capa caliente para instant recovery: repositorio con flash o discos rápidos y concurrencia alta para montar VMs directamente desde el backup (instant VM restore), aunque sea con rendimiento “aceptable” durante horas.
- Capa fría para retención: deduplicación y objetos para históricos y cumplimiento. No es la fuente prioritaria en un desastre.
2) Snapshots y “near-zero” para lo que no puede caer
- Snapshots de cabina y réplicas para las pocas cargas que no toleran ni horas de caída.
- CDP/journal donde tenga sentido: baja RPO y recuperación en minutos. Caro, pero para el 5–10 % crítico marca la diferencia.
3) “Plan de restauración”, no “prueba de una VM”
- Restaurar 200 VMs no es 200 × (prueba individual): es DNS, AD/IdP, PKI, DHCP, hypervisor managers, licencias, dependencias.
- Define un runbook: orden exacto, redes temporales, prioridades de arranque, pruebas de aplicación, datos que limpiar (malware) antes de publicar.
4) Concurrencia real y orquestación
- Divide por lotes: grupos de VMs con ventanas de arranque y afinidad de almacenamiento.
- Proxies suficientes y red dedicada (10/25/40 GbE según tamaño).
- QoS: evita que un monstruo acapare todo el canal mientras otros esperan.
5) Métrica que importa: Índice de Rendimiento de Recuperación
- Mide y registra un RPI: TB/hora sirviendo restauraciones con tu topología real, con N VMs simultáneas. Ésa es tu verdad operativa.
- Versiona esa métrica con cada cambio (firmware, parches, crecimiento). Si cae, explica por qué.
Seguridad del backup ≠ capacidad de recuperación
En muchos ransomware, el primer objetivo es romper tu posibilidad de restaurar. Por eso hay dos ángulos inseparables:
- Inmutabilidad y air gap: WORM/Object Lock, cintas, bóvedas aisladas, copias offline. Si el atacante no puede borrar/alterar, tienes de dónde volver.
- Limpieza: no restaures malware. Usa entornos aislados (clean room/IRE), escaneo del backup y verificación automática (arranque y pruebas de salud) antes de reintroducir en producción.
- Identidad y zero trust: MFA y RBAC estrictos para operadores de backup, credenciales rotadas, segregación entre plataforma de backup y dominios comprometidos.
La bóveda inmutable te salva los datos; el diseño orientado a recuperación te salva el negocio.
“Pero mis copias son rápidas…” —sí, y eso no significa nada el día D
Las ventanas de backup y el ratio de dedupe son métricas de coste y eficiencia. Útiles, sí; suficientes, no. El día D la pregunta relevante no es “¿cuánto ahorraste?”, sino:
- ¿Cuánto puedes servir por hora con 100, 200, 400 restauraciones en paralelo?
- ¿Qué latencia presentará el datastore montado desde backup en instant recovery?
- ¿Qué servicios levantas primero y en qué orden vuelves a ser útil para el cliente?
Si no tienes estas respuestas medidas, no las tienes.
Un plan de choque realista (90 días)
- Define el “mínimo vital”: qué 20 % de servicios devuelve 80 % del valor si están arriba. Negocia RTO/RPO por servicio con el negocio.
- Prueba de recuperación masiva: no una VM; 50–100 simultáneas, incluyendo AD/DNS/PKI. Cronometra todo (datos, arranque, pruebas). Obtén tu RPI.
- Ajusta arquitectura: añade capa caliente (flash/cache), segmenta cargas, escala proxies y red, separa repositorio frío.
- Endurece seguridad: inmutabilidad, bóveda aislada, MFA, cuentas “break glass”, runbooks impresos.
- Automatiza: runbooks versionados como código, flujos de arranque, pruebas de aplicación (synthetics).
- Repite trimestralmente y reporta a Dirección el RPI y el tiempo total hasta “servicio útil”.
Sobre el coste (y el falso ahorro)
Sí, una capa rápida cuesta. También cuesta parar la empresa dos días por un cuello de botella que sabíamos que existía. El TCO aquí no es el precio por TB guardado, sino el coste por hora de caída evitada. Si tu capa caliente reduce un día de parada en un incidente serio, probablemente se ha pagado sola.
Un recordatorio: el marketing de “90:1” es estupendo en slides. El cliente, el regulador y el CFO miden otra cosa: horas hasta volver a facturar.
Conclusión: cambia el marco mental
El backup ya no es un proyecto de almacenamiento: es una capacidad de continuidad de negocio. Hay que evaluarla con métricas de tiempo y servicio, no de TB. La mayoría de las crisis que veo no vienen de “no había copias”, sino de “no pudimos servirlas al ritmo que el negocio necesitaba”.
Deduplicación, compresión y objetos son aliados valiosos. Úsalos. Pero no sacrifiques tu capacidad de recuperación en nombre del ahorro. Diseña con frialdad:
- Compra para restaurar; el ahorro vendrá después.
- Mide el RPI como KPI principal del programa de backup.
- Ensaya restauraciones masivas y documenta dependencias.
- Protege tus copias (inmutables, limpias, aisladas) y tu identidad.
La diferencia entre un incidente bien gestionado y una crisis reputacional no la marca el slide de dedupe. La marca el reloj. Y ése, te guste o no, no se negocia.
