La programación necesaria para mantener un estado persistente de Docker
El autor quería copias semanales de AppData en un conjunto RAID 1 y una segunda copia de ese conjunto en un disco USB conectado continuamente. El crontab del sistema y una aplicación de programación de la comunidad no conservaban las tareas de forma fiable después de reiniciar, así que trasladó la programación a una pila de Ofelia administrada por Portainer y almacenada en los datos persistentes de ZimaOS.
El diseño resultante separaba tres capas: scripts de shell en el almacenamiento RAID, un contenedor de Ofelia que proporcionaba la programación y contenedores de rsync de corta duración que realizaban cada copia.
Almacenar scripts y registros en almacenamiento persistente
El ejemplo colocaba los scripts en una ruta como /media/RAID1/scripts. Ese directorio se montaba con permisos de lectura y escritura en el programador como /scripts. Los registros se escribían junto a los scripts para poder inspeccionarlos mediante Files o un recurso compartido de red una vez finalizado el trabajo.
Todas las rutas del ejemplo dependen de la instalación. Copiar el nombre del RAID del autor sin comprobar la ruta de montaje real puede enviar la copia de seguridad al lugar equivocado o hacer que el trabajo falle silenciosamente.
Ofelia proporcionó una programación persistente tras los reinicios
La pila de Portainer utilizaba la imagen de Ofelia, establecía restart: always, montaba el directorio de scripts y almacenaba las etiquetas de programación con el contenedor. El ejemplo programaba AppData a las 23:30 de cada domingo y los datos generales del NAS a las 23:45.
ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"El autor informó que el programador y sus trabajos volvían a estar disponibles aproximadamente un minuto después de reiniciar, sin requerir otra sesión SSH.
El script de AppData detenía Plex antes de copiar
Para reducir la posibilidad de copiar una base de datos de Plex que estuviera cambiando activamente, el script detenía Plex, ejecutaba rsync desde un montaje de origen de AppData de solo lectura y después reiniciaba Plex. Cuando era necesario, el contenedor del programador instalaba una CLI de Docker y controlaba los contenedores hermanos mediante el socket de Docker.
Montar /var/run/docker.sock proporciona al programador un amplio control sobre el host de Docker. Ejecutarlo como root y con privilegios aumenta aún más esa autoridad. El hilo presenta esto como el diseño funcional del autor, no como un modelo de seguridad basado en el principio de mínimo privilegio.
rsync --delete crea un espejo exacto, no un historial versionado
El ejemplo utilizaba rsync -avH --delete. La opción --delete elimina los archivos del destino que ya no existen en el origen. Esto produce un espejo exacto, pero también puede replicar eliminaciones accidentales o daños.
Prueba primero sin eliminar archivos, confirma los montajes de origen y destino e inspecciona el registro antes de activar una programación desatendida. Un espejo en un disco USB siempre conectado tampoco equivale a una copia de seguridad sin conexión o inmutable.
La persistencia tras reinicios no resolvió la reconexión del USB
El autor solicitó por separado que un disco USB conectado dejara de aparecer como un disco nuevo después de reiniciar. Ofelia conserva la configuración del trabajo, pero una ruta de montaje modificada o no disponible aún puede romper el destino de la copia de seguridad. La identificación estable del almacenamiento y la verificación de los montajes antes de ejecutar rsync siguen siendo requisitos independientes.
Preguntas frecuentes
¿Por qué esta programación sobrevivió al reinicio?
Las definiciones de los trabajos estaban en una pila de Portainer configurada para reiniciarse y los scripts se encontraban en almacenamiento persistente, en lugar de estar en un crontab del sistema efímero.
¿Esto crea versiones históricas de las copias de seguridad?
No. El comando de rsync documentado crea un espejo y utiliza --delete. La conservación de versiones requiere un diseño diferente.
¿Por qué detener Plex antes de copiar AppData?
El autor lo hizo para reducir el riesgo de copiar su base de datos mientras se estaba modificando.
