Linux: controlli rapidi quando il disco si riempie all’improvviso

Quando un server Linux esaurisce spazio disco, il sintomo arriva spesso senza preavviso: servizi che falliscono, log che si fermano, database che non scrivono più e aggiornamenti bloccati. In questi casi la priorità non è “pulire tutto”, ma capire quale filesystem è pieno, quale directory sta crescendo e se lo spazio è davvero occupato oppure solo apparentemente indisponibile.

Questo approccio è utile sia su VPS e server dedicati sia su macchine con cPanel, Plesk o FastPanel. L’obiettivo è semplice: individuare il colpevole, liberare spazio in modo reversibile e lasciare un controllo stabile per evitare che il problema si ripresenti.

Perché il disco si riempie “all’improvviso”

In pratica, quasi mai è davvero improvviso. Di solito la crescita è stata lenta, ma invisibile fino al superamento di una soglia critica. Le cause più comuni sono queste:

• log applicativi o di sistema cresciuti senza rotazione;
• backup locali accumulati nella stessa macchina;
• cache di applicazioni, CMS o proxy non limitate;
• file temporanei o upload abbandonati;
• database con binlog, dump o tabelle temporanee molto grandi;
• inode esauriti, anche quando lo spazio in GB sembra ancora disponibile;
• spazio occupato da file cancellati ma ancora aperti da un processo.

La distinzione importante è tra spazio disco e inode: il primo misura i GB disponibili, il secondo il numero di file. Si può avere un filesystem con spazio libero ma inode al 100%, e in quel caso il sistema si comporta come se il disco fosse pieno.

Controlli rapidi da fare subito

Se hai accesso SSH, questi controlli sono i primi da eseguire. Sono sicuri e non modificano nulla.

df -hT

Questo comando mostra filesystem, tipo, dimensione, spazio usato e punto di mount. L’esito atteso è identificare subito la partizione al limite, spesso /, /var, /home o un mount dedicato ai dati.

df -ih

Questo verifica gli inode. Se una partizione è al 100% sugli inode, devi cercare troppi file piccoli, non un singolo file enorme.

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

Questo mostra le directory più pesanti sul filesystem radice senza attraversare altri mount. L’esito atteso è individuare una directory dominante, per esempio /var o /home.

Se il server è sotto pannello, un controllo utile è anche la sezione storage o file manager del pannello stesso. Però, quando il disco è quasi pieno, SSH resta il metodo più rapido per una diagnosi affidabile.

Come trovare la cartella che cresce davvero

Una volta individuato il filesystem critico, scendi di livello con la stessa logica: prima directory, poi sottodirectory, poi file. Non partire dai singoli file a caso.

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

Se /var è la zona sospetta, controlla in particolare:

• /var/log per i log;
• /var/lib per database e servizi persistenti;
• /var/spool per code e mail in coda;
• /var/cache per cache locali;
• /var/tmp per temporanei.

Per trovare file grandi in una directory specifica:

find /var -xdev -type f -size +500M -printf '%s %p
' 2>/dev/null | sort -n

Questo elenca i file oltre 500 MB. L’esito atteso è identificare uno o più file anomali, come log giganteschi, dump dimenticati o archivi di backup.

Se sospetti un problema più diffuso, cerca gli elementi più grandi su tutto il filesystem principale:

find / -xdev -type f -size +1G -printf '%s %p
' 2>/dev/null | sort -n

Attenzione: su sistemi grandi questo controllo può richiedere tempo. È comunque non distruttivo.

Il caso nascosto: spazio occupato da file cancellati

Un errore molto comune è vedere il disco pieno anche dopo aver cancellato file grandi. In questi casi, il file è stato rimosso dal filesystem, ma un processo lo tiene ancora aperto. Lo spazio viene liberato solo quando il processo chiude il descrittore.

Per verificare:

lsof +L1

L’esito atteso è la presenza di file marcati come deleted ma ancora aperti. Questo succede spesso con log di web server, database o applicazioni in esecuzione continua.

Se trovi un file così, il fix più sicuro è riavviare il servizio che lo tiene aperto, non cancellare altro a caso. Per esempio, se il file è di un web server, può bastare un reload o restart controllato del servizio interessato.

Soluzione consigliata: liberare spazio senza rischi

La regola è: prima i file temporanei e i log vecchi, poi i backup locali, poi gli artefatti applicativi. Evita di toccare subito file di database o directory non identificate con certezza.

1. Se la crescita è nei log, ruotali o comprimi quelli vecchi. In ambienti con logrotate, verifica che la rotazione stia funzionando e che non ci siano file fuori controllo in /var/log.
2. Se trovi backup locali inutili, spostali su storage esterno o eliminali solo dopo aver verificato che esista una copia valida altrove.
3. Se la cache occupa troppo spazio, svuotala solo se è una cache rigenerabile e non un archivio funzionale dell’applicazione.
4. Se il problema è un file enorme chiaramente temporaneo, valuta se può essere spostato in sicurezza prima di cancellarlo.

Per esempio, per controllare i log più grandi in /var/log:

find /var/log -type f -printf '%s %p
' 2>/dev/null | sort -n | tail -20

L’esito atteso è vedere i file più pesanti in cima all’elenco. Se un log è cresciuto troppo, il primo intervento corretto è fermarne la crescita, non solo cancellarlo.

Se usi logrotate, verifica che il servizio sia abilitato e che la configurazione includa i log giusti. In molti casi basta correggere la rotazione per risolvere il problema in modo stabile.

Verifica e pulizia di pacchetti o cache di sistema

Su sistemi Debian e Ubuntu, anche la cache di APT può crescere nel tempo. Su sistemi RHEL, Rocky, Alma e CentOS, può succedere con la cache del gestore pacchetti o con vecchi kernel non rimossi.

Prima verifica quanto spazio occupano le cache:

du -sh /var/cache/apt /var/cache/dnf /var/cache/yum 2>/dev/null

Se una di queste directory è enorme, puoi valutare la pulizia del gestore pacchetti, ma solo dopo aver confermato che il sistema è aggiornabile e che non stai rimuovendo informazioni utili per il troubleshooting.

Su Debian/Ubuntu, il controllo tipico è:

apt clean

Su RHEL-like, il comando equivalente è:

dnf clean all

Esito atteso: recupero di spazio nella cache senza impatto sui dati applicativi. È una pulizia reversibile e generalmente sicura.

Database e directory applicative: controlli mirati

Se il filesystem pieno ospita un database, non cancellare file a mano dentro le directory del motore. Prima identifica cosa occupa spazio: binlog, iblog, dump, temporanei o file di dati veri e propri.

Controlla la dimensione delle directory del database:

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

Se usi MariaDB o MySQL, il colpevole può essere un binlog molto grande. In quel caso la pulizia va fatta con i comandi del motore, non con eliminazioni dirette dal filesystem. Se non sei sicuro, fermati e verifica prima i log del database e la politica di retention.

Per le applicazioni web, controlla anche le directory di upload, cache e backup del CMS. Su WordPress, ad esempio, cartelle come wp-content/cache o wp-content/updraft possono crescere rapidamente se non governate. Lo stesso vale per installazioni con plugin di backup locali.

Controllo dei file cancellati ma ancora aperti

Quando df mostra disco pieno ma du non trova abbastanza spazio occupato, quasi sempre c’è un processo che tiene aperto un file già cancellato. È una delle situazioni più frustranti, ma anche una delle più facili da confermare.

lsof +L1 | head -50

Se vedi un processo importante con un file grande marcato come deleted, il controllo successivo è il servizio associato. Riavvia solo quel servizio, non l’intera macchina, se puoi farlo in sicurezza.

Se il processo è critico e il riavvio non è immediato, come workaround temporaneo puoi liberare spazio togliendo file sicuramente inutili e guadagnare margine per pianificare un restart ordinato.

Prevenzione: evitare che succeda di nuovo

La prevenzione è più efficace della pulizia occasionale. Bastano poche abitudini operative per ridurre molto il rischio:

• imposta rotazione e retention dei log;
• sposta i backup fuori dal server di produzione;
• controlla spazio e inode con alert automatici;
• limita cache e temporanei per servizio o applicazione;
• verifica periodicamente i file più grandi delle directory critiche.

Un controllo semplice e utile è schedulare un report periodico su spazio e inode. Per esempio, un cron giornaliero può salvare l’output di df -hT e df -ih in un file di monitoraggio, così da vedere la crescita nel tempo.

Se hai un sistema di monitoraggio, imposta soglie di alert non solo al 100%, ma già all’80% o 85% su filesystem critici. Il vantaggio è che hai tempo di intervenire prima che il servizio vada in errore.

Checklist operativa rapida

1. Controlla df -hT e df -ih per capire se il problema è spazio o inode.
2. Individua la directory dominante con du -xhd1 sul filesystem interessato.
3. Verifica file grandi e log anomali con find.
4. Controlla i file cancellati ma ancora aperti con lsof +L1.
5. Applica la pulizia più sicura: log vecchi, cache, backup locali, poi verifica il recupero con df -hT.

Controlli finali e rollback

Dopo ogni intervento, il controllo finale deve confermare che il filesystem abbia recuperato margine sufficiente e che il servizio impattato sia tornato operativo. Verifica di nuovo:

df -hT

L’esito atteso è un calo reale dell’utilizzo e non solo apparente. Se hai fatto un restart di servizio, controlla anche che non siano comparsi nuovi errori nei log principali.

Se la pulizia non produce spazio sufficiente, il rollback non consiste nel “togliere altro”, ma nel ripristinare solo ciò che è stato rimosso in modo non essenziale e nel fermarsi a diagnosticare meglio. In particolare, non intervenire a mano dentro directory di database o servizi critici senza sapere con certezza cosa stai rimuovendo.

Assunzione operativa: i comandi proposti sono eseguiti su un sistema Linux con accesso amministrativo e filesystem standard tipo ext4, xfs o simili.