Veeam: planificar y probar restauraciones en plantas y sedes, y un servidor de ficheros cifrado

Qué vas a conseguir

Que, cuando una planta pida recuperar algo, ya sepas qué restauración usar, cuánto va a tardar y que funciona, porque lo probaste el trimestre pasado. En una empresa industrial con varias sedes, cada planta tiene su servidor de ficheros, sus servidores de MES o de etiquetado y a menudo un proxy y un repositorio locales, con un enlace a la sede central que no siempre da para mover terabytes en una mañana. La copia ya está hecha; esta guía va de la vuelta.

Antes de empezar

• El inventario por planta: qué máquinas virtuales hay, qué hace cada una, quién es su responsable en la planta y su RTO y RPO acordados.
• Dónde está cada copia: repositorio local de la planta, copia en la sede central o en otra planta, y repositorio inmutable.
• Acceso a la consola de Veeam Backup & Replication con un usuario nominal con rol de restauración.
• Un segmento aislado en cada clúster (o en el central) para levantar máquinas sin que vean la red de producción.

1. Qué restauración para qué necesidad

Instant Recovery desde un repositorio en la sede central para una VM de la planta funciona, pero la VM corre sobre el enlace WAN. Para las máquinas críticas de cada planta, lo razonable es tener la copia más reciente en un repositorio de la propia planta.

2. Pruebas automáticas con SureBackup

SureBackup arranca las máquinas desde la copia en un laboratorio virtual (una red aislada con un proxy que las enmascara), comprueba que responden y las apaga. Para cada planta:

• Un grupo de aplicaciones con las dependencias: el controlador de dominio de la planta primero, después el servidor de ficheros, el de MES o el de etiquetado.
• Comprobaciones por rol: latido de VMware Tools, ping y un script que valida algo real (que el recurso compartido responde o que el servicio del MES está arrancado).
• La opción de verificar la integridad de la copia y, si está activada en tu versión, el análisis de malware del contenido.

SureBackup demuestra que la copia arranca y responde. No sustituye la prueba manual de la sección 3, que mide el tiempo completo hasta que la planta podría trabajar.

3. El calendario trimestral de pruebas por planta

• Se prueba en días sin producción crítica, acordados con la planta y con su hora local.
• Que la planta compruebe el resultado: IT ve que la VM arranca; solo el usuario sabe si la aplicación de etiquetado imprime bien.

4. Documentar el tiempo real frente al RTO

La segunda línea es la que importa: si la copia local se pierde, el RTO no se cumple. Se lleva al comité con dos opciones (más ancho de banda o una copia en otra planta más cercana), no se esconde en un informe.

5. Copia a otra sede y repositorio inmutable

• Backup copy job de cada repositorio de planta a la sede central (u otra planta), fuera del horario de turnos si el enlace es compartido con la producción.
• Al menos una copia en un repositorio inmutable: un Hardened Repository sobre Linux con inmutabilidad configurada o almacenamiento de objetos con Object Lock. Un atacante con la cuenta de administrador de Veeam no puede borrar esas copias antes de que venza el periodo.
• Las credenciales de Veeam fuera del dominio de producción, con MFA en la consola, y el servidor de Veeam sin las mismas cuentas de administrador que los servidores de la planta.

6. El ticket: "el servidor de ficheros de una planta está cifrado, restáuralo"

Lunes, 07:20. Los usuarios de la Planta 02 ven ficheros con una extensión desconocida y una nota de rescate en \\srv-p2-fs01\produccion.

1. Primero, contener: es un incidente de seguridad, no un ticket de restauración. Se avisa al responsable de seguridad, se desconecta la red de la VM (sin borrarla, sirve para la investigación) y se revisa si hay más máquinas afectadas.
2. Elegir el punto limpio: no el de anoche por defecto. Revisa cuándo empezaron a cambiar los ficheros y si Veeam marcó algún punto como sospechoso.

›$b = Get-VBRBackup -Name "BJ-PLANTA-02-DIARIO"›Get-VBRRestorePoint -Backup $b -Name "srv-p2-fs01" | Sort-Object CreationTime -Descending | Select-Object -First 4 Name, CreationTime, TypeName          CreationTime         Type----          ------------         ----srv-p2-fs01   27/10/2026 22:00:14  Incrementsrv-p2-fs01   26/10/2026 22:00:09  Incrementsrv-p2-fs01   25/10/2026 22:00:11  Incrementsrv-p2-fs01   24/10/2026 22:00:16  Full

1. Restaurar al segmento aislado: Entire VM restore con otro nombre (srv-p2-fs01-r) y la red conectada solo al segmento aislado, usando Secure Restore para que el antivirus revise los discos antes de arrancarla.
2. Comprobar con la planta que los datos están y son los esperados, y que no hay rastro del cifrado.
3. Volver a producción cuando seguridad lo autorice: credenciales cambiadas, el vector de entrada identificado, la VM restaurada conectada a su red.
4. Comunicar la pérdida de datos: todo lo creado después del punto elegido se ha perdido. Se dice con fecha y hora, para que la planta sepa qué tiene que rehacer.

Siguientes pasos

• La guía de Veeam Backup del Nivel 2 cubre trabajos, repositorios y el día a día de las copias.
• La de Backup y DR/BCP del Nivel 4 encaja estas pruebas en el plan de continuidad de cada planta.
• La de VMware vSphere y vCenter ayuda a preparar el segmento aislado y la migración tras un Instant Recovery.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.