Linux: diagnosticare e risolvere un disco pieno con metodo

Quando il disco si riempie, il problema non è solo lo spazio

Su Linux un filesystem quasi pieno non provoca soltanto avvisi: può rallentare servizi, bloccare scritture, mandare in errore database, mail server e log, fino a far fallire aggiornamenti e backup. La parte più difficile non è liberare qualche gigabyte, ma capire cosa ha consumato spazio, dove si trova davvero il consumo e quale intervento sia sicuro senza peggiorare la situazione.

La regola migliore è semplice: prima si misura, poi si libera, poi si impedisce che succeda di nuovo. In ambiente server conviene procedere con calma, evitando cancellazioni “a sensazione” e privilegiando interventi reversibili.

Il sintomo tipico di un disco pieno

I segnali non sempre sono evidenti. A volte il sistema continua a rispondere, ma alcune applicazioni iniziano a fallire. In altri casi compaiono errori come “No space left on device”, backup incompleti, code mail bloccate o siti web che generano errori 500 perché non riescono più a scrivere file temporanei o log.

Va considerato anche un caso spesso trascurato: il disco può apparire “quasi vuoto” ma il sistema continua a dire che non c’è spazio. Questo succede, per esempio, quando ci sono file cancellati ma ancora aperti da un processo, oppure quando i inode sono esauriti. Quindi non basta guardare solo la percentuale di uso del filesystem.

Prima diagnosi: capire se il problema è spazio, inode o file aperti

Il controllo iniziale deve rispondere a tre domande: quanto spazio è occupato, se gli inode sono finiti e se qualche processo sta trattenendo file già eliminati.

df -hT

Questo comando mostra lo spazio usato per ogni filesystem, il tipo e il punto di mount. L’esito atteso è identificare subito la partizione critica, per esempio /, /var o /home.

df -ih

Questo controllo verifica gli inode. Se la colonna IUse% è al 100%, il problema non è la dimensione dei file ma il numero di file e directory presenti. È comune su server mail, cache, directory di sessione o cartelle con tanti piccoli file.

sudo lsof +L1

Questo comando elenca i file cancellati ma ancora aperti. Se compare un processo con file molto grandi, lo spazio non verrà liberato finché quel processo non viene riavviato o chiude il file.

Capire dove si è concentrato il consumo

Una volta individuato il filesystem colpito, il passo successivo è trovare le directory più pesanti. Su server Linux conviene partire dal livello alto e scendere solo nei rami sospetti.

sudo du -xhd1 /var 2>/dev/null | sort -h

Questo comando mostra l’occupazione delle directory sotto /var senza attraversare altri filesystem. È utile perché molte cause di saturazione si trovano qui: log, cache, spool mail, database, container, pacchetti temporanei. L’esito atteso è una lista ordinata che evidenzi la directory dominante.

Se il problema è in /, si può fare lo stesso su root:

sudo du -xhd1 / 2>/dev/null | sort -h

Quando una directory emerge come anomala, si entra un livello più in basso. Per esempio, se /var pesa troppo, si analizzano /var/log, /var/lib, /var/spool e /var/cache. Se il server ospita siti web, è utile controllare anche le directory degli utenti e i backup locali.

Le cause più frequenti su server Linux

In pratica, i colpevoli ricorrenti sono sempre pochi. I log non ruotati, backup dimenticati, cache applicative cresciute senza controllo, archivi compressi lasciati sul server, immagini temporanee, repository di pacchetti, file di dump e database che hanno accumulato tabelle o binlog.

Su hosting e VPS capita spesso questo scenario: il sito genera molti errori, i log aumentano rapidamente, la rotazione non è configurata bene e in poco tempo /var/log occupa decine di gigabyte. In altri casi sono i backup automatici a riempire /backup, /home o una cartella temporanea non monitorata. Su server mail, la crescita può arrivare da code bloccate, allegati, spool e mailbox molto grandi.

Soluzione consigliata: liberare spazio nel modo più sicuro

La regola è intervenire prima sulle aree più sicure e reversibili. Il primo obiettivo non è “cancellare tanto”, ma recuperare spazio senza rompere servizi.

1. Verificare i log: se /var/log è enorme, controllare quali file stanno crescendo. I log possono spesso essere archiviati o ruotati, non cancellati alla cieca.
2. Controllare i backup locali: se esistono archivi vecchi, copiarli altrove prima di rimuoverli dal server. I backup sono il primo candidato alla pulizia, ma solo dopo averne verificato la presenza esterna.
3. Pulire cache e temporanei: directory come /tmp, cache di pacchetti e cache applicative possono essere ripulite con prudenza, preferendo strumenti del sistema rispetto alla cancellazione manuale indiscriminata.
4. Ridurre file inutili del servizio colpito: per esempio log di web server, code mail bloccate, dump vecchi, file di sessione obsoleti o snapshot non necessari.

Se il filesystem è quasi pieno, è meglio liberare spazio in due tempi: prima una quantità minima che rimetta in sicurezza il sistema, poi una pulizia più ordinata. Anche 1-2 GB possono bastare per far ripartire processi critici e consentire ulteriori verifiche.

Intervento mirato sui log

I log sono la causa più comune e anche il punto in cui si possono fare danni se si agisce male. Cancellare un file di log aperto da un processo può non liberare spazio subito o può creare problemi di monitoraggio. È preferibile usare la rotazione prevista dal sistema o, se necessario, troncare solo dopo aver capito quale servizio sta scrivendo.

Per capire quali log crescono di più, conviene elencare i file più grandi nella directory interessata:

sudo find /var/log -type f -printf '%s %p
' 2>/dev/null | sort -nr | head -20

L’esito atteso è una classifica dei file maggiori. A quel punto si può valutare se il log è ancora utile, se va archiviato o se è un caso di errore ripetitivo da correggere alla radice.

Se un servizio sta generando troppi log, la soluzione corretta non è solo svuotare il file: bisogna capire perché produce errori continui. Un esempio classico è una configurazione sbagliata, una connessione database fallita o un problema DNS che manda in loop il web server o un’applicazione PHP.

Quando il colpevole è un processo con file cancellati

Questa è una situazione subdola: hai cancellato un file enorme, ma lo spazio non torna. In quel caso il file è ancora aperto da un processo. La verifica si fa così:

sudo lsof +L1

Se compare un file marcato come cancellato, il processo che lo mantiene aperto deve essere riavviato in modo controllato. Prima si identifica il servizio, poi si programma il riavvio nel momento meno impattante possibile. Se si tratta di un demone di sistema, spesso basta un restart del servizio. Se è un’applicazione web o un database, il riavvio va fatto con attenzione, verificando l’impatto sulle sessioni in corso.

Questa è una delle poche situazioni in cui lo spazio “torna” solo dopo il riavvio del processo, non dopo la cancellazione del file.

Se il problema sono gli inode

Quando gli inode finiscono, il filesystem non può più creare nuovi file anche se lo spazio libero esiste ancora. Il caso tipico è una directory con milioni di file piccoli: cache, sessioni, code, spool, thumbnail, file temporanei o cartelle applicative mal gestite.

Il primo passo è individuare la directory con il numero maggiore di file, non il peso maggiore. Un metodo pratico è scendere nelle directory sospette e contare gli elementi. Se l’area critica è nota, si può intervenire eliminando file temporanei scaduti, log troppo frammentati o cache che il software è in grado di rigenerare.

La prevenzione qui conta più del fix: quando un’applicazione produce moltissimi file piccoli, servono regole di pulizia periodiche e, se possibile, una configurazione che limiti la crescita della directory.

Database e spazio disco: il punto da non trascurare

MariaDB e MySQL possono occupare molto più spazio di quanto sembri, soprattutto con log binari, tabelle temporanee o database cresciuti senza manutenzione. Se /var/lib/mysql è una delle directory più grandi, non bisogna intervenire alla cieca. Prima si verifica quali database crescono, se esistono dump vecchi, se i binlog sono necessari e se ci sono tabelle da ottimizzare o archivi da esportare.

Su server di produzione la pulizia del database va fatta con più cautela del resto, perché una rimozione errata può causare perdita di dati o blocco delle applicazioni. In questo caso è fondamentale avere un backup recente e verificato prima di ridurre log o rimuovere dati obsoleti.

Ambienti hosting, cPanel, Plesk e FastPanel

Se il server è gestito da pannello, spesso conviene partire dall’interfaccia grafica perché mostra subito consumi, backup, log e account coinvolti. In cPanel si possono controllare spazio disco, file manager, backup e log degli account. In Plesk si può vedere la distribuzione dello spazio per dominio e accedere ai registri e ai backup. In FastPanel, la dashboard aiuta a individuare rapidamente siti, database e directory che occupano più spazio.

Il vantaggio del pannello è la velocità di orientamento. Il vantaggio del terminale è la precisione. Il metodo migliore è usarli insieme: prima si trova la zona colpita, poi si conferma con i comandi di verifica. Se il pannello mostra che un dominio è cresciuto in modo anomalo, il terminale permette di capire se il peso è dovuto a log, upload, cache o backup.

Prevenzione: come evitare che il disco si riempia di nuovo

Una correzione che non include prevenzione è solo una pausa prima del prossimo incidente. Dopo aver ripristinato spazio, conviene mettere in ordine quattro punti.

1. Rotazione log: verificare che i log ruotino correttamente e che i file vecchi vengano compressi o rimossi secondo policy.
2. Backup esterni: evitare di tenere sul server solo backup locali non controllati. Se un backup resta, deve avere una scadenza e una destinazione chiara.
3. Monitoraggio disco: impostare alert quando il filesystem supera soglie come 70%, 80% e 90%, così l’intervento avviene prima del blocco.
4. Pulizia periodica: cache, temporanei, sessioni e file di lavoro devono avere una scadenza automatica, non manuale.

Se il server ospita siti WordPress o altri CMS, è utile controllare anche le directory di upload, le cache dei plugin, i backup automatici generati dall’applicazione e i file di debug. Spesso il problema non è il motore Linux, ma il livello applicativo che continua a produrre file senza politica di retention.

Un metodo pratico da seguire ogni volta

Quando un disco si avvicina alla saturazione, conviene usare sempre la stessa sequenza operativa: prima si verifica il filesystem, poi si identifica la directory pesante, poi si distingue tra spazio, inode e file aperti, infine si applica il fix minimo e si ricontrolla. Questo riduce gli errori e impedisce interventi frettolosi.

In sintesi: non cancellare prima di aver misurato, non riavviare servizi senza sapere perché il file resta aperto, non confondere spazio libero con inode liberi e non considerare la pulizia completa finché non hai verificato che il filesystem sia tornato sotto soglia.

Il vero obiettivo non è svuotare un disco. È riportare il server in uno stato stabile, con spazio sufficiente, cause identificate e una regola che impedisca il ritorno del problema.

Checklist finale

• Verificare con df -hT quale filesystem è pieno.
• Controllare con df -ih se il problema sono gli inode.
• Individuare directory e file più pesanti con du e find.
• Controllare file cancellati ma ancora aperti con lsof +L1.
• Attivare rotazione log, monitoraggio e policy di pulizia per evitare il ritorno del problema.