Un backup job de Veeam es la regla que dice qué se copia, a dónde, cuándo y cuánto tiempo se conserva. Casi todo lo que sale bien o mal en un esquema de respaldo se decide en su configuración: el método, la retención, la coherencia de las aplicaciones y la hora. Por eso esta guía recorre cada opción con los dos trabajos de un caso real y termina con la copia fuera de la sede.
Además, está escrita en dos niveles. Si usted responde por cuánta información puede perder la empresa, las tablas del caso le dicen qué se consigue y a qué costo. En cambio, si configura los trabajos, encontrará los métodos, las reglas de la retención GFS, las limitaciones del complemento de Proxmox y los comandos para revisarlos.
La serie y el caso común
En concreto, esta es la quinta de siete guías que comparten el mismo caso. Por eso los trabajos de aquí copian las siete máquinas del mapa de la primera guía y escriben en el repositorio endurecido que dimensionó la cuarta.
- Qué es y para qué sirve, con el mapa de protección.
- Licencias: instancias, ediciones y Community Edition.
- Instalación: appliance, puertos y workers de Proxmox.
- Hardened Repository: copias inmutables en discos locales.
- Backup job: métodos, retención GFS y copia fuera de sede (esta guía).
- Instant Recovery: restaurar en minutos.
- SureBackup: verificar las copias e informar.
Qué es un backup job de Veeam
Un trabajo reúne cuatro decisiones. Primero, qué máquinas incluye. Después, en qué repositorio escribe. Luego, cuándo corre. Y por último, cómo copia: el método, la retención y el tratamiento de las aplicaciones. Cada vez que se ejecuta, abre una sesión, y cada sesión deja un punto de restauración por máquina.
Esos puntos forman una cadena. El primero es un full, con la máquina entera; los siguientes son incrementales, con solo los bloques que cambiaron. Por eso, para restaurar un martes hace falta el full y todos los incrementales hasta ese martes, como explicamos en la guía de tipos de backup. Así, la configuración del backup job de Veeam decide lo largas que son esas cadenas y cuántas se conservan.
Los métodos de copia en la versión 13
| Método | Cómo es la cadena | Ventaja | Costo |
|---|---|---|---|
| Forward incremental | Varios fulls, cada uno con sus incrementales | El más fiable y el de menor carga de escritura | Más espacio, salvo con fast clone |
| Forever forward incremental | Un solo full que absorbe el incremental más viejo | Menos espacio | Fragmenta el full y pide compactarlo |
| Reverse incremental | El full siempre es el punto más reciente | Restaurar lo último es lo más rápido | Ya no se puede elegir en trabajos nuevos |
En el caso no hay elección, y es una buena noticia. El repositorio endurecido solo admite el forward incremental con fulls periódicos, porque un archivo inmutable no se puede fusionar. Por lo tanto, los dos trabajos crean un full sintético cada sábado, que con el fast clone de XFS casi no ocupa espacio nuevo.
Full sintético o full activo
El full activo vuelve a leer las máquinas enteras, así que carga la producción. En cambio, el full sintético se arma en el repositorio con lo que ya tiene y no toca los nodos. Por eso se usa el sintético cada semana y, como mucho, un full activo al trimestre para renovar la cadena desde el origen.
Los dos trabajos del caso
Una sola regla para todas las máquinas no sirve, porque no todas valen lo mismo si se pierde un día. Por eso el caso usa dos trabajos:
| Opción | Diario | ERP cada 4 horas |
|---|---|---|
| Máquinas | Las 7 del mapa | erp-app y erp-db |
| Hora | Todos los días, 22:00 | 08:00, 12:00, 16:00 y 20:00 |
| Retención corta | 14 puntos | 28 puntos: una semana |
| Retención GFS | 4 semanales y 12 mensuales | Ninguna |
| Full sintético | Sábados | Sábados |
| Coherencia de aplicaciones | Activada | Activada |
| Pérdida máxima de datos | 24 horas | 4 horas en horario laboral |
Las horas del segundo trabajo no son arbitrarias. El complemento de Proxmox toma la medianoche como referencia para los trabajos periódicos, así que «cada 4 horas» significa 00:00, 04:00, 08:00 y así sucesivamente. Con una ventana permitida de 07:00 a 21:00, quedan cuatro corridas. Además, el complemento no relanza una corrida que cae fuera de la ventana cuando esta se abre, así que conviene que la ventana cubra las horas buscadas.
Retención corta y retención GFS
La retención corta cuenta puntos: en el trabajo diario, los últimos 14. La retención GFS, en cambio, conserva copias durante semanas, meses o años sin crear archivos nuevos: marca algunos fulls con una bandera semanal, mensual o anual. Según la documentación de la retención a largo plazo, estas son sus reglas:
- Solo marca fulls. Si el trabajo no crea un full en el periodo, ese periodo se queda sin punto largo.
- Un full marcado no se toca. No se modifica ni se borra hasta que vence su bandera.
- No aplica al incremental inverso, y al forever forward incremental solo si hay fulls periódicos.
- No es retroactiva. Marca los fulls creados después de guardar la configuración.
- Hace falta al menos un full por periodo. Para una retención mensual, al menos un full al mes.
En el caso, el full sintético de cada sábado cumple esas reglas: cuatro de ellos quedan marcados como semanales y uno por mes, como mensual. Así, la empresa puede volver a cualquier día de las dos últimas semanas, a cualquier sábado del último mes y a un sábado de cada uno de los últimos doce meses.
Application-aware processing en Proxmox
Una copia tomada en caliente puede atrapar una base de datos a mitad de una escritura. Por eso Veeam ofrece el procesamiento con reconocimiento de aplicaciones: antes de la instantánea, pide al sistema invitado que deje las aplicaciones en un estado coherente. En Proxmox, eso exige el agente invitado de QEMU instalado y activo en cada máquina, y credenciales del sistema operativo en el trabajo.
Además, el complemento tiene tres límites que conviene conocer. No admite excluir archivos dentro de la máquina. Tampoco usa Kerberos para conectarse a los sistemas invitados. Y un SQL Server en un clúster de conmutación de Windows solo queda como copia de imagen, sin coherencia de aplicación; para ese caso, la documentación recomienda Veeam Agent administrado por el servidor de copias.
En el caso, la opción va activada para erp-db, erp-app, dc-01 y dc-02, que son las máquinas donde la coherencia importa. Sin ella, además, no funcionaría la restauración de objetos de Active Directory que explica la sexta guía.
Cuánto mueve el backup job de Veeam cada noche
Estas son las cifras del caso. Se supone que la compresión y la deduplicación reducen los datos a la mitad y que la red de copias entrega unos 110 MB/s efectivos en un enlace de 1 Gbps:
| Máquina | Datos (GiB) | Cambio diario | Cambio (GiB) |
|---|---|---|---|
| erp-db | 214 | 8 % | 17,12 |
| file-01 | 540 | 1,5 % | 8,10 |
| erp-app | 62 | 3 % | 1,86 |
| web-01 y web-02 | 42 | 2 % | 0,84 |
| dc-01 y dc-02 | 44 | 1 % | 0,44 |
| Total | 902 | 3,1 % | 28,36 |
De ahí salen tres resultados. Primero, el full inicial lee 902 GiB y tarda unas 2,3 horas, así que conviene lanzarlo un viernes por la noche. Segundo, cada incremental nocturno lee 28,4 GiB en unos 4 minutos y escribe 14,18 GiB en el repositorio. Tercero, cada corrida del ERP escribe unos 2,4 GiB. En otras palabras, el trabajo diario apenas ocupa la red, y la ventana nocturna sobra.
Por otra parte, el complemento limita a cuatro las copias simultáneas por almacenamiento de Proxmox. Con siete máquinas repartidas en tres nodos, ese límite no frena al trabajo diario, pero sí conviene no programar otro trabajo grande a la misma hora.
La copia fuera de sede: backup copy job
El trabajo principal escribe en el repositorio de la sede. Para la tercera copia de la regla 3-2-1, que explicamos en la guía de copias de seguridad ante el ransomware, hace falta otro trabajo: el backup copy job. Toma los puntos ya creados y los copia a otro repositorio con su propia retención, sin volver a leer las máquinas.
Tiene dos modos, y los dos admiten las copias del complemento de Proxmox. Por un lado, el inmediato copia cada punto en cuanto aparece; según las notas de la versión 13.1, solo procesa la cadena más reciente. Por otro, el periódico copia el último punto según un horario propio. En el caso se elige el inmediato, detrás del trabajo diario, hacia almacenamiento de objetos en la nube con inmutabilidad.
| Cifra de la copia fuera de sede | Valor |
|---|---|
| Siembra inicial | 451 GiB comprimidos |
| Subida a 100 Mbit/s, al 100 % | 10,8 horas |
| Subida a 100 Mbit/s, al 80 % | 13,5 horas |
| Incremental diario al 80 % | 25 minutos |
| Retención: 7 diarios, 4 semanales y 12 mensuales | 1,25 TiB en la nube |
La siembra es la parte delicada: más de medio día de subida. Por eso conviene lanzarla un sábado y limitar el ancho de banda en horario laboral. Después, cada noche sube en 25 minutos. Si prefiere comparar esta vía con una copia nativa de la nube, la guía de Azure Backup calcula esa factura para otro caso.
Revisar el backup job de Veeam con PowerShell
La consola muestra el estado, pero PowerShell permite revisarlo sin abrirla y guardar el resultado. El módulo viene con la consola remota; en el appliance de Linux, además, hay que importarlo a mano, como indican las notas de la versión 13. Este ejemplo conecta con el servidor y lista las sesiones de los últimos siete días que terminaron con aviso o con error:
Connect-VBRServer -Server vbr-01.empresa.local -Credential (Get-Credential)
$desde = (Get-Date).AddDays(-7)
Get-VBRBackupSession |
Where-Object { $_.CreationTime -ge $desde -and $_.Result -ne "Success" } |
Sort-Object CreationTime -Descending |
Select-Object CreationTime, EndTime, Result, StateLuego, para ver el último punto de cada máquina, se encadenan dos comandos. Si una máquina lleva más de 24 horas sin punto nuevo, algo falló aunque nadie lo haya notado:
Get-VBRBackup | Get-VBRRestorePoint |
Group-Object Name |
ForEach-Object { $_.Group | Sort-Object CreationTime -Descending | Select-Object -First 1 } |
Select-Object Name, CreationTimeAmbos comandos están en la referencia de PowerShell del fabricante. La última guía los convierte en el informe mensual para la dirección.
Errores frecuentes al configurar el trabajo
| Error | Qué provoca | Qué hacer |
|---|---|---|
| Una sola regla para todas las máquinas | El ERP pierde un día entero | Un trabajo más frecuente para lo crítico |
| GFS sin fulls en el periodo | Meses sin punto largo | Full sintético semanal |
| Sin el agente de QEMU | Copias sin coherencia de aplicación | Instalarlo antes de la primera copia |
| Full activo cada semana | Carga innecesaria sobre la producción | Sintético semanal, activo trimestral |
| Siembra en horario laboral | Internet saturado durante horas | Fin de semana y límite de ancho de banda |
| Nadie lee las notificaciones | Fallos que se descubren al restaurar | Revisión diaria y alerta como caso |
Preguntas frecuentes sobre el backup job de Veeam
¿Una máquina puede estar en dos trabajos?
Sí, como erp-db en el caso. Cada trabajo mantiene su propia cadena, así que ocupa su propio espacio y hay que contarlo al dimensionar el repositorio.
¿Cada cuánto conviene un full activo?
Con fulls sintéticos semanales, uno al trimestre basta para renovar la cadena desde el origen. Además, conviene programarlo en fin de semana.
¿El backup copy job vuelve a leer las máquinas?
No. Copia los puntos que ya existen en el repositorio de origen, así que no añade carga a la producción.
¿Qué pasa si un trabajo falla de noche?
Veeam reintenta según la configuración y envía la notificación. Por eso lo importante es que alguien la reciba y la atienda al empezar el día.
En resumen: el backup job de Veeam en cuatro ideas
En resumen, un backup job de Veeam decide qué, dónde, cuándo y cuánto se conserva. Con un repositorio endurecido, el método es el incremental con full sintético semanal. La retención GFS solo marca fulls, así que hace falta uno por periodo. Y la copia fuera de sede es otro trabajo: en el caso, 13,5 horas de siembra y 25 minutos cada noche.
Con las copias en marcha, la pregunta cambia: cuánto se tarda en volver cuando algo falla. Ese es el tema de la sexta guía.
Cómo lo aborda KHARONTE
Configurar un trabajo es una tarde; administrarlo es cada día. Dentro de nuestra línea de continuidad y respaldo diseñamos, implementamos y administramos Veeam Backup: los trabajos programados, los cambios que pida su operación y la corrección cuando alguno no termina bien, con un plan que fija por escrito cuánta información puede perder cada sistema.
Cada trabajo que termina con aviso o con error entra como caso en nuestra mesa de ayuda TI y se atiende según su criticidad. Y si prefiere que un técnico dedicado se ocupe de esta rutina dentro de su equipo, lo ofrecemos como outsourcing de TI.
Hablemos de la TI de su empresa
Cuéntenos qué necesita su operación y le enviamos una propuesta por escrito. Cada línea del portafolio se contrata por separado.
