Questa discussione dell’aprile 2026 iniziò come un ampio post di un “nuovo utente sopraffatto da ZimaOS”, che riguardava il backup e la posta elettronica self-hosted. Il problema della posta divenne infine secondario: l’utente riuscì a far funzionare Mailcow abbastanza bene per le proprie esigenze. La questione tecnica irrisolta riguardava ZimaOS Backup, con dimensioni visualizzate incoerenti, una prima esecuzione che di solito si completava e quelle successive che potevano bloccarsi senza ulteriore attività sul disco.
La fonte è particolarmente utile perché l’utente testò più di uno ZimaBoard 2, diverse unità interne ed esterne, una destinazione di rete Synology e, in seguito, ZimaOS 1.6.1. Il problema non dovrebbe quindi essere riassunto come un semplice guasto di un disco USB o come un unico percorso di rete errato.
L’utente voleva un semplice backup per il ripristino d’emergenza, non un formato d’archivio
Il flusso di lavoro desiderato era semplice: avviare manualmente un backup in stile 1:1, preservare una struttura delle cartelle riconoscibile, evitare la crittografia o pacchetti opachi e poter ripristinare rapidamente i dati se un intero ZimaBoard 2 fosse guasto.
Questa aspettativa è diversa da quella del software di backup con versioning, che conserva intenzionalmente copie storiche. Quando la conservazione delle versioni è abilitata, l’utilizzo della destinazione può legittimamente superare le dimensioni del dataset sorgente corrente.
Il problema relativo al server di posta venne infine separato
Il post originale descriveva anche la difficoltà nel sostituire Synology Mail Plus. Zima-Jerry suggerì Stalwart, ma l’utente aveva specificamente bisogno del recupero tramite POP3. Il 16 aprile, l’utente riferì che Mailcow funzionava e che le altre applicazioni erano soddisfacenti.
Vale la pena preservare questo esito, perché impedisce di interpretare erroneamente la successiva discussione sul Backup come prova che fosse Mailcow ad aver causato il problema di archiviazione.
Le dimensioni della destinazione del backup non corrispondevano alla realtà
Su una scheda, circa 800 GB alla sorgente corrispondevano a circa 2,7 TB nella directory di destinazione. Su un’altra, circa 105 GB alla sorgente sembravano risultare inferiori di circa 2 GB nella destinazione.
La conservazione delle versioni può spiegare una parte dell’aumento, ma non una seconda esecuzione bloccata
Zima-Jerry ha chiesto se la funzione “versione riservata” fosse abilitata. Conservare le versioni precedenti può effettivamente rendere la destinazione del backup più grande della sorgente attiva corrente.
Tuttavia, in seguito l’utente della fonte ha ripetuto il test con un disco USB esterno appena formattato e ha documentato un problema diverso: il primo backup è stato completato, mentre il secondo ha copiato alcuni dati e poi ha smesso di avanzare.
Il test USB pulito ha riprodotto il problema della seconda esecuzione
L’utente ha eliminato i vecchi processi, riavviato ZimaBoard 2, formattato un’unità esterna e creato un nuovo backup manuale con le versioni abilitate. La prima esecuzione è durata quasi due giorni e ha copiato correttamente circa 1,25 TB.
Dopo aver scollegato e ricollegato l’unità tramite File, la seconda esecuzione ha copiato alcune modifiche, poi la barra di avanzamento si è bloccata e il LED di attività USB si è spento. Lo stesso comportamento si era verificato con la destinazione Synology.
IceWhale ha intensificato la gestione del comportamento del backup
Zima-Jerry ha ringraziato l’utente per i test controllati e ha detto che il problema sarebbe stato inoltrato al team di sviluppo per le verifiche.
Una risposta successiva relativa a IceWhale ha distinto due aree problematiche note: il backup di tutto /media/ZimaOS-HD in precedenza includeva contenuti di pipe/socket Docker e la precisione della visualizzazione dell’avanzamento del backup doveva ancora essere migliorata.
Eseguire il backup dell’intero disco di sistema non equivale a creare un’immagine di sistema ripristinabile
La discussione si è poi spostata sul ripristino di emergenza. Una risposta del team ha spiegato che eseguire ciecamente il backup dell’intero disco di sistema include file Docker/runtime usa e getta e non offre automaticamente una procedura supportata per “ripristinare questa cartella e riportare l’intero sistema ZimaOS esattamente allo stato precedente”.
Per la pianificazione in caso di emergenza, distinguere i dati utente, i dati delle applicazioni, i database, la configurazione e le immagini dei container sostituibili.
ZimaOS 1.6.0 ha modificato i metadati per il ripristino dello spazio di archiviazione
Una risposta ufficiale successiva ha affermato che, a partire da ZimaOS 1.6.0, anche le informazioni che descrivono come montare un dispositivo di archiviazione venivano scritte sul dispositivo stesso. L'obiettivo era facilitare il riconoscimento dello storage RAID o a disco singolo dopo un problema al disco di sistema.
Questo migliora il ripristino dell'array, ma non trasforma il RAID in un backup e non risolve di per sé il blocco del backup alla seconda esecuzione segnalato dall'utente.
L'utente ha riprodotto nuovamente il problema in ZimaOS 1.6.1
Il 27 aprile, l'autore del post originale ha riferito che il primo backup funzionava ancora, ma la seconda esecuzione e quelle successive si bloccavano per più di sei ore senza ulteriori attività di scrittura. Chiudendo e riaprendo Backup, la destinazione poteva essere visualizzata come 0 B.
Hanno detto che il comportamento era stato testato con quattro unità interne, due unità USB esterne e tre sistemi ZimaBoard 2.
Il flusso di lavoro attuale del backup si è evoluto
La documentazione attuale di ZimaOS descrive ora le attività di backup pianificate verso destinazioni locali, USB, NAS e cloud come parte di una strategia 3-2-1.
Usa il flusso di lavoro attuale del backup di ZimaOS e le opzioni di destinazione invece di presumere che oggi l'interfaccia delle versioni 1.5.x/1.6.1 si comporti allo stesso modo.
La guida attuale non dimostra di per sé che ogni bug storico della seconda esecuzione menzionato in questa discussione sia stato risolto, quindi verifica il comportamento effettivo del ripristino nella versione in uso.
Verificare il backup al di fuori della barra di avanzamento
- confrontare, quando possibile, il numero di file nella sorgente e nella destinazione;
- controllare la capacità effettiva della destinazione anziché affidarsi solo all'interfaccia Backup;
- testare una seconda e una terza esecuzione incrementale/con versione;
- ripristinare file rappresentativi in un'altra posizione;
- documentare quali database delle applicazioni e impostazioni devono essere sottoposti a backup separatamente.
FAQ sul backup di ZimaOS
Il problema della sorgente si verificava solo con un NAS Synology?
No. L'utente ha riprodotto blocchi simili con un'unità USB esterna.
Il primo backup non è riuscito?
La prima esecuzione controllata è stata completata; il problema ricorrente è comparso nelle esecuzioni successive.
Il problema era scomparso in ZimaOS 1.6.1?
No. L'autore del post originale ha detto esplicitamente che il problema si ripresentava anche lì.
Una destinazione di backup può essere legittimamente più grande della sorgente attuale?
Sì, quando la conservazione delle versioni è abilitata, ma questo non spiega ogni sintomo di visualizzazione o di blocco dei processi nella discussione.
