Si prendés inline scan hoy en Veeam Backup & Replication, el primer backup no te va a avisar de nada. Y no es un bug: ese job arma la línea de base contra la que se comparan los siguientes.
Por qué el primer backup no cuenta
El inline scan analiza los bloques del flujo de backup con entropía. No es un escaneo completo del contenido. Su lógica es comparar un punto contra el anterior.
El detalle lo explicó Lei Wei en un hilo de la comunidad sobre 13.1: sin un índice previo, el primero queda como línea de base y no se analiza. Lo que ya estaba ahí pasa a ser lo normal.
La consecuencia es incómoda. Si la VM ya tenía un artefacto cuando activaste la función, no hay evento. Tampoco en los puntos siguientes, salvo que la cantidad aumente.
Qué pasa durante y después del job
Durante el job, el proxy escribe un RIDX por disco en una carpeta temporal. Cuando termina, Philippe Dupuis detalla que el índice viaja al backup server y el Data Analyzer lo compara con el anterior. Si encuentra actividad, crea el evento.
Hay dos costos para presupuestar. La primera corrida no usa CBT, así que la ventana crece, y lo mismo pasa al sumar un disco. Dupuis cita además 25 a 30 % más de CPU por proxy en 12.1.
El mail tampoco es inmediato. El servicio reinicia todos los días a las 00:00, actualiza listas y envía los eventos de las últimas 24 horas. Para verlo antes, entrá a History, Malware Detection, Malware Events.
Qué mira y qué se le escapa
Son tres señales, y cada una tiene su condición para disparar.
Para los artefactos de texto, Wei enumera otros requisitos: UTF-8, bloque de 4 KB y datos fuera de la MFT. Por eso un .txt muy chico puede pasar de largo.
En 12.1 también quedaban afuera ReFS, XFS, volúmenes dinámicos y BitLocker. Conviene confirmarlo en tu versión antes de confiarte.
Receta para probarlo en el lab
Con dos VMs Windows de prueba alcanza, y la idea es ver la diferencia entre plantar el artefacto antes y después de la base.
- Activá la función: en Malware Detection, pestaña Encryption Detection, tildá Enable inline entropy analysis y dejá la sensibilidad en Normal.
- Prepará un archivo de texto UTF-8 de más de 4 KB con una dirección v3 inventada: 56 caracteres
[a-z2-7]y.onion. No hace falta malware real. - En VM-B, copiá el archivo antes del primer backup. VM-A queda limpia.
- Corré el job. Es la línea de base de las dos, así que no debería haber eventos.
- Copiá el archivo en VM-A y volvé a correr el job.
- Revisá History, Malware Detection, Malware Events.
Según el comportamiento descripto, VM-A debería aparecer como Suspicious y VM-B no. Si querés que VM-B dispare, agregá más direcciones: lo que cuenta es que aumente la cantidad.
Cuando salta el evento
Un evento es una pista, no un veredicto, y el inline scan solo marca Suspicious. Marcar Infected es una decisión manual tuya sobre el restore point.
El punto donde se vio la actividad y los posteriores de esa máquina quedan marcados hasta que la marques limpia. Para ubicar el archivo en un evento de cifrado, en 12.1.2 se usaba find-encrypted-data.ps1; verificá si sigue vigente en tu versión.
Después toca buscar el último punto sano con Scan Backup, usando Veeam Threat Hunter o tu antivirus. Ese escaneo sí mira contenido, así que cubre el caso que la línea de base deja afuera.
Si fue un falso positivo, marcá la máquina como limpia en Inventory. Ojo: marcar un restore point desde Home solo afecta los puntos pasados.
Lo que me llevo
El inline scan detecta cambios, no presencia. Por eso conviene activarlo con un punto limpio conocido y sumarle un escaneo por contenido a lo que ya estaba.
¿Cuándo fue la última vez que probaste que tu detección dispara de verdad? Contame, o lo charlamos en la VUG Argentina.
Fuentes abiertas
- Veeam Help Center: Inline Scan, How Inline Scan Works, Encryption Detection, How Malware Detection Works, Scan Backup, Managing Malware Status (solo descripción)
- Veeam Blog: Veeam Data Platform v13.1
- Comunidad Veeam: Philippe Dupuis, 2024, Shane Williford, feb. 2024, Shane Williford, jul. 2024, hilo 13.1, ago. 2026
— Pablo · pablitocli