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

Diagnosi probabile

Quando un server Linux va in crisi per mancanza di spazio, la causa più comune è una crescita improvvisa di log, cache, backup locali, file temporanei, dump di crash o dati applicativi. In altri casi il disco non è davvero pieno, ma lo spazio libero sembra sparito perché ci sono file cancellati ancora aperti da un processo, oppure perché una partizione separata, come /var o /home, è arrivata al limite mentre il resto del sistema ha ancora margine.

La sintomatologia tipica è molto concreta: servizi che smettono di scrivere, database in errore, update falliti, mail che si accodano, pannelli di controllo lenti o bloccati, e in casi peggiori il sistema che non riesce più a creare file temporanei. Se il disco è al 100%, la priorità non è fare pulizia “a caso”, ma identificare rapidamente quale filesystem è saturo e quale directory sta consumando spazio.

Su server in produzione la causa più frequente, in ordine pratico, è: log applicativi, log di sistema, cache, backup, upload utenti, database, file temporanei. Se il riempimento è improvviso e ricorrente, spesso c’è anche un processo anomalo o una rotazione log mancante.

Verifiche immediate

Prima di cancellare qualsiasi cosa, conviene fotografare la situazione con pochi comandi sicuri. L’obiettivo è capire se il problema riguarda tutto il disco o solo una partizione, e se lo spazio è occupato da file grandi o da tanti file piccoli.

1. Controlla i filesystem montati e il loro utilizzo. Esito atteso: individui subito la partizione in rosso.

   df -hT

2. Verifica se ci sono inode esauriti, perché a volte il disco sembra non pieno ma non si riescono più a creare file. Esito atteso: valore sotto il 100% su ogni filesystem.

   df -ih

3. Trova le directory più pesanti nel punto critico, ad esempio /var, /home o /srv. Se non sai quale sia la partizione problematica, parti da / e poi scendi. Esito atteso: emergono poche directory dominanti.

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

4. Se il problema sembra essere in /var, controlla subito log, cache e code. Esito atteso: una sottodirectory anomala risulta molto più grande delle altre.

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

5. Verifica se ci sono file cancellati ma ancora aperti da processi attivi. Questo caso è molto comune: lo spazio non si libera finché il processo non viene riavviato. Esito atteso: eventuali file “deleted” compaiono associati a un PID.

   lsof +L1

Se df mostra il disco pieno ma du non spiega la differenza, il sospetto principale è proprio un file eliminato ma ancora tenuto aperto. Se invece du mostra una directory enorme, la pulizia va fatta lì con criterio, partendo dai file meno critici.

Soluzione consigliata passo-passo

La via più sicura è liberare spazio in modo reversibile, senza toccare dati applicativi o database se non dopo averli identificati con certezza. L’ordine sotto privilegia le aree a basso rischio e i controlli dopo ogni passo.

1. Pulisci i log ruotati e compressi solo se sono chiaramente vecchi e non più necessari per il troubleshooting. Esito atteso: recupero immediato di spazio senza impatto sul servizio.

   sudo find /var/log -type f \( -name '*.gz' -o -name '*.old' -o -name '*.1' -o -name '*.log.*' \) -mtime +14 -print

   Se l’elenco è coerente, puoi rimuovere solo i file vecchi e chiaramente ruotati. Prima fai sempre un backup mentale della regola: niente file attivi, niente log correnti.

2. Riduci i log di sistema se usi systemd-journald. È un intervento sicuro e spesso risolutivo. Esito atteso: il journal torna sotto controllo.

   sudo journalctl --disk-usage

   Per una pulizia conservativa, conserva gli ultimi giorni e lascia il resto al sistema di rotazione.

   sudo journalctl --vacuum-time=7d

3. Controlla cache e temporanei in /tmp, /var/tmp e cache applicative. Esito atteso: trovi file vecchi, grandi o chiaramente temporanei.

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

   Se individui una cache enorme di un servizio noto, preferisci svuotarla con il servizio fermo o secondo la procedura prevista dal software, non con cancellazioni aggressive.

4. Verifica i backup locali. Spesso il problema nasce da archivi lasciati in produzione, copie scaricate due volte o snapshot manuali troppo vecchi. Esito atteso: distingui backup utili da copie obsolete.

   sudo find /backup /backups /var/backups -type f -mtime +30 -printf '%s %p
   ' 2>/dev/null | sort -n | tail

   Se trovi archivi obsoleti ma vuoi essere prudente, spostali temporaneamente in una directory di quarantena invece di eliminarli subito.

5. Controlla i file cancellati ma ancora aperti. Se lsof +L1 mostra processi con file enormi marcati come deleted, riavvia quel servizio in modo controllato. Esito atteso: lo spazio libero aumenta dopo il restart.

   sudo lsof +L1

   Per esempio, se il colpevole è un web server o un database, il riavvio del solo processo interessato libera lo spazio senza toccare il resto del sistema.

6. Se la partizione è dedicata a un servizio, ad esempio database o web, isola la causa prima di fare pulizie ulteriori. Esito atteso: il consumo è attribuito a un solo componente.

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

   Su ambienti hosting è frequente che /home sia pieno per upload degli utenti, mentre su server applicativi il problema si concentra in /var/lib/mysql, /var/lib/postgresql o nei log del web server.

Se il disco è pieno e il sistema è instabile, intervieni prima sulle cause più semplici e reversibili: log, cache, temporanei, backup duplicati. Evita di toccare database o directory applicative senza un riscontro preciso sulla loro funzione.

Controlli finali / rollback

1. Riesegui i controlli di spazio e inode. Esito atteso: almeno un margine libero ragionevole torna disponibile e i servizi riprendono a scrivere senza errori.

   df -hT

   df -ih

2. Verifica che i processi interessati non stiano ancora tenendo aperti file cancellati. Esito atteso: lsof +L1 non mostra più il file responsabile, oppure mostra solo elementi non critici.

   lsof +L1

3. Controlla i log del servizio che ha sofferto per il disco pieno, ad esempio web server, database o coda mail. Esito atteso: nessun nuovo errore di scrittura o di filesystem.

   sudo journalctl -p err -n 50 --no-pager

4. Se una pulizia ha creato un effetto collaterale, il rollback più sicuro è ripristinare i file spostati dalla quarantena o ricreare il backup cancellato solo se hai confermato che non serve più. Non fare rollback ciechi su file di sistema o database senza backup verificato.

5. Per prevenire il problema, imposta rotazione log, limiti di retention, alert di spazio libero e, se possibile, una soglia di allarme sopra il 15-20% di spazio residuo. In produzione è utile monitorare anche inode, crescita di /var/log, dimensione backup e spazio nei mount critici.

Assunzione pratica: i comandi sono pensati per distribuzioni Linux comuni come Ubuntu, Debian, AlmaLinux, Rocky Linux e CentOS, con privilegi sudo disponibili.