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
| Necesidad | Tipo de restauración | Notas |
|---|---|---|
| Un usuario borró una carpeta o un fichero | Guest file restore (restauración a nivel de fichero) | Minutos; se devuelve al servidor original o se descarga |
| Un servidor no arranca y la planta está parada | Instant Recovery | La VM arranca desde el repositorio en minutos; después hay que migrarla a producción con vMotion o Quick Migration |
| Un servidor dañado sin prisa extrema | Entire VM restore | Copia completa de los discos; tarda lo que tarde mover los datos |
| Solo un disco de datos | Virtual disk restore o Instant disk recovery | Útil para el disco de datos del servidor de ficheros |
| Una base de datos, un objeto de AD, un buzón | Veeam Explorers (SQL Server, Active Directory, Exchange, SharePoint, Oracle) | Requiere copias con procesamiento con reconocimiento de aplicaciones |
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
| Trimestre | Planta | Prueba | Responsable en la planta |
|---|---|---|---|
| T1 | Planta 01 | Entire VM restore del servidor de ficheros al segmento aislado | Jefe de mantenimiento |
| T1 | Planta 02 | Instant Recovery del servidor de etiquetado y migración | Responsable de logística |
| T2 | Planta 01 | Explorer for SQL Server: base del MES a un servidor de pruebas | Responsable de MES |
| T2 | Sede central | Restauración desde el repositorio inmutable | IT central |
| T3 | Planta 02 | Restauración de la planta entera en la sede central (simulacro de pérdida de la planta) | Director de planta |
| T4 | Todas | Guest file restore de una carpeta elegida por el usuario | Usuario clave de cada 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
| Sistema | RTO acordado | Tipo usado | Tiempo real | Resultado |
|---|---|---|---|---|
| srv-p1-fs01 (2,1 TB) | 4 h | Entire VM desde repositorio local | 3 h 10 min | Cumple |
| srv-p1-fs01 (2,1 TB) | 4 h | Entire VM desde la sede central | 11 h 40 min | No cumple: el enlace es de 500 Mb/s |
| srv-p2-mes01 | 1 h | Instant Recovery | 14 min hasta servicio | Cumple |
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.
- 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.
- 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- 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. - Comprobar con la planta que los datos están y son los esperados, y que no hay rastro del cifrado.
- Volver a producción cuando seguridad lo autorice: credenciales cambiadas, el vector de entrada identificado, la VM restaurada conectada a su red.
- 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.
What you'll get
When a plant asks for something back, you already know which restore to use, how long it will take and that it works, because you tested it last quarter. In a manufacturer with several sites, each plant has its own file server, its MES or labelling servers and often a local proxy and repository, with a link to head office that won't always move terabytes in a morning. The backup is already done; this guide is about the way back.
Before you start
- The inventory per plant: which virtual machines there are, what each does, who owns it at the plant and its agreed RTO and RPO.
- Where each copy lives: the plant's local repository, the copy at head office or another plant, and the immutable repository.
- Access to the Veeam Backup & Replication console with a named user holding a restore role.
- An isolated segment on each cluster (or the central one) to bring machines up without them seeing the production network.
1. Which restore for which need
| Need | Restore type | Notes |
|---|---|---|
| A user deleted a folder or a file | Guest file restore (file-level restore) | Minutes; restored to the original server or downloaded |
| A server won't boot and the plant has stopped | Instant Recovery | The VM boots from the repository in minutes; then it has to be migrated to production with vMotion or Quick Migration |
| A damaged server without extreme urgency | Entire VM restore | A full copy of the disks; it takes as long as moving the data takes |
| Just one data disk | Virtual disk restore or Instant disk recovery | Useful for the file server's data disk |
| A database, an AD object, a mailbox | Veeam Explorers (SQL Server, Active Directory, Exchange, SharePoint, Oracle) | Needs backups with application-aware processing |
Instant Recovery from a head office repository for a plant VM works, but the VM runs over the WAN link. For each plant's critical machines, the sensible thing is to keep the latest copy on a repository at the plant itself.
2. Automated tests with SureBackup
SureBackup boots machines from the backup in a virtual lab (an isolated network with a proxy that masquerades them), checks that they respond and shuts them down. For each plant:
- An application group with the dependencies: the plant's domain controller first, then the file server, the MES or labelling server.
- Checks per role: VMware Tools heartbeat, ping and a script that validates something real (that the share responds or that the MES service is running).
- The option to validate backup integrity and, if enabled in your version, the malware scan of the content.
SureBackup proves the backup boots and responds. It doesn't replace the manual test in section 3, which measures the full time until the plant could work.
3. The quarterly test calendar per plant
| Quarter | Plant | Test | Owner at the plant |
|---|---|---|---|
| Q1 | Plant 01 | Entire VM restore of the file server to the isolated segment | Maintenance manager |
| Q1 | Plant 02 | Instant Recovery of the labelling server and migration | Logistics lead |
| Q2 | Plant 01 | Explorer for SQL Server: MES database to a test server | MES lead |
| Q2 | Head office | Restore from the immutable repository | Central IT |
| Q3 | Plant 02 | Restore of the whole plant at head office (loss-of-plant drill) | Plant director |
| Q4 | All | Guest file restore of a folder chosen by the user | Key user at each plant |
- Tests run on days without critical production, agreed with the plant and in its local time.
- The plant checks the result: IT sees the VM boot; only the user knows whether the labelling application prints correctly.
4. Recording real time against the RTO
| System | Agreed RTO | Type used | Real time | Result |
|---|---|---|---|---|
| srv-p1-fs01 (2.1 TB) | 4 h | Entire VM from local repository | 3 h 10 min | Meets |
| srv-p1-fs01 (2.1 TB) | 4 h | Entire VM from head office | 11 h 40 min | Fails: the link is 500 Mb/s |
| srv-p2-mes01 | 1 h | Instant Recovery | 14 min to service | Meets |
The second line is the one that matters: if the local copy is lost, the RTO isn't met. It goes to the steering committee with two options (more bandwidth or a copy at a closer plant), not buried in a report.
5. Copies to another site and an immutable repository
- A backup copy job from each plant repository to head office (or another plant), outside shift hours if the link is shared with production.
- At least one copy on an immutable repository: a Hardened Repository on Linux with immutability configured, or object storage with Object Lock. An attacker with the Veeam administrator account can't delete those copies before the period expires.
- Veeam credentials outside the production domain, with MFA on the console, and the Veeam server without the same administrator accounts as the plant servers.
6. The ticket: "a plant file server was encrypted, restore it"
Monday, 07:20. Users at Plant 02 see files with an unknown extension and a ransom note in \\srv-p2-fs01\production.
- Contain first: this is a security incident, not a restore ticket. Alert the security lead, disconnect the VM's network (without deleting it, it is needed for the investigation) and check whether other machines are affected.
- Pick the clean point: not last night's by default. Check when files started changing and whether Veeam flagged any point as suspicious.
$b = Get-VBRBackup -Name "BJ-PLANT-02-DAILY"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- Restore to the isolated segment: Entire VM restore under another name (
srv-p2-fs01-r) with the network connected only to the isolated segment, using Secure Restore so the antivirus scans the disks before it boots. - Check with the plant that the data is there and is what they expect, and that there is no trace of the encryption.
- Return to production when security approves: credentials changed, the entry vector identified, the restored VM connected to its network.
- Communicate the data loss: everything created after the chosen point is lost. Say it with date and time, so the plant knows what it has to redo.
Next steps
- The Level 2 Veeam Backup guide covers jobs, repositories and the day-to-day running of backups.
- The Level 4 Backup and DR/BCP guide fits these tests into each plant's continuity plan.
- The VMware vSphere and vCenter guide helps prepare the isolated segment and the migration after an Instant Recovery.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →