Hay incidentes que lees en un reporte de amenazas y hay incidentes que te tocan en vivo. Este es de los segundos. Es un caso real en el que ayudé a recuperar un ambiente enorme después de un ransomware que no se conformó con cifrar máquinas virtuales: cifró los datastores del hipervisor completo, y de paso se llevó los respaldos. Lo que sigue es la historia de esa recuperación, y las lecciones que dejó, que son más valiosas que cualquier diagrama de arquitectura.
Nota sobre la confidencialidad: El caso es real. Los datos que podrían identificar al cliente, su ubicación, su sector o el grupo de ransomware fueron omitidos o generalizados a propósito. Las cifras están redondeadas. Lo que comparto es el cómo y el por qué, no el quién.
El llamado#
Me contactaron para ayudar en una recuperación que sonaba imposible. Del otro lado había un proveedor que administraba la infraestructura de múltiples clientes en más de una decena de países. La descripción inicial ya era de las que te enderezan en la silla: un ransomware había cifrado los datastores de más de 400 nodos del hipervisor. No una máquina. No un cluster. La capa de virtualización completa. Y con ella, alrededor de 20 mil máquinas virtuales de gobiernos y empresas repartidas por varios países.
La frase que terminó de dimensionar el problema vino después: los repositorios de Veeam también estaban abajo.
Ahí es donde este caso deja de ser un incidente de ransomware común y se convierte en algo mucho más serio. Cuando el ataque también se lleva tu última línea de defensa, el respaldo, ya no estás recuperando, estás haciendo arqueología.
Llegamos directo al War Room#
Cuando aterrizamos, fuimos directo al cliente. Ni pasamos por el hotel. Llegamos a una sala donde el equipo ya llevaba tiempo en modo crisis, y lo que encontramos no fue gente buscando la mejor herramienta, sino gente buscando cualquier herramienta. Algunos ya estaban evaluando opciones manuales de recuperación de datos, como TestDisk, una utilidad opensource que funciona, pero que en un ambiente de petabytes puede tardar una eternidad. Cuando la única opción sobre la mesa es una que tardaría semanas, ya sabes que el plan no existía.
Con mi compañero hicimos las preguntas de rigor: ¿probaron esto, aquello, lo otro? ¿Agotaron todas las opciones antes de llegar a esto? La respuesta fue que sí, ya habían intentado todo lo que conocían. El ambiente en la sala era el de un equipo agotado. Algunos ya estaban entregados, asumiendo que la data se había perdido para siempre. Pero en estos casos siempre queda una brasa de esperanza de que algo se puede rescatar, y esa esperanza era justo lo que nos habían llamado a sostener.
El diseño que se volvió en contra#
Para entender por qué cayeron los respaldos junto con todo lo demás, hay que mirar la arquitectura. Los repositorios de Veeam de este ambiente eran máquinas virtuales corriendo Ubuntu 18.04, y el almacenamiento de respaldo estaba conectado a esas VMs mediante RDM (Raw Device Mapping) directo desde el storage.
Suena razonable sobre el papel. En la práctica, significaba que los repositorios vivían sobre la misma infraestructura que estaban protegiendo. Cuando el ransomware cifró los datastores, no había ninguna separación real entre el dato productivo y el respaldo. El respaldo no estaba en otro plano, estaba en el mismo barco.
Esta es la primera lección, y la pongo arriba porque es la que más duele: un repositorio de respaldo que depende de la misma infraestructura que protege no es un respaldo, es una copia que comparte el mismo destino.
Y acá conviene ser directo: nada de esto fue una falla de Veeam. Los respaldos existían, estaban completos y, como veremos, se pudieron recuperar enteros. Lo que falló fue la arquitectura alrededor de ellos y la ausencia de controles básicos. Montar los repositorios como máquinas virtuales con RDM sobre el mismo storage que se protege no es la arquitectura recomendada, es justo lo que las buenas prácticas piden evitar. Veeam ofrece exactamente los controles que habrían neutralizado este ataque, Hardened Repository físico, inmutabilidad, Object Storage con Object Lock y hoy por supuesto, Veeam Data Cloud Vault, pero no estaban implementados. La herramienta estaba lista para hacer su trabajo; el diseño no la dejó.
El nudo técnico: cuando el filesystem se rompe solo#
Acá viene la parte que convirtió esto en un trabajo de forense más que de operación.
Cuando los datastores fueron cifrados, los volúmenes RDM que alimentaban a los repositorios se desmontaron de forma inesperada. Un desmontaje sucio de un volumen activo es la receta perfecta para corromper un sistema de archivos, y eso fue exactamente lo que pasó: los volúmenes quedaron con el filesystem XFS corrupto.
Al intentar remontarlos, no mostraban nada. El sistema solo informaba que el filesystem estaba corrupto. Los respaldos estaban ahí, físicamente, pero el sistema operativo no podía leerlos.
El primer intento fue reparar el XFS desde la misma versión de Ubuntu que usaban, la 18.04. No funcionó. Esa versión arrastraba un comportamiento conocido en las herramientas de XFS que impedía leer o reparar correctamente el sistema de archivos en este escenario. Estábamos intentando abrir una caja fuerte con la llave que justamente no abría.
La recuperación: trabajar sobre una copia, nunca sobre el original#
El segundo día llegamos muy temprano a la oficina a armar el plan de acción: entender realmente cómo habían sido afectados los repositorios de Veeam, qué arquitectura tenían, cómo había sido el ataque, y confirmar que ya disponían de servidores físicos y un ambiente vSphere nuevo y funcionando donde restaurar. La presión era gigante, de esas en las que todos te miran esperando una respuesta. Así que le pedí a mi compañero un favor concreto: que él hablara con el cliente y me dejara tranquilo, para concentrarme solo en una cosa, recuperar los repositorios. En una crisis, aislar a la persona que está resolviendo el nudo técnico del ruido de la sala vale más de lo que parece.
La salida fue cambiar de herramienta. Pedí que actualizaran a una versión más reciente de Ubuntu, la 20.04, que traía versiones más nuevas de las utilidades de XFS capaces de manejar la reparación que necesitábamos. Suena simple, pero el internet del ambiente estaba estrictamente restringido y la ISO bajaba lentísimo. Esperar esa descarga, sabiendo que todo dependía de ella, fue de las horas más largas.
Pero antes de tocar nada, la regla de oro de cualquier recuperación forense: nunca trabajas sobre el dato original. Pedí que tomaran un snapshot de la LUN para poder trabajar sobre una copia del volumen RDM. Si la reparación salía mal, no quería destruir la única evidencia que nos quedaba.
Acá apareció un problema que no estaba en ningún manual: en varios casos no quedaba espacio para tomar el snapshot de los volúmenes RDM. El administrador de storage tuvo que entrar a recuperar espacio sobre la marcha para poder generar el necesario y trabajar sobre la copia sin arriesgar el original. Detalle pequeño, impacto enorme: sin ese espacio, no había recuperación segura posible.
Con la copia montada y las herramientas correctas, ejecuté el proceso de reparación de XFS. Y funcionó. Cuando el filesystem volvió a montar y aparecieron los archivos .vbk y .vib, los fulls y los incrementales de Veeam, fue uno de esos momentos de alegría pura que justifican todas las horas anteriores. Ya no era arqueología, ya los podíamos ver. Recuperé los datos y, con ellos, todos los respaldos existentes y sus cadenas completas. Las cadenas intactas eran clave: sin la cadena, un respaldo incremental no sirve de nada.
Con los respaldos en mano, el resto era territorio conocido de Veeam: importar los respaldos recuperados a un servidor de Veeam Backup & Replication, y restaurar la primera máquina sobre un host de VMware nuevo que se había aprovisionado limpio. Cuando esa primera VM levantó y dio servicio, supimos dos cosas: que el proceso funcionaba, y que se podía replicar. Para entonces ya llevábamos más de 12 horas seguidas, así que documentamos lo que teníamos y nos fuimos al hotel a dormir algo, porque el día siguiente, domingo, había que convertir ese primer éxito en un proceso.
De una recuperación a veinte mil#
Recuperar una máquina es muy fácil con Veeam. Recuperar veinte mil, sobre múltiples volúmenes de varios petabytes de datos, es un proceso industrial, y ahí el trabajo cambió de naturaleza. Lo primero fue documentar el procedimiento completo, paso a paso, para que no dependiera de mí ni de nadie en particular. Un procedimiento simple y repetible vale más que un experto que no escala.
Con el procedimiento listo, la estrategia fue paralelizar todo. Se desplegaron múltiples servidores de Veeam Backup & Replication para poder correr muchas recuperaciones en simultáneo, y según el tamaño y la urgencia de cada carga se elegía la técnica:
- Instant VM Recovery para levantar rápido las máquinas críticas, arrancándolas directamente desde el respaldo mientras se hacía la migración en segundo plano.
- Full VM Restore para las que requerían volver completas a producción sin compromiso de ejecución o tiempo.
A pesar de la magnitud, la recuperación avanzó rápido, justamente porque el procedimiento era sencillo y la paralelización multiplicaba la capacidad.
Si se apagaba, no volvía: respaldar lo que seguía en ejecución#
Hubo un escenario que no estaba previsto por el tipo de cifrado. Algunas máquinas habían quedado funcionando y dando servicio, pero su datastore estaba cifrado. Es decir: la VM seguía viva en memoria, atendiendo, pero el almacenamiento debajo de ella era inservible. Si se apagaba, no volvía. Y no teníamos un respaldo limpio de ellas. El respaldo tradicional a nivel de hipervisor tampoco era opción: para respaldar una VM, el hipervisor necesita crear snapshots sobre ese mismo datastore, y con el datastore cifrado esa vía estaba muerta.
La solución se nos ocurrió saltándonos el problema en vez de enfrentarlo de frente: instalar Veeam Agent for Windows dentro de esas máquinas para respaldarlas como si fueran servidores físicos, leyendo el sistema operativo desde adentro y evitando por completo la capa del datastore cifrado. Para las máquinas Linux en la misma situación, la misma estrategia con Veeam Agent for Linux.
Funcionó. Una vez que teníamos un respaldo sano hecho por el agente, solo había que hacer Instant VM Recovery desde ese respaldo para tener la máquina de vuelta, ya sin depender del datastore comprometido. Ese truco, sencillo de explicar pero fácil de pasar por alto bajo presión, salvó cargas que de otra forma se habrían perdido al primer reinicio.
La identidad que no estaba respaldada#
Hubo un problema que apareció temprano y que complicó todo lo que vino después: no había respaldos actualizados del sistema de identidad. Ni Microsoft Active Directory, ni Entra ID. La columna vertebral de autenticación de todo el ambiente, sin una copia confiable de donde recuperarla.
Eso nos obligó a trabajar con cuentas locales en cada máquina. En un ambiente de 20 mil VMs, operar con cuentas locales es lento, inseguro y no escala. La identidad es de lo primero que necesitas en una recuperación, porque sin un directorio no puedes ni entrar de forma ordenada a los sistemas que estás levantando, ni delegar accesos, ni mantener trazabilidad de quién hizo qué. Un respaldo de Active Directory o Entra ID inexistente o desactualizado convierte cada acceso en un problema, y multiplica el tiempo de todo lo demás.
El RTO estaba resuelto, el RPO era una incógnita#
Instant VM Recovery nos resolvió el RTO: las máquinas volvían rápido. Pero el RTO es solo la mitad de la ecuación. La otra mitad, el RPO, se estaba manejando a ciegas.
Acá apareció otro vacío que nadie había contemplado: no existía ningún proceso para documentar lo que se estaba recuperando. ¿Qué punto de restauración se usó para cada máquina? ¿Fue el último respaldo, o hubo que volver a uno anterior? ¿De qué fecha era? Porque en varios casos, por la corrupción del filesystem, el último punto no servía y había que retroceder a un respaldo previo. Y retroceder a un respaldo previo significa una cosa concreta: pérdida de datos.
La pregunta que nadie podía responder era justamente la más importante para el dueño de cada servicio: ¿cuántos datos, de cuánto tiempo, se perdieron en esta máquina? Sin un registro de qué punto se usó y de qué fecha era, los usuarios de esos servidores no tenían forma de saber qué información habían perdido ni desde dónde reconstruir.
Y esa es una diferencia enorme. Recuperar la máquina es la parte técnica. Poder decirle al área de negocio “este sistema volvió al estado de tal fecha y hora, perdiste esta ventana de datos, reconstruye desde acá” es la parte que de verdad le importa al cliente. Sin documentación del punto de restauración y del RPO real de cada carga, esa conversación es imposible, y el negocio queda reconstruyendo a ciegas.
El fin de semana contra el reloj#
El domingo llegamos temprano otra vez, ya con la estrategia de recuperación en la mano. Ese día hicimos varias pruebas de recuperación, tomando máquinas al azar y también países al azar, para validar que el proceso aguantaba distintos escenarios. Pero cuando preguntamos al cliente qué recuperar con prioridad, qué países, qué servicios, la respuesta fue que mejor esperáramos al lunes: ahí llegarían más personas del comité ejecutivo y recién entonces se tomarían las decisiones correctas. Así que nos fuimos temprano a descansar, porque sabíamos que el lunes empezaba lo bueno.
El lunes arrancó la recuperación masiva en serio. Compartí el proceso documentado con todas las personas involucradas, levantamos los servidores de Veeam en paralelo y, entre la gente en la sala y los equipos conectados de forma remota trabajando las 24 horas, la máquina por fin giraba a toda velocidad. Y fue justo ahí, con todo listo para recuperar a escala, cuando quedó en evidencia el único problema que no podíamos resolver con tecnología: nadie sabía en qué orden hacerlo.
¿Qué recuperamos primero? La pregunta que nadie podía responder#
Y acá llegamos a la parte que más me marcó, porque no fue un problema técnico. Fue un problema de decisión, y de los que no se resuelven con Veeam.
Cuando el procedimiento ya funcionaba y teníamos capacidad para recuperar en paralelo, apareció la pregunta más difícil de todas: ¿qué recuperamos primero? ¿Qué país? ¿Qué cliente? ¿Lo que afecta a la ciudadanía? ¿Lo que afecta a un gobierno?
El cliente no tenía respuesta. No existía un plan de recuperación ante incidentes. No había forma de identificar qué servicios eran más críticos, ni un criterio de priorización por cliente, por impacto o por lo que fuera. En el momento más caro de toda la crisis, la organización estaba decidiendo el orden de recuperación a pulso.
Para un proveedor que aloja cargas de terceros esto es especialmente grave, porque la pregunta tiene respuesta, pero la respuesta se construye antes, no durante. Un proveedor puede y debe saber qué tan críticas son las cargas que aloja en sus datacenters, y eso se define en el onboarding del cliente, cuando se montan los servicios. No a las 3 de la mañana con el ambiente en llamas.
La recomendación que terminé dando fue un criterio simple, casi de sentido común, pero que en medio del caos nadie había articulado: si afecta a la ciudadanía de un país, se empieza por ahí. Había entidades gubernamentales cuya caída golpeaba directamente a las personas, así que esas iban primero, y después las empresas. Un criterio de impacto humano antes que de cualquier otra cosa.
La recuperación no termina cuando las VMs vuelven#
Cuando las máquinas empezaron a volver, había una sensación de alivio que era prematura. Levantamos los servicios, sí, pero nadie hizo un análisis de seguridad del ambiente recuperado, al menos en el perímetro. Y eso me preocupaba por una razón muy concreta.
Una de las causas de la intrusión fue el uso de cuentas privilegiadas. Los atacantes no forzaron nada exótico, entraron con credenciales válidas. Entonces la pregunta obvia, la que nadie se estaba haciendo, era: ¿y si dejaron un backdoor? ¿Y si la máquina que tenía la vulnerabilidad que usaron para entrar sigue con esa vulnerabilidad después de recuperarla?
Porque ahí está la trampa: si recuperas el ambiente tal cual estaba, también recuperas el agujero por el que entraron. Restaurar un respaldo previo al incidente es restaurar también la puerta abierta. Los atacantes podían volver a explotar la misma vulnerabilidad e ingresar de nuevo, esta vez a un ambiente recién recuperado y con todos exhaustos.
Recuperar sin revisar la seguridad es reconstruir la casa con la misma cerradura forzada. Esa fue, de hecho, una de las razones por las que terminé desarrollando vScan, una herramienta para analizar la postura de seguridad del ambiente, identificar vulnerabilidades y puntos de entrada antes de declarar la recuperación como exitosa. Porque “las VMs están arriba” no es lo mismo que “el ambiente está seguro”, y confundir las dos cosas es cómo terminas viviendo el mismo incidente dos veces.
El desenlace#
Dejamos todo el proceso documentado de punta a punta: la reparación del filesystem, el montaje, el rescaneo, la validación de los puntos de restauración y la elección del tipo de recuperación, Instant VM Recovery o Full VM Restore, hacia los hosts nuevos. Esa fue la idea desde el principio: que la recuperación no dependiera de mí ni de mi compañero, sino de un procedimiento que cualquiera del equipo pudiera ejecutar. Nosotros estuvimos en terreno tres o cuatro días; el procedimiento se quedó para siempre.
Y funcionó. El personal a cargo siguió aplicando el proceso, recuperando las máquinas en el orden que el negocio había definido por país y criticidad, y el ambiente volvió a operar en muy poco tiempo para la envergadura del ataque. El mismo equipo que el primer día estaba entregado, asumiendo que la data se había perdido, terminó recuperando el ambiente completo con un procedimiento que cabía en una página.
Pero lo que más me dejó tranquilo vino después. El cliente implementó las buenas prácticas que les dejamos escritas: una arquitectura con inmutabilidad, copias múltiples, análisis de malware sobre los respaldos, y planes de IRP y DRP dimensionados según el nivel de criticidad que define el negocio. No se quedaron en la recuperación, cerraron las puertas que habían quedado abiertas. De ahí en adelante siguieron sumando buenas prácticas de Veeam, y todavía nos mantenemos en contacto, cruzándonos en los viajes. Esa, al final, es la mejor señal de que el trabajo quedó bien hecho: no la recuperación en sí, sino que nunca más volvieron a necesitar una igual.
Lo que este caso enseña#
La recuperación salió bien. Dado el tamaño del ataque, el ambiente volvió a operar en muy poco tiempo. Pero un final feliz no borra el hecho de que casi todo lo que hizo esta crisis tan difícil era evitable. Estas son las lecciones, separadas en las dos capas donde duelen.
Lecciones de arquitectura#
1. Tus respaldos no pueden compartir destino con lo que protegen. Repositorios virtuales con RDM sobre el mismo storage cifrado significó que el respaldo cayó junto con la producción. Un Hardened Repository físico, sobre Linux y con inmutabilidad nativa, vive fuera del alcance de un ransomware que ataca el hipervisor.
2. Sin inmutabilidad, estás a un paso de distancia del desastre. Si esos respaldos hubieran estado en un repositorio inmutable o en Veeam Data Cloud Vault, no habría hecho falta ninguna reparación forense de XFS. La recuperación habría sido simple, que es exactamente como debe ser una recuperación.
3. La regla 3-2-1-1-0 no es decorativa. Faltaba la copia offline o air-gapped, y faltaban copias múltiples de los respaldos. Una sola copia, en un solo plano, es un punto único de falla esperando su turno. Es, literalmente, poner todos los huevos en la misma canasta.
4. Tu sistema de identidad es el primer servicio a recuperar, y necesita su propio respaldo. No tener un respaldo reciente y confiable de Active Directory o Entra ID nos obligó a trabajar todo con cuentas locales, lo que ralentizó cada acceso en un ambiente de 20 mil VMs. Sin directorio no hay recuperación ordenada.
5. En forense, siempre se trabaja sobre una copia. El snapshot de la LUN para reparar el XFS sin tocar el original fue lo que permitió equivocarse sin consecuencias. Y el espacio para ese snapshot tiene que existir antes de necesitarlo.
6. Conoce las herramientas, no solo el producto. El bug de XFS en Ubuntu 18.04 pudo haber detenido toda la recuperación. Saber que actualizar a la 20.04 traía utilidades capaces de hacer el trabajo fue la diferencia entre recuperar y rendirse.
7. El Veeam Agent es una salida de emergencia que pocos tienen mapeada. Respaldar una VM viva como si fuera física, saltándose el datastore comprometido, es un recurso que conviene conocer antes de necesitarlo.
8. La recuperación a escala se gana con paralelización. Múltiples servidores de Veeam Backup & Replication e Instant VM Recovery para lo urgente fue lo que convirtió un proceso imposible en uno manejable.
Lecciones de proceso, que son las que más cuestan#
9. No tener un DRP ni un IRP es la verdadera vulnerabilidad. No había plan de recuperación ante desastres, ni plan de respuesta a incidentes, ni una guía simple de qué hacer ante un ataque. El stack técnico se puede improvisar bajo presión, pero la decisión de qué recuperar primero, no.
10. La criticidad de los servicios se define antes, no durante. Para un proveedor que administra infraestructura de múltiples clientes, clasificar la criticidad de cada carga en el onboarding no es burocracia, es el insumo que te permite priorizar cuando todo se cae al mismo tiempo.
11. Documentar cada recuperación no es burocracia, es lo que le permite al negocio reconstruir. Qué punto de restauración se usó, de qué fecha era, cuál fue el RPO real de cada carga. El RTO lo resolvimos con Instant VM Recovery, pero sin registrar la brecha de datos de cada máquina, los dueños de los servicios no sabían cuánta información perdieron ni desde dónde reconstruir.
12. Si nunca lo ensayaste, no lo sabes hacer. Nadie había hecho un tabletop ni un simulacro de un incidente de esta escala. El primer ensayo no puede ser el evento real.
13. Las credenciales débiles convierten un incidente en una catástrofe. El detalle aburrido de siempre, que en una crisis se vuelve el más caro. Y en este caso, las cuentas privilegiadas fueron justamente la vía de entrada del ataque.
14. Un respaldo que no escaneas puede reinfectarte al restaurar. Sin análisis de malware sobre los respaldos, cada restauración es una ruleta. Veeam Threat Hunter y Secure Restore existen justamente para no volver a meter la amenaza a producción.
15. La recuperación no termina hasta que validaste que el atacante no puede volver a entrar. Recuperar el ambiente tal cual estaba es recuperar también el agujero por el que entraron. Análisis de seguridad post-recuperación, escaneo de vulnerabilidades, revisión del perímetro, rotación de credenciales y caza de amenazas sobre lo recuperado. Esa necesidad fue una de las razones por las que terminé desarrollando vScan.
16. El war room necesita estructura. La improvisación en la sala de crisis cuesta horas, y en un incidente las horas son dinero y, a veces, servicios públicos caídos. Marcos como NIST SP 800-61r3 existen para que esa estructura no se invente sobre la marcha.
No había que inventar nada: el mapa ya existe#
Si algo deja claro este caso es que la organización no necesitaba ser pionera en nada. Todo lo que faltaba ya está escrito en estándares maduros y públicos. La resiliencia no es un acto de creatividad bajo presión, es la aplicación disciplinada de marcos que existen hace años.
- NIST SP 800-184 (Guide for Cybersecurity Event Recovery): es, literalmente, la guía para recuperarse de un evento como este.
- NIST SP 800-61r3 y el ciclo PICERL de SANS (Preparación, Identificación, Contención, Erradicación, Recuperación, Lecciones aprendidas): el proceso de respuesta a incidentes, el IRP.
- NIST SP 800-34 (Contingency Planning Guide): la base del plan de recuperación ante desastres, el DRP.
- ISO 22301 e ISO/IEC 27031: continuidad del negocio y preparación de TI para sostenerla.
- NIST Cybersecurity Framework 2.0: el marco paraguas, con sus funciones de Responder (Respond) y Recuperar (Recover) que ordenan todo lo anterior.
- La regla 3-2-1-1-0: al menos 3 copias de los datos, en 2 medios distintos, 1 fuera de sitio, 1 offline o inmutable, y 0 errores tras verificar la recuperabilidad. La buena práctica de respaldo que, por sí sola, habría cambiado el desenlace de este caso.
No hace falta adoptarlos todos de golpe ni al pie de la letra. Pero tener un IRP y un DRP escritos, una clasificación de criticidad por servicio y una arquitectura de respaldo alineada a estas guías es, exactamente, la diferencia entre una crisis ordenada y una a las 3 de la mañana sin saber por dónde empezar.
La conclusión incómoda#
La parte difícil de este caso no fue la reparación del XFS, ni el truco del Veeam Agent, ni la paralelización. Todo eso fue trabajo técnico, intenso pero acotado. La parte difícil fue descubrir, en plena crisis, que la organización no tenía ninguna respuesta a la pregunta más básica de la resiliencia: cuando todo se cae, ¿en qué orden lo levantamos?
La resiliencia no es la herramienta de respaldo. La herramienta es necesaria, pero es la parte fácil. La resiliencia es haber decidido, mucho antes del incidente, qué es lo que más importa, dónde están tus copias, quién toma las decisiones y en qué orden se recupera. Todo eso se construye en frío. Si lo dejas para el día del ataque, ya es tarde.
Si tu organización o tus clientes dependen de que sepas recuperar bajo presión, conviene tener esta conversación antes de que sea urgente. Escríbeme por LinkedIn o sigue el feed de 24xsiempre.com para más contenido sobre resiliencia, respaldo y recuperación real.
Preguntas frecuentes#
¿Se puede recuperar un respaldo de Veeam si el repositorio queda con el filesystem corrupto?#
Sí. Si el respaldo existe y la corrupción es del sistema de archivos (no de los datos en sí), se puede reparar el filesystem y recuperar los archivos de respaldo con sus cadenas. En este caso, los volúmenes XFS quedaron corruptos tras un desmontaje sucio, pero al repararlos aparecieron intactos los archivos .vbk y .vib, que luego se importaron a un servidor de Veeam Backup & Replication para restaurar.
¿Cómo se repara un sistema de archivos XFS corrupto?#
Trabajando siempre sobre una copia del volumen (un snapshot de la LUN), nunca sobre el original, y con las utilidades de XFS de una versión reciente del sistema operativo. En este caso, la versión vieja de Ubuntu (18.04) arrastraba un comportamiento que impedía la reparación, y actualizar a la 20.04 con utilidades más nuevas fue lo que permitió montar y recuperar los datos.
¿Cómo respaldar una VM si su datastore está cifrado pero la máquina sigue encendida?#
Instalando un agente de respaldo dentro de la VM (Veeam Agent for Windows o Linux) para respaldarla como si fuera un servidor físico, leyendo el sistema operativo desde adentro y evitando por completo la capa del datastore comprometido. Luego se hace Instant VM Recovery desde ese respaldo del agente.
¿Por qué cayeron los respaldos de Veeam en este ataque?#
No por una falla de Veeam, sino por la arquitectura. Los repositorios eran máquinas virtuales con discos RDM sobre el mismo storage que protegían, así que al cifrarse los datastores cayeron junto con la producción. Los controles que lo habrían evitado (Hardened Repository físico, inmutabilidad, Veeam Vault) no estaban implementados.
¿Qué controles previenen un ransomware a nivel de hipervisor?#
Aislar el repositorio de la infraestructura que protege (Hardened Repository físico), inmutabilidad de los respaldos, object storage con Object Lock o Veeam Vault, la regla 3-2-1-1-0 con al menos una copia offline o air-gapped, y escaneo de malware sobre los respaldos antes de restaurar.
¿Por dónde se empieza a recuperar cuando se cae todo al mismo tiempo?#
Por impacto humano: primero los servicios que afectan a la ciudadanía (gobierno y servicios públicos esenciales), luego las empresas críticas, y después el resto. Pero ese orden no se improvisa en la crisis, se define antes en el plan de respuesta a incidentes y en la clasificación de criticidad de cada servicio.
