Gli strumenti per l’analisi dell’utilizzo del disco possono essere fuorvianti su un NAS, perché una directory può essere una normale area di archiviazione locale oppure il punto in cui è montato un altro filesystem. Questa discussione del gennaio 2026 è iniziata con un’unità ZimaOS da 1 TB che mostrava circa 915 GB utilizzati, anche se l’utente riteneva di avere solo circa 450 GB di contenuti multimediali. La prima ipotesi era la cache di Docker. L’output del comando indicava invece che /DATA/.media, dove erano coinvolti punti di mount per backup e archiviazione remota.
Misurare prima di ridurre Docker
La prima risposta della community suggeriva di esaminare le cartelle più grandi sotto /DATA e controllando la contabilità interna di Docker. Era ragionevole, ma il risultato dell’utente mostrava solo circa 2,1 GB nell’albero di Docker e circa 2 GB di AppData.
Docker, quindi, non poteva spiegare centinaia di gigabyte mancanti.
/DATA la partizione era quasi piena.Il primo utente ha trovato 424 GB sotto /DATA/.media/UNTITLED 2
La scansione delle dimensioni mostrava circa 419 GB di contenuti multimediali normali più altri 424 GB sotto /DATA/.media/UNTITLED 2. L’utente ha riconosciuto quel nome come l’SSD usato in precedenza come destinazione di Backup di ZimaOS.
La parte confusa era che l’unità fisica di backup non era più collegata.
Un punto di mount può diventare una normale cartella locale
I punti di mount di Linux sono directory. Quando viene montata un’unità USB o una condivisione SMB, gli accessi alla directory raggiungono il filesystem esterno. Se il filesystem esterno scompare e un’applicazione continua a scrivere nella stessa directory, tali scritture possono finire nel filesystem locale sottostante.
Questo crea il classico problema: «la mia destinazione di backup è esterna, quindi perché il disco di sistema si è riempito?».
Non eliminare una directory .media prima di sapere se è montata
La procedura di risoluzione dei problemi proposta dalla fonte prevedeva comandi di rimozione distruttivi dopo aver verificato lo stato dei mount. L’ordine è importante. Eliminare file da una destinazione di backup montata e attiva può cancellare il backup esterno effettivo invece di recuperare dati locali nascosti.
Poiché il comando di eliminazione era un suggerimento della community e non un’istruzione del supporto IceWhale, questa pagina non lo presenta come procedura di pulizia generica.
Un secondo utente ha riprodotto lo stesso schema dopo un’interruzione di corrente
Più avanti nella discussione, un altro utente con una piccola partizione di sistema/dati ZimaOS-HD ha perso tutto lo spazio libero rimanente dopo che un’interruzione di corrente ha interrotto un’attività di backup. I suoi dati grezzi du l’output sembrava enorme perché conteggiava anche i dati RAID e SMB montati sottostanti /DATA/.media.
Usa un'analisi sullo stesso filesystem per separare i dati locali dai mount
La community ha consigliato una du un'analisi che rimanga nello stesso filesystem, così da escludere le condivisioni di rete montate. Nel secondo caso, questo ha fatto emergere circa 30 GB di dati realmente locali sotto una directory denominata con un IP all'interno di /DATA/.media.
Il secondo utente ha recuperato 30 GB
Dopo aver confermato che la directory denominata con l'IP non era un mount SMB attivo e aver identificato i dati locali rimasti sotto il punto di mount, l'utente ha rimosso i contenuti indesiderati e ha riferito di aver recuperato 30 GB.
Questo è il risultato più chiaramente confermato della discussione.
La teoria della community era che il backup scrivesse mentre la destinazione non era montata
Il responder riteneva che il processo di backup continuasse a scrivere nel percorso SMB previsto quando la condivisione non era montata correttamente, facendo sì che Linux scrivesse invece nella directory locale.
Il recupero confermato di 30 GB dimostra l'esistenza di file locali sotto il punto di mount, ma la spiegazione esatta del problema del backup è stata una diagnosi della community, non un intervento tecnico di IceWhale in questa discussione.
La gestione attuale di backup e spazio di archiviazione di ZimaOS è cambiata
L'attuale documentazione di ZimaOS descrive le attività di backup gestite e una gestione dello spazio di archiviazione più ampia. Per i nuovi processi, usa il flusso di lavoro di backup dell'attuale ZimaOS e verifica che la destinazione prevista sia effettivamente montata prima di iniziare grandi scritture.
Un flusso di lavoro più sicuro per individuare lo spazio mancante
- Usa
dfper confermare quale filesystem locale è pieno. - Analizza solo quel filesystem, in modo che i mount SMB, USB e RAID non gonfino i totali.
- Controlla separatamente Docker e AppData.
- Ispeziona
/DATA/.mediaper le directory dei punti di mount che contengono file locali reali. - Conferma che la destinazione non sia montata prima di eliminare qualsiasi elemento al di sotto di un punto di mount.
- Dopo la pulizia, verifica lo spazio libero e prova nuovamente la destinazione di backup.
Il caso dei 424 GB del primo utente era più ambiguo rispetto al caso successivo dei 30 GB
L'autore del post originale vedeva circa 424 GB in una directory denominata come l'SSD di backup disconnesso e riteneva che fossero dati duplicati. La discussione è poi passata dai controlli dei mount alle proposte di pulizia, ma il recupero verificato più chiaro della discussione è arrivato dall'utente successivo, che ha recuperato 30 GB.
Questa distinzione è importante perché una directory sotto /DATA/.media può rappresentare un montaggio attivo, un punto di montaggio obsoleto o file locali reali. Lo stesso percorso apparentemente identico non implica la stessa azione di pulizia sicura su ogni sistema.
Usa df e du per domande diverse
df risponde alla domanda «quale filesystem è effettivamente pieno?», mentre du risponde alla domanda «quali directory visibili contengono file?». Su un NAS con punti di montaggio annidati, i due strumenti possono sembrare in disaccordo perché du può entrare in altri filesystem se non gli viene impedito.
La discussione è diventata molto più chiara solo dopo che la diagnosi ha separato il filesystem locale ZimaOS-HD dai contenuti SMB e RAID montati.
Le perdite di corrente impreviste rendono più pericolosi i problemi dei punti di montaggio
Il caso successivo dei 30 GB è iniziato dopo un'interruzione di corrente mentre i backup erano in corso. Se una destinazione remota non viene rimontata correttamente dopo l'avvio, ma un processo di backup riprende o viene riavviato, il percorso può ancora esistere come normale directory locale.
Per i processi di backup importanti, verifica che la destinazione sia montata e scrivibile dopo un riavvio o un'interruzione di corrente, prima di presumere che il vecchio percorso punti ancora alla destinazione esterna.
Non eliminare manualmente overlay2 di Docker per recuperare spazio
All'inizio della discussione, i percorsi overlay di Docker apparivano visivamente prominenti nell'output del filesystem. La community ha specificamente avvertito di non eliminare file arbitrari da overlay2. Il livello di archiviazione di Docker deve essere gestito tramite Docker o il ciclo di vita dell'applicazione, non eliminando directory casuali dei layer.
ZimaOS ora mostra anche l'utilizzo dello spazio delle app
Le impostazioni attuali delle app ZimaOS mostrano il consumo di spazio delle applicazioni e consentono di pulire la cache per le app supportate. È utile per distinguere la normale crescita delle applicazioni dai dati nei punti di montaggio prima di passare al terminale.
La spiegazione di dove le applicazioni ZimaOS attuali memorizzano dati e cache fornisce una mappa iniziale più sicura del filesystem.
FAQ sullo spazio mancante
L'overlay2 di Docker era responsabile delle centinaia di gigabyte mancanti del primo utente?
No. Docker rappresentava solo una piccola frazione dello spazio utilizzato nell'output pubblicato.
Perché du può segnalare terabyte su un disco locale molto più piccolo?
Può contare ricorsivamente i filesystem remoti montati o RAID, a meno che la scansione non sia limitata al filesystem locale.
È stato confermato un recupero?
Sì. L'utente successivo ha recuperato 30 GB di dati locali memorizzati sotto una directory punto di montaggio SMB.
