Saltar a contenido

Automatización del gestor de almacenamiento

Actualizado el 10 de agosto de 2026.

storage-mgr es un contenedor LXC sin privilegios de Proxmox 109. Coordina varios flujos independientes de grabación, multitrack y copias de seguridad de VM. Esta página es el inventario del plano de control: identifica el planificador activo para cada flujo, la fuente de verdad de Git donde exista, las comprobaciones de estado seguras y los scripts heredados que no deben reactivarse junto con sus reemplazos.

Horarios activos

Flujo Planificador activo Punto de entrada de ejecución Propósito Manual detallado
Ingesta multitrack crontab de root, diario a las 22:00 /root/audio-backup.sh Copia las multitracks completadas del servicio al almacenamiento masivo Esta página
Copia de seguridad externa de Proxmox crontab de root, diario a las 00:00 /root/proxmox-backup-sync.sh Reanuda la instantánea de la semana ISO actual en Google Shared Drive y retiene 13 semanas Copias de seguridad de Proxmox
Archivo de HyperDeck crontab de root, diario a las 01:00 /root/hypedeck-backup.sh Descarga los clips completados de HyperDeck, verifica los recuentos de bytes antes de eliminar el dispositivo, luego sincroniza el archivo con fecha riveroaks/infra/apps/hyperdeck/README.md
Copia en la nube de multitrack rclone-multitracks.service /usr/local/bin/rclone-multitracks-loop.sh Copia el archivo multitrack del almacenamiento masivo a su destino en la nube aprobado con CPU y E/S limitadas Fiabilidad del almacenamiento de archivos
Archivo de grabación de OBS ro-obs-archive.timer, cada 10 minutos /usr/local/sbin/ro-obs-archive Descarga grabaciones estables de OBS, verifica SHA-256, publica atómicamente y solo entonces elimina la fuente de Mac Archivo de grabación de OBS

La crontab de root es la autoridad para las tres filas de cron. rclone-multitracks.service es el único planificador activo para la copia multitrack en la nube; sus entradas de cron anteriores están intencionalmente comentadas. ro-obs-archive.timer reemplazó a /root/obs-backup.sh; todas las variantes de cron de OBS están intencionalmente deshabilitadas.

Fuente de verdad y secretos

  • La sincronización externa de Proxmox es administrada por Git en riveroaks/infra/storage/hosts/storage-mgr/files/usr/local/sbin/riveroaks-proxmox-backup-sync y se implementa en /root/proxmox-backup-sync.sh.
  • La automatización de HyperDeck es administrada por Git bajo riveroaks/infra/apps/hyperdeck. Su token de Influx pertenece a /etc/hyperdeck/influx.env, solo para root, nunca al script o a la documentación.
  • El código de archivo de OBS, el instalador, el rollback y el modelo de amenazas son administrados por Git bajo riveroaks/infra/apps/obs-archive.
  • El servicio multitrack en la nube y sus límites de recursos se documentan en el manual de almacenamiento de archivos. No restaure el cron de root deshabilitado mientras el servicio esté activo.
  • /root/audio-backup.sh sigue siendo un script heredado administrado por el host. Trátelo como deuda técnica solo de producción: consérvelo durante el trabajo de rutina, no copie su contenido en tickets y migre a código de infraestructura revisado antes de realizar cambios de comportamiento.
  • La configuración remota de rclone y cualquier credencial de servicio siguen siendo configuración de tiempo de ejecución local propiedad de root. La documentación solo nombra los límites y los nombres de las variables.

Comprobaciones de estado seguras

Ejecute estas desde el host de Proxmox. Inspeccionan el estado y la sintaxis sin leer credenciales ni contenido de copia de seguridad.

pct status 109
pct exec 109 -- crontab -l
pct exec 109 -- systemctl is-active rclone-multitracks.service ro-obs-archive.timer
pct exec 109 -- systemctl list-timers ro-obs-archive.timer --no-pager
pct exec 109 -- bash -n /root/audio-backup.sh
pct exec 109 -- bash -n /root/hypedeck-backup.sh
pct exec 109 -- bash -n /root/proxmox-backup-sync.sh
pct exec 109 -- /root/proxmox-backup-sync.sh --dry-run
pct exec 109 -- df -h /mnt/bulk-storage /mnt/proxmox-backups

Los tiempos esperados del cron de root activos son las 22:00 para la ingesta multitrack, las 00:00 para la sincronización externa de Proxmox y la 01:00 para HyperDeck. Un cron de rclone u OBS activo duplicado es un fallo, no redundancia.

Utilice consultas de registro limitadas al solucionar problemas:

pct exec 109 -- journalctl -u rclone-multitracks.service --since "2 hours ago" --no-pager
pct exec 109 -- journalctl -u ro-obs-archive.service --since "2 hours ago" --no-pager
pct exec 109 -- tail -n 200 /var/log/proxmox-backup-sync.log

Los registros y tickets no deben incluir nombres de grabación, texto de transcripción, configuración de rclone, tokens, credenciales o contenido de copia de seguridad. Prefiera recuentos, totales de bytes, duración, códigos de error limitados y hashes de objetos.

Reglas de cambio y recuperación

  1. Actualice el repositorio de infraestructura primero siempre que cambie un flujo administrado por Git.
  2. Ejecute pruebas de regresión de sintaxis y sin red, luego requiera un pipeline de solicitud de extracción que sea exitoso.
  3. Conserve el artefacto instalado con una copia de recuperación fechada antes de la implementación.
  4. Compare SHA-256 entre el artefacto revisado y la copia instalada.
  5. Utilice un modo de simulación (dry-run) o sin eliminación antes de una copia en vivo siempre que el flujo lo admita.
  6. Nunca ejecute un segundo planificador en paralelo para "probar" un archivo. Respete el bloqueo existente del flujo.
  7. Nunca elimine una grabación o copia de seguridad de origen para reparar un fallo de cuota en la nube. Reanude desde la copia local verificada después de que se restablezca el límite del proveedor.

La auditoría del 10 de agosto verificó los cuatro scripts de root anteriores con bash -n, confirmó la propiedad esperada del cron y verificó los dos flujos de systemd de reemplazo. La sincronización de Proxmox es ahora idempotente y reanudable; un objeto histórico de la semana 32 permanece rastreado por separado hasta que se restablezca la cuota de carga de Google Drive.