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 (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
- TB/h de restauración con 200 VMs concurrentes rehidratando en topología real del cliente.
- Latencia y límites de streams al montar VMs por instant recovery.
- Impacto real de Object Lock y cifrado activados en rendimiento de lectura.
- Requisitos de proxies y red para sostener ese rendimiento.
- 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.
