--- title: "Ransomware: el gran cuello de botella no está en las copias, sino en la recuperación masiva" description: "El sector redobló la inversión en backup, deduplicación y retención tras la ola de ransomware de los últimos años. Pero cuando llega el “día D”, el tropiezo se repite con inquietante frecuencia: la em..." url: https://revistacloud.com/ransomware-el-gran-cuello-de-botella-no-esta-en-las-copias-sino-en-la-recuperacion-masiva/ date: 2025-11-12 modified: 2025-11-07 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2024/06/ataque-ransomware.jpg categories: ["Análisis y opinión", "Seguridad"] tags: ["backups", "ransomware"] type: post lang: es --- # Ransomware: el gran cuello de botella no está en las copias, sino en la recuperación masiva El sector redobló la inversión en backup, deduplicación y retención tras la ola de ransomware de los últimos años. Pero cuando llega el “día D”, el tropiezo se repite con inquietante frecuencia: la empresa **sí tiene copias**, pero **no puede restaurar a tiempo**. El **RTO** (tiempo objetivo de recuperación) salta de horas a días y el impacto operativo y económico se dispara. En conversación con este medio, varios especialistas apuntan al mismo punto ciego: repositorios y *appliances* de backup están optimizados para **ingestar y almacenar** de forma eficiente —compresión, deduplicación, erasure coding—, pero **no** para **servir** cientos de restauraciones concurrentes con rehidratación intensiva y picos de I/O. El síntoma es conocido: CPU desbocada, discos al 100 %, IOPS saturados y colas interminables. El diagnóstico también: **la arquitectura está pensada para escribir, no para leer a lo grande**. > “El día más caro del backup es el día que restauras. Si dependes de una cabina afinada para dedupe pero no para lectura concurrente, has comprado almacenamiento, no continuidad de negocio”, resume David Carrero, cofundador de [Stackscale](https://www.stackscale.com/es/) (Grupo Aire), proveedor europeo de infraestructura cloud privada y bare-metal con experiencia en misión crítica y disaster recovery. --- ## La trampa del “90:1”: cuando el ratio de deduplicación encubre el coste real del RTO La deduplicación de bloques diminutos y la compresión agresiva funcionan: reducen *capex*, estiran CPDs y ayudan a cumplir políticas de retención. El problema llega al **rehidratar**. Para reconstruir un par de terabytes “lógicos” pueden ser necesarios **cientos de miles de lecturas dispersas**. Ese patrón —**aleatorio y masivo**— es lo opuesto a la ingestión secuencial de los backups y multiplica el coste en **latencia** y **IOPS**. Si además hay cifrado o compresión en línea, la CPU añade su propio cuello de botella. > “Cada punto de dedupe extremo es una promesa de I/O el día D. La métrica que manda no es el ‘ratio’, es cuántos TB por hora puedes entregar rehidratando con 100, 200 o 400 VMs en paralelo”, advierte Carrero. --- ## La métrica olvidada: medir TB/h **sirviendo** restauraciones (Índice de Rendimiento de Recuperación) Fuentes del sector recomiendan institucionalizar un KPI específico, el **Índice de Rendimiento de Recuperación (RPI)**: **TB/h** reales que la plataforma es capaz de **servir** con **N** restauraciones simultáneas, en la **topología real** de la empresa (no de laboratorio). Ese valor, y no el ahorro por deduplicación, debería guiar tanto las compras como los *runbooks* de continuidad. Un ejemplo ilustrativo: recuperar **50 TB** con un *throughput* efectivo de **600 MB/s** (ya descontadas rehidratación, colas y latencia) son **≈ 25 horas** sólo para mover datos, sin contar *rescans* del hipervisor, arranques masivos (*boot storms*), validaciones de aplicaciones ni limpieza de malware. Con **100 TB**, la cifra se duplica. > “Todo programa de backup serio debería reportar un RPI trimestral: TB/h entregados con X restauraciones en paralelo. Eso, y no el ahorro en TB, es lo que salva la cuenta de resultados”, afirma el cofundador de Stackscale. --- ## Diseño para recuperar: separar “almacenar” de “volver a producir” El consenso técnico apunta a un rediseño por capas: **1) Capa caliente para *instant recovery*** Repositorios con **flash/cache** o perfiles de lectura alta que permitan **montar VMs directamente desde el backup** y devolver servicio “aceptable” mientras se migra a producción. La capa fría —dedupe, objetos— queda **fuera** del camino crítico de las primeras horas. **2) Réplicas/snapshots para el 5–10 % que no puede caer** Para cargas que no toleran horas de inactividad, **snapshots de cabina**, **réplicas** síncronas/asíncronas y, donde tenga sentido, **CDP** con RPO bajísimo. Es caro, sí, pero se aplica a un subconjunto crítico. **3) Plan de restauración —no “prueba de una VM”** Orquestar 200 VMs implica **AD/DNS/PKI**, colas, licencias y dependencias de aplicación. Hace falta **runbook** versionado: orden de arranque, redes temporales, criterios de verificación y responsables. **4) Concurrencia y red dimensionadas** **Proxies** de backup suficientes, **QoS** para evitar acaparadores, y **10/25/40/100 GbE** según el tamaño. Restaurar en lotes y con afinidad de almacenamiento reduce contención. **5) Seguridad: inmutabilidad y “*clean room*”** Copia **inmutable** (WORM/Object Lock, bóvedas aisladas) y **restauración en entorno limpio** con escaneo antimalware **antes** de publicar a producción. MFA y RBAC estrictos en la plataforma de backup cierran el círculo. > “Siempre dos preguntas: ¿puedes traer de vuelta datos limpios en horas? y ¿puedes demostrar que no reinyectas el bicho? Sin inmutabilidad y clean room una de las dos falla”, señala Carrero. --- ## Errores que convierten un incidente en crisis - **Confundir pruebas**: recuperar una VM de laboratorio ≠ levantar 80 servicios con dependencias reales. - **Comprar por *datasheet***: priorizar “90:1” y no **TB/h de restauración concurrente**. - **Subdimensionar red y proxies**: 10 GbE compartidos y *proxies* sin CPU no sostienen picos. - **Olvidar el “mínimo vital”**: no todos los servicios pesan igual en el negocio; faltan prioridades claras. - **Publicar sin limpiar**: restaurar directamente en producción sin pasar por *clean room*. --- ## Plan de choque en 90 días **Día 0–15** - Definir con negocio el **mínimo vital** (20 % de servicios que devuelve 80 % de valor) y fijar **RTO/RPO por servicio**. - Medir **RPI** inicial con **50–100** recuperaciones simultáneas incluyendo **AD/DNS/PKI**; cronometraje y lecciones. **Día 16–45** - Introducir **capa caliente** para *instant restore*. - Escalar **proxies** y **red**, orquestar restauraciones por lotes. - Preparar **entorno limpio** y procedimiento de verificación. **Día 46–90** - Endurecer **bóveda inmutable**, **MFA/RBAC** de backup. - Automatizar **runbooks** (infra como código para redes/arranques). - Repetir prueba masiva; **reportar RPI** y tiempo hasta “servicio útil” a dirección. > “Si en 90 días no enseñas a la dirección un gráfico con el RPI subiendo y el RTO bajando, sigues gestionando storage, no continuidad de negocio”, resume el experto. --- ## Cinco preguntas incisivas para el proveedor 1. **TB/h de restauración** con **200 VMs concurrentes rehidratando** en topología real del cliente. 2. **Latencia y límites de *streams*** al montar VMs por *instant recovery*. 3. Impacto real de **Object Lock** y **cifrado** activados en rendimiento de lectura. 4. **Requisitos de proxies y red** para sostener ese rendimiento. 5. **SLA** de soporte “día D” fuera de horario. --- ## Coste y falso ahorro Una capa caliente cuesta más por TB. Pero **también cuesta** parar la empresa dos días por un cuello de botella **previsible**. El TCO relevante no es €/TB guardado, sino **€/hora de interrupción evitada**. Cuando una capa rápida recorta un día de parada, suele **pagarse sola**. > “El slide de dedupe se enseña antes de comprar. El reloj del RTO se enseña al comité de crisis. Adivina cuál decide tu futuro”, ironiza Carrero. --- ## Conclusión El backup ya no es un proyecto de almacenamiento: es una **capacidad de continuidad** que debe medirse en **tiempo** y **servicio**. La mayoría de los desastres recientes no se explican por falta de copias, sino por **incapacidad de servirlas al ritmo que el negocio exige**. Cambiar el marco mental —**comprar para restaurar**, medir **RPI**, separar **capa caliente/retención/inmutabilidad** y **ensayar** restauraciones masivas— marca la frontera entre un incidente bien resuelto y una **crisis**.