{ "meta": { "title": "Trabajos programados — timers, modo adjunto, retención | ProxMenux", "description": "Trabajos de copia de host programados en ProxMenux. Dos modos de creación (timer systemd propio o adjuntarse a un trabajo vzdump de PVE existente), valores de retención aplicados por trabajo vía proxmox-backup-client/borg/local prune, layout de almacenamiento bajo /var/lib/proxmenux/backup-jobs, y el script runner que produce archivos idénticos al flujo interactivo.", "ogTitle": "ProxMenux Backup — trabajos programados", "ogDescription": "Copias de host desatendidas programadas con modo adjunto, retención, y los mismos tres destinos que el flujo interactivo.", "twitterTitle": "Trabajos programados | ProxMenux", "twitterDescription": "Trabajos de copia de host desatendidos con modo adjunto y retención." }, "header": { "title": "Trabajos programados", "description": "Trabajos de copia de host desatendidos. Dos modelos de creación: un trabajo nuevo e independiente con su propio horario, o un trabajo adjuntado a una tarea vzdump de PVE existente que hereda el horario y la retención de esa tarea. Ambos producen archivos idénticos al flujo interactivo.", "section": "Backup & Restore" }, "intro": { "title": "Los dos modelos de trabajo programado", "body": "Un trabajo programado puede crearse siguiendo uno de dos modelos:", "modelsList": [ "Trabajo nuevo e independiente — el propio ProxMenux define el horario del trabajo con un timer systemd propio, independiente de cualquier otra tarea del host. Compatible con los tres destinos: Local, PBS y Borg.", "Adjuntarse a una tarea vzdump de PVE existente — el trabajo no lleva horario propio; se ejecuta automáticamente cada vez que se dispara la tarea vzdump padre que ya copia las VMs y los LXCs del host. Hereda el horario y la retención de la tarea padre. Compatible con Local y PBS (Borg no está soportado porque no existe scheduler nativo de PVE para Borg)." ] }, "attachBadge": { "title": "Modo adjunto — recomendado cuando ya existe una tarea vzdump de PVE", "body": "Cuando ya hay una tarea de copia vzdump de PVE configurada para las VMs y los LXCs de este nodo, adjuntar la copia de host a esa tarea garantiza que la configuración del host se captura en la misma ventana que los invitados. En la restauración, las configuraciones de los invitados vienen de la copia de host (viven bajo /etc/pve), y los discos de los invitados vienen de la copia vzdump tomada al mismo tiempo — ambos conjuntos son consistentes entre sí, por lo que una recuperación completa del nodo puede reproducir el host y re-adjuntar cada invitado sin drift de versiones." }, "modes": { "heading": "Los dos modos", "rows": [ { "mode": "Nuevo trabajo programado", "backends": "Local, PBS, Borg", "schedule": "Expresión OnCalendar propia (sintaxis de calendario systemd — por ejemplo daily, Mon..Fri 03:00).", "retention": "Se pregunta por separado: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. La aplica el runner tras cada copia exitosa." }, { "mode": "Adjuntar a un trabajo vzdump de PVE", "backends": "Local, PBS (Borg no tiene scheduler del lado PVE)", "schedule": "Heredado del trabajo PVE padre. No se instala timer systemd del lado de ProxMenux.", "retention": "Heredada de la configuración prune-backups del padre (mapeada uno-a-uno a las variables KEEP_* del runner vía hb_pve_prune_to_keep_env)." } ] }, "attachDetail": { "heading": "Cómo funciona el modo adjunto", "intro": "PVE escribe las tareas vzdump en /etc/pve/jobs.cfg — una entrada por tarea, cada una apuntando a un storage donde caen los dumps de VMs y LXCs. El modo adjunto requiere que ese storage sea un backend que ProxMenux entienda (Local o PBS); cuando la tarea dispara, ProxMenux se ejecuta al mismo tiempo.", "steps": [ { "step": "1", "detail": "Durante la creación del trabajo, ProxMenux lista las tareas PVE padre compatibles vía hb_pve_list_vzdump_jobs_for_backend. El usuario elige una." }, { "step": "2", "detail": "El .env del trabajo se escribe con PVE_PARENT_JOB, PVE_STORAGE y los valores heredados de KEEP_*; no se crea timer systemd." }, { "step": "3", "detail": "hb_install_vzdump_hook registra un script-hook en /etc/vzdump.conf. Cuando PVE ejecuta cualquier tarea vzdump, el script-hook dispara; si el $STOREID que se le pasa coincide con el PVE_STORAGE de un trabajo adjuntado, el runner se invoca para ese trabajo." }, { "step": "4", "detail": "El archivo aterriza en el mismo storage donde los dumps de vzdump acaban de escribirse: path/dump/ para Local, o el repositorio PBS configurado en la entrada de storage de PVE." } ], "outroBody": "El modo adjunto tiene una implicación operativa: desactivar o eliminar la tarea padre de PVE también desactiva la copia de host — no hay timer propio al que recurrir. La entrada del trabajo permanece en disco para poder re-adjuntarla más tarde." }, "storageLayout": { "heading": "Ficheros que componen un trabajo", "intro": "Cada trabajo programado queda completamente descrito por tres o cuatro ficheros en disco. Consultarlos permite ver toda la configuración del trabajo sin depender de la interfaz.", "rows": [ { "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env", "content": "Backend, backup ID o destino, horario (modo Nuevo) o padre PVE (modo adjunto), flag enabled, valores KEEP_* de retención, punteros a credenciales." }, { "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths", "content": "Una ruta absoluta por línea — la selección congelada resuelta desde el perfil en el momento de creación del trabajo. Editar el fichero re-ejecuta el trabajo con la nueva selección en el siguiente disparo del timer." }, { "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service", "content": "Sólo modo Nuevo. El service invoca run_scheduled_backup.sh JOB_ID. El timer lo programa con Persistent=true (los disparos perdidos se ejecutan al siguiente arranque) y un pequeño RandomizedDelaySec=120 para repartir carga cuando varios trabajos comparten la misma expresión OnCalendar." }, { "path": "script-hook de /etc/vzdump.conf", "content": "Sólo modo adjunto. Lo instala una vez hb_install_vzdump_hook; casa el PVE_STORAGE de cada trabajo adjuntado contra el $STOREID que PVE pasa al script-hook." } ] }, "runner": { "heading": "Qué hace un trabajo cuando se dispara", "intro": "Cada trabajo — sea del modelo nuevo o adjunto — ejecuta la misma secuencia de tres pasos:", "steps": [ "Preparar la copia. Lee la configuración del trabajo (destino, perfil, rutas) y ensambla el árbol de la copia siguiendo exactamente el mismo procedimiento que el flujo interactivo. El resultado es el mismo archivo que produciría una copia manual con esos ajustes.", "Escribir en el destino. Sube o escribe la copia al destino configurado — un archivo local .tar.zst, un backup PBS o un archivo Borg — usando exactamente las mismas herramientas y credenciales que utilizaría una copia manual al mismo destino.", "Aplicar retención. Elimina las copias antiguas del destino conservando los valores keep-last / keep-daily / keep-weekly configurados en el trabajo. La poda la realiza el propio destino: PBS mantiene la cuenta en su lado, Borg ejecuta borg prune, y en Local ProxMenux borra los archivos que quedan fuera del keep-last." ] }, "management": { "heading": "Gestión de trabajos", "intro": "El menú del scheduler (TUI de Scripts) y la pestaña Backups del Monitor exponen las mismas acciones sobre cualquier trabajo.", "rows": [ { "action": "Run now", "detail": "Invoca el runner de inmediato, saltándose el timer / hook de vzdump. Útil para verificar una configuración de trabajo sin esperar al siguiente disparo programado." }, { "action": "Enable / Disable", "detail": "Modo Nuevo: systemctl enable/disable --now sobre el timer. Modo adjunto: cambia el flag ENABLED en el env del trabajo — el script-hook lo respeta en el siguiente disparo de PVE." }, { "action": "Edit", "detail": "Reabre los prompts de destino, horario, perfil y retención y reescribe los ficheros del trabajo. Preserva el ID del trabajo." }, { "action": "Delete", "detail": "Elimina el env del trabajo, el fichero de rutas, el timer + service systemd (modo Nuevo) y desactiva el binding del hook (modo adjunto). No toca los archivos ya presentes en el destino." }, { "action": "View log", "detail": "Muestra en streaming /var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log — un fichero de log por ejecución. El runner también emite una línea de estado compacta a journald bajo el service systemd." } ] }, "notifications": { "heading": "Notificaciones", "body": "Cada ejecución programada dispara los mismos eventos hb_notify_lifecycle que el flujo interactivo (start, complete, fail). Si hay canales de notificación configurados en el Monitor, los trabajos desatendidos exponen sus resultados igual que las copias manuales — un usuario no necesita revisar el log para saber si un trabajo tuvo éxito." }, "whereNext": { "heading": "A dónde seguir", "items": [ { "label": "Crear copias", "href": "/docs/backup-restore/creating-backups", "tail": " — el flujo interactivo que comparte backend con el scheduler." }, { "label": "Destinos", "href": "/docs/backup-restore/destinations", "tail": " — configuración por backend usada tanto por el flujo interactivo como por el scheduler." }, { "label": "Restauración", "href": "/docs/backup-restore/restoring", "tail": " — el flujo que consume lo que producen los trabajos." } ] } }