Todos los jobs de backup en verde. Retención correcta, copia offsite al día, informes semanales impecables. Y aun así, el día del desastre, la restauración falla: el controlador de dominio no arranca, la base de datos está corrupta o el backup lleva semanas guardando un ransomware dormido. Un backup que nunca se ha restaurado no es una garantía: es una esperanza.
La mayoría de los desastres de datos no se descubren cuando falla el backup, sino cuando falla la restauración. Un job puede terminar "Success" y aun así producir un punto de restauración inservible: corrupción silenciosa en el repositorio, una aplicación inconsistente dentro de la VM, credenciales caducadas o malware cifrando desde dentro. La única forma de saber que un backup restaura es restaurarlo, y hacerlo a mano para decenas de máquinas cada semana no escala.
En este artículo explicamos cómo SureBackup, la tecnología de verificación automática de Veeam, resuelve exactamente ese problema: qué es, cómo funciona por dentro, qué tests ejecuta, qué alternativas existen cuando no está disponible y qué métrica deberías estar midiendo desde ya.
La Regla 3-2-1-1-0: el Cero es la Parte que Todos Olvidan
La regla clásica 3-2-1 (tres copias de los datos, en dos soportes distintos, con una copia fuera de las instalaciones) evolucionó hace años a la regla 3-2-1-1-0: el segundo "1" exige que una de las copias sea offline o inmutable —fuera del alcance de un atacante con credenciales de administrador— y el "0" significa cero errores tras la verificación automática de la recuperación.
Ese último dígito es el que separa una política de backup de una política de recuperación. Puedes cumplir escrupulosamente el 3-2-1-1 y seguir sin saber si tus copias sirven para algo. Como explicamos en nuestro artículo sobre por qué un snapshot no es un backup, tener "algo" que se parece a una copia no equivale a poder recuperar el negocio: la recuperabilidad hay que demostrarla, no suponerla.
La pregunta correcta:
No es "¿se ejecutó el backup anoche?" sino "¿cuándo fue la última vez que demostrasteis que ese backup arranca y la aplicación responde?". Si la respuesta es "nunca" o "no lo sé", el plan de recuperación es teoría sin evidencia.
Qué es SureBackup: Arrancar el Backup sin Tocar Producción
SureBackup es la tecnología de verificación de recuperación de Veeam Backup & Replication. Su idea central es simple y potente: en lugar de comprobar el fichero de backup, arranca las máquinas virtuales directamente desde el backup en un entorno aislado llamado virtual lab, y ejecuta contra ellas una batería de tests. Si la VM arranca, la red responde y la aplicación contesta, el backup es recuperable de verdad, no en teoría.
Lo hace sin restaurar nada al almacenamiento de producción: las VMs se publican desde el repositorio mediante la tecnología de arranque instantáneo de Veeam y los cambios que generan durante el test se escriben en ficheros temporales que se descartan al terminar. El entorno de producción no se toca, las VMs originales siguen funcionando y no hay riesgo de conflictos de IP o de nombre, porque todo ocurre dentro de una red aislada. El proceso completo está documentado en la guía oficial de SureBackup de Veeam.
El resultado es que la verificación deja de ser un proyecto trimestral doloroso y pasa a ser un job programado más, que se ejecuta de madrugada después de las copias y deja un informe en tu buzón cada mañana.
Los Tres Componentes: Application Group, Virtual Lab y SureBackup Job
Una verificación SureBackup se construye con tres piezas que se configuran una vez y se reutilizan:
- check_circle Application group: define qué VMs arrancan y en qué orden. Las aplicaciones reales tienen dependencias: primero el controlador de dominio (DNS y autenticación), después la base de datos y por último el servidor de aplicación. Si se arranca todo a la vez, la verificación falla por dependencias, no porque el backup esté mal.
- check_circle Virtual lab: la red aislada donde viven las VMs durante el test. Un proxy appliance actúa de pasarela entre producción y el laboratorio, replicando dentro las redes de producción y enmascarando las IPs, de forma que las VMs verificadas conservan su configuración de red original sin colisionar con las máquinas reales.
- check_circle SureBackup job: el orquestador. Une el application group con el virtual lab, decide qué backups verificar, ejecuta los tests, recoge los resultados, genera el informe y desmonta el laboratorio al terminar.
Además de verificar, el mismo virtual lab sirve como entorno sandbox bajo demanda: probar un parche crítico, ensayar una migración o analizar un incidente sobre una copia exacta de producción, sin riesgo alguno.
Qué Tests Ejecuta SureBackup (y Qué Valida Cada Uno)
Cada nivel de test valida una capa distinta de la recuperación. Pasar el heartbeat no garantiza que la aplicación funcione; por eso los niveles se acumulan:
| Test | Qué valida | Qué detecta |
|---|---|---|
| Heartbeat | El sistema operativo arranca y las tools del hypervisor responden | VMs que no arrancan, SO corrupto, discos ilegibles |
| Ping | La pila de red de la VM está operativa y responde | Drivers de red rotos, configuración IP dañada |
| Test de aplicación (scripts) | El servicio responde de verdad: consulta SQL, petición HTTP, puerto abierto | BBDD que no montan, servicios caídos, aplicaciones inconsistentes |
| Análisis antimalware | El contenido del backup está libre de malware conocido | Ransomware dormido antes de restaurarlo a producción |
| Validación de integridad (CRC) | Los bloques del fichero de backup son legibles y coherentes | Corrupción silenciosa en el repositorio |
Los tests de aplicación son el nivel que de verdad diferencia una verificación seria: un script que lanza una consulta SQL contra la base de datos arrancada en el laboratorio, o una petición HTTP que espera un código 200 del servidor web, demuestra que el servicio completo —no solo el sistema operativo— es recuperable. Veeam incluye scripts predefinidos para los servicios habituales y admite scripts propios para aplicaciones a medida.
El análisis antimalware del backup merece mención aparte. Los atacantes modernos permanecen semanas dentro de la red antes de cifrar, y ese periodo queda capturado en las copias: restaurar un backup infectado equivale a reintroducir al atacante. Escanear el punto de restauración en el laboratorio aislado permite identificar el último punto limpio antes de llevarlo a producción, algo crítico en la recuperación de un incidente de ransomware.
Programación Periódica y Reports: Evidencia, no Fe
Un SureBackup job se programa como cualquier otro: por ejemplo, cada noche tras la ventana de backup para el application group crítico, y semanalmente para el resto de cargas. Al terminar, genera un informe automático con el resultado de cada VM y cada test, que se envía por correo a los responsables.
Ese informe vale más de lo que parece, porque convierte la recuperabilidad en evidencia documental:
- check_circle Auditorías: ISO 27001, ENS o NIS2 piden pruebas periódicas de recuperación. Un histórico de reports de SureBackup responde a ese control sin preparar nada ad hoc.
- check_circle Ciberseguro: las aseguradoras exigen cada vez más demostrar verificación de backups para emitir o renovar pólizas, y la evidencia acelera cualquier reclamación tras un incidente.
- check_circle Dirección: "el 100% de las VMs críticas verificadas esta semana" es un dato que un comité entiende; "los jobs terminan en verde" no dice nada sobre el riesgo real.
Sin SureBackup: Alternativas y Complementos
No todas las plataformas ni todas las licencias incluyen verificación automática con arranque de VMs. Eso no exime del "0" de la regla: cambia la herramienta, no el objetivo.
- arrow_right Restauraciones de prueba manuales programadas: un calendario trimestral que rota por las cargas críticas —este trimestre el ERP, el siguiente el correo, después el fileserver—, restaurando a un host o red aislada, arrancando la aplicación y documentando resultado y duración. Menos frecuente que SureBackup, pero infinitamente mejor que nada.
- arrow_right Verify jobs de Proxmox Backup Server: PBS verifica criptográficamente los chunks de cada snapshot contra sus checksums, detectando corrupción en el datastore. No demuestra que la VM arranque, pero garantiza la integridad del dato almacenado.
- arrow_right Checksums y health checks del repositorio: validaciones periódicas de integridad a nivel de fichero de backup (CRC), que atrapan la corrupción silenciosa de disco antes de que se propague a toda la cadena de restauración.
Lo ideal es combinar niveles: integridad continua (checksums, verify jobs) más arranque real periódico (SureBackup o restauración manual). La primera capa detecta datos rotos; la segunda, procesos rotos.
Qué Medir: RTA Real frente a RTO Prometido
Cada prueba de restauración —automática o manual— produce un dato valiosísimo que casi nadie apunta: el RTA (Recovery Time Actual), el tiempo real que costó recuperar el servicio. Ese número es el contraste empírico del RTO que figura en el plan de continuidad. Si tu RTO promete 4 horas y la última prueba tardó 9, no tienes un plan de recuperación: tienes un documento optimista.
Medir el RTA por aplicación, compararlo con el RTO comprometido y corregir la brecha (más ancho de banda de restauración, repositorios más rápidos, procedimientos ensayados) es la práctica que convierte los objetivos de recuperación en compromisos reales. Explicamos cómo definir y dimensionar estos objetivos en nuestra guía de disaster recovery, RPO y RTO.
Verificación con EasyDataHost: Cloud Connect y DRaaS
La verificación funciona igual de bien cuando la copia está fuera de tus instalaciones. Nuestro servicio de backup offsite con Veeam Cloud Connect te da un repositorio inmutable en nuestro datacenter de España que se integra en tu consola de Veeam como un repositorio más: tus SureBackup jobs pueden verificar también los puntos de restauración offsite, cerrando el ciclo 3-2-1-1-0 completo.
Y si lo que necesitas es garantizar el arranque completo de tu infraestructura en otro CPD, nuestro servicio de DRaaS con Veeam incluye pruebas de failover programadas: levantamos tus réplicas en nuestro entorno aislado, validamos aplicaciones y documentamos tiempos, sin interrumpir producción. Es el equivalente a SureBackup aplicado al plan de disaster recovery completo, con informe de RTA incluido para tus auditorías.
Preguntas Frecuentes
¿SureBackup afecta al entorno de producción?
No. Las VMs arrancan directamente desde el fichero de backup dentro de un virtual lab: una red aislada conectada a producción solo a través de un proxy appliance que enmascara las IPs. Las máquinas verificadas nunca tocan las originales y todos los cambios se descartan al terminar el job.
¿Con qué frecuencia debo ejecutar SureBackup?
Depende de la criticidad de cada carga. Como referencia: verificación semanal para las VMs críticas (controlador de dominio, bases de datos, ERP), mensual para el resto, y una ejecución adicional tras cualquier cambio relevante: actualizaciones mayores, migraciones o cambios de red y repositorio.
¿Qué edición de Veeam incluye SureBackup?
SureBackup está disponible en las ediciones Advanced y Premium de Veeam Data Platform (históricamente Enterprise y Enterprise Plus). Si tu licencia no lo incluye, puedes cubrir el mismo objetivo con restauraciones de prueba manuales programadas, verify jobs en Proxmox Backup Server y validación de checksums.
Conclusión
El estado "Success" de un job de backup mide que la copia se escribió, no que el negocio pueda recuperarse. La diferencia entre ambas cosas se descubre en el peor momento posible, salvo que la busques antes de forma deliberada:
- arrow_right La regla completa es 3-2-1-1-0: el cero —cero errores tras la verificación automática— es el que convierte las copias en garantía de recuperación.
- arrow_right SureBackup automatiza esa verificación: arranca las VMs desde el backup en un virtual lab aislado y ejecuta tests de heartbeat, ping, aplicación y análisis antimalware, sin tocar producción.
- arrow_right Sin SureBackup, el objetivo se cubre con restauraciones de prueba en calendario trimestral, verify jobs de PBS y checksums periódicos. La herramienta cambia; la obligación de verificar, no.
- arrow_right Mide el RTA real de cada prueba y compáralo con tu RTO: es el único dato que dice si tu plan de recuperación es un compromiso o una expectativa.
- arrow_right Con repositorios Cloud Connect inmutables y DRaaS con pruebas de failover, la verificación cubre también tu copia offsite y tu plan de DR completo.
Si quieres que revisemos tu estrategia de verificación —o montar desde cero un repositorio offsite verificable y un plan de DR con pruebas programadas—, contacta con nuestro equipo para un análisis sin compromiso.