La pianificazione necessaria per vivere con uno stato Docker persistente
L’autore voleva copie settimanali di AppData su un pool RAID 1 e una seconda copia da quel pool a un disco USB collegato continuamente. Il crontab di sistema e un’app di pianificazione della community non conservavano i task in modo affidabile dopo il riavvio, quindi ha spostato la pianificazione in uno stack Ofelia gestito da Portainer e archiviato nei dati persistenti di ZimaOS.
Il design risultante separava tre livelli: script shell sullo storage RAID, un container Ofelia che forniva la pianificazione e container rsync di breve durata che eseguivano ciascuna copia.
Archiviare script e log nello storage persistente
L’esempio collocava gli script in un percorso come /media/RAID1/scripts. La directory veniva montata in lettura-scrittura nel pianificatore come /scripts. I log venivano scritti accanto agli script, così potevano essere consultati tramite Files o una condivisione di rete dopo il completamento del job.
Ogni percorso dell’esempio dipende dalla specifica installazione. Copiare il nome del RAID dell’autore senza verificare il percorso di mount effettivo può inviare un backup nella posizione sbagliata o causare il fallimento silenzioso del job.
Ofelia forniva una pianificazione persistente dopo il riavvio
Lo stack Portainer utilizzava l’immagine Ofelia, impostava restart: always, montava la directory degli script e memorizzava le etichette della pianificazione insieme al container. L’esempio pianificava AppData alle 23:30 di ogni domenica e i dati NAS generali alle 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"L’autore ha riferito che il pianificatore e i relativi job tornavano operativi entro circa un minuto dal riavvio, senza richiedere un’altra sessione SSH.
Lo script AppData arrestava Plex prima della copia
Per ridurre la possibilità di copiare un database Plex che stava cambiando, lo script arrestava Plex, eseguiva rsync da un mount di origine AppData in sola lettura e poi riavviava Plex. Quando necessario, il container del pianificatore installava una CLI Docker e controllava i container adiacenti tramite il socket Docker.
Montare /var/run/docker.sock conferisce al pianificatore un ampio controllo sull’host Docker. Eseguirlo come root e in modalità privilegiata aumenta ulteriormente tale autorità. La discussione presenta questa configurazione come il design funzionante dell’autore, non come un modello di sicurezza basato sul principio del privilegio minimo.
rsync --delete crea un mirror esatto, non una cronologia con versioni
L’esempio utilizzava rsync -avH --delete. L’opzione --delete rimuove i file dalla destinazione che non esistono più nell’origine. Questo produce un mirror esatto, ma può anche replicare eliminazioni accidentali o dati danneggiati.
Esegui prima i test senza l’eliminazione, conferma i mount di origine e destinazione e controlla il log prima di abilitare una pianificazione automatica. Un mirror su un disco USB sempre collegato non equivale inoltre a un backup offline o immutabile.
La persistenza dopo il riavvio non ha risolto la riconnessione USB
L’autore ha inoltre richiesto che un disco USB collegato non comparisse come nuovo disco dopo il riavvio. Ofelia conserva la configurazione del job, ma un percorso di mount cambiato o non disponibile può comunque interrompere il backup sulla destinazione. L’identificazione stabile dello storage e la verifica dei mount prima di rsync restano requisiti separati.
Domande frequenti
Perché questa pianificazione è sopravvissuta al riavvio?
Le definizioni dei job risiedevano in uno stack Portainer configurato per il riavvio automatico e gli script erano archiviati nello storage persistente, anziché in un crontab di sistema effimero.
Vengono create versioni storiche dei backup?
No. Il comando rsync documentato crea un mirror e utilizza --delete. La conservazione delle versioni richiede un design diverso.
Perché arrestare Plex prima di copiare AppData?
L’autore lo faceva per ridurre il rischio di copiare il database mentre veniva modificato.
