Disco pieno su server: come pulire in sicurezza

Un disco pieno e una delle emergenze più comuni sui server Linux: causa errori applicativi, blocco dei DB, crash di servizi e perdita di log. La tentazione di cancellare in fretta porta spesso a danni peggiori. Vediamo come liberare spazio in modo sicuro e prevenire ricadute.

Diagnosi rapida

Il primo comando: df -h per vedere quale filesystem e saturo. Poi du -sh /* 2>/dev/null | sort -h per identificare le directory più pesanti. Strumenti come ncdu (installabile con apt install ncdu) sono interattivi e velocissimi. Per file aperti ma cancellati che continuano a occupare spazio: lsof +L1 | grep deleted.

Aree tipiche da controllare

• /var/log: log che non ruotano o ruotano poco.
• /var/cache/apt/archives (Debian/Ubuntu): pacchetti scaricati.
• /tmp: file temporanei dimenticati.
• /var/lib/docker: immagini, container, volumi orfani.
• /var/lib/mysql o /var/lib/postgresql: dump, binlog, tabelle gonfiate.
• Home utenti: backup manuali, file dimenticati.
• Backup locali: snapshot accumulati.

Comandi sicuri

Pulizia cache APT: apt clean e apt autoclean. Pulizia journal: journalctl --vacuum-time=14d o --vacuum-size=500M. Pulizia Docker: docker system prune -a --volumes (attenzione: rimuove immagini non in uso). Pulizia /tmp: i file dovrebbero scomparire al reboot, manualmente find /tmp -mtime +7 -delete con cautela.

Procedura passo-passo

1. Esegui df -h e identifica il filesystem critico.
2. Usa du o ncdu per individuare le directory grandi.
3. Controlla file aperti ma cancellati con lsof +L1 e riavvia i servizi se necessario.
4. Pulisci cache e log con i comandi sicuri elencati sopra.
5. Configura o aggiorna logrotate per evitare ricadute.
6. Verifica i backup locali: trasferiscili off-site e rimuovili.
7. Pulisci Docker con prune se applicabile.
8. Per database, esegui dump-restore o ottimizzazione tabelle.
9. Pianifica monitoring del disco con alert a 75 percento e 85 percento.
10. Considera aumento spazio se la crescita e strutturale.

Errori comuni e come risolverli

• rm -rf su /var/log senza riavvio servizi: i file restano aperti, lo spazio non si libera; riavvia il servizio.
• Eliminare /var/lib/mysql per liberare spazio: distrugge il database, sempre dump prima.
• Truncate di file di log mentre l'app scrive: usa : > logfile (zero-truncate) o reload del servizio.
• Cancellare snapshot LVM/ZFS senza capire: alcuni rappresentano backup, attento.

Domande frequenti

D: Come trovo i file più vecchi di N giorni?
R: find /path -mtime +N -type f.

D: Posso ridurre il filesystem a caldo?
R: ext4 non supporta shrink a caldo; XFS non supporta shrink affatto. Pianifica grande.

D: Come prevengo dischi pieni?
R: Alert a 75 percento, logrotate aggressivo, separazione di /var/log e dati su volumi distinti.

Approfondimento tecnico: inode e filesystem fragmentation

Non sempre "disco pieno" significa byte esauriti: gli inode possono saturarsi prima. Ogni file/directory consuma un'inode; filesystem con milioni di file piccoli (cache, sessioni PHP, log shard) esauriscono prima gli inode dello spazio. Verifica con df -i. Soluzioni: ext4 si formatta con mke2fs -i custom; XFS gestisce inode dinamicamente. Per situazioni croniche, sposta cache in tmpfs o usa SQLite/Redis.

Su ext4 e XFS la frammentazione e meno problematica che su FAT/NTFS, ma su filesystem molto pieni (oltre 90 percento) le allocazioni diventano subottimali. Manteni sempre 10-15 percento di spazio libero per performance e operazioni di emergenza. Strumenti come e4defrag (ext4) e xfs_fsr (XFS) deframmentano online.

Scenari d'uso reali

Un server di sessioni PHP con migliaia di file accumulati esaurisce gli inode: pulizia con find -mtime +1 -delete via cron orario.

Un server Docker non ripulito accumula immagini orfane: 30 GB recuperati con docker system prune -a.

Un server di backup con milioni di file rsync risolve con destinazione XFS o ZFS, più efficienti su grandi quantità di metadata.

Checklist operativa gestione disco

• Monitoring df + df -i con alert a 75 e 85 percento.
• logrotate configurato per tutti i log.
• Pulizia cache APT periodica.
• Docker prune in cron mensile.
• Backup spostati su altro storage, non /var/log.
• Separazione /var/log su volume distinto.
• Trimming SSD (fstrim) settimanale.

Risorse e riferimenti

man find, df, du, ncdu. baobab per visualizzazione grafica. Per Docker: docs.docker.com/config/pruning. journald: man journalctl, journald.conf. Per database: documentazione VACUUM (PostgreSQL), OPTIMIZE TABLE (MySQL).

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su disco pieno su server richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.