Veeam Backup: crear un trabajo, comprobar que termina bien y hacer una restauración de pruebaVeeam Backup: creating a job, checking it completes, and running a test restore

Qué vas a conseguir

Un trabajo de copia en Veeam Backup & Replication que protege las máquinas virtuales de un servicio, con retención definida, y la rutina que de verdad importa: leer el resultado cada mañana y restaurar algo cada mes para saber que funciona.

Antes de empezar

• Acceso a la consola de Veeam con rol Backup Administrator (o Backup Operator para restaurar sin cambiar trabajos).
• El hipervisor añadido en Inventory (vCenter o Hyper-V) con una cuenta de solo lectura más los permisos de snapshot que Veeam documenta.
• Un repositorio con espacio: como regla, 2-3 veces el tamaño de los datos protegidos para dos semanas de retención con incrementales.
• Para el 3-2-1: una segunda copia fuera (otro sitio, cinta o nube) planificada como *Backup Copy Job*; esta guía monta la primera.

1. El trabajo de copia

Dos decisiones que importan: application-aware processing para la VM de base de datos (hace la copia consistente con VSS y trunca los logs de SQL si lo configuras), y la retención acordada con negocio, no inventada: 14 puntos diarios + 4 semanales + 3 mensuales cubre "lo que había hace tres meses".

Un job por servicio, no uno gigante. Así un fallo en una VM no deja sin copia a otras, y el informe de la mañana dice qué servicio está sin proteger.

2. Leer el resultado cada mañana

El correo de Veeam (o el panel Home → Last 24 hours) tiene tres colores y hay que mirar los tres:

• Success: todo bien. Aun así, mira el tamaño transferido: un incremental que de repente pesa como un full suele ser un cambio masivo (actualización, cifrado por ransomware, un disco añadido).
• Warning: la copia existe pero algo no fue como debía. El de VSS de arriba es el más frecuente: la cuenta de guest processing no tiene permisos, o el servicio VSS en la VM está roto. No se ignora dos días seguidos.
• Failed: esa VM no tiene copia de hoy. dc-02 ha desaparecido del inventario (borrada, migrada a otro clúster, renombrada): hay que actualizar el job y lanzar un Retry.

El informe que llevas a la reunión semanal: Reports → Backup Job Reports o, mejor, Veeam ONE si está instalado, con el porcentaje de éxito por job y las VMs sin copia en 7 días.

3. Restaurar un fichero

Keep deja el original y añade la versión restaurada al lado; Overwrite pisa el actual. Para un usuario que ha borrado o sobrescrito un fichero, Copy To una carpeta tuya y entregárselo es lo más seguro. Todo el proceso tarda minutos y no toca la VM.

4. Restaurar una máquina entera (la prueba mensual)

Una vez al mes, restaura una VM en un entorno aislado y comprueba que arranca y que la aplicación responde. Es lo único que demuestra que la copia sirve.

Con SureBackup (Veeam lo automatiza) la prueba se programa y el informe dice cada semana si cada VM arranca. Sin SureBackup, la prueba manual con una VM distinta cada mes y una línea en el ticket de cambios es suficiente, y es lo que piden las auditorías.

Restaurar una VM en producción con la misma red y el mismo nombre mientras la original está encendida provoca un conflicto de IP y de identidad en el dominio. Siempre a red aislada o con la original apagada.

5. Qué poner en el ticket

Nombre del job, VM, punto de restauración usado, dónde se restauró, cuánto tardó y la comprobación hecha (fichero abierto, aplicación responde). Esa línea es la evidencia del DR/BCP.

Siguientes pasos

• Monta el Backup Copy Job a un segundo repositorio (otro sitio, S3 con inmutabilidad, cinta): sin él no hay 3-2-1.
• Activa la inmutabilidad en el repositorio si lo soporta (Linux hardened repository u object lock): es lo que salva la copia en un ransomware.
• En el Nivel 4 verás DR/BCP de principio a fin: planes, pruebas de recuperación completas y los tiempos (RPO/RTO) que negocias con cada servicio.

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