Come eliminare i file inutili dal VPS e pulirlo davvero

Prima di cancellare: capire dove finisce davvero lo spazio

Su un VPS il disco si riempie quasi sempre per quattro motivi: log cresciuti senza rotazione, cache applicative o di pacchetto, file temporanei dimenticati e dati di servizio che non sono più utili ma restano sul filesystem. Il punto non è “liberare spazio” e basta: il punto è liberarlo senza rompere il sistema, senza perdere dati necessari e senza nascondere il problema che lo farà tornare tra una settimana.

La sequenza giusta è semplice: misurare, identificare il colpevole, pulire con criterio, verificare l’effetto, poi chiudere il buco con rotazione, policy o automazione. Se salti la parte di osservazione, stai solo spostando il rischio.

Il primo controllo è capire se il problema è davvero spazio esaurito o inode finiti. Il secondo è trovare i mount point pieni. Il terzo è distinguere tra file eliminabili subito e dati da trattare con più cautela.

Misura lo stato del disco prima di toccare qualsiasi cosa

Parti da una fotografia generale. Questi comandi non modificano nulla e ti dicono subito se stai inseguendo il posto giusto.

df -hT
findmnt -D
lsblk -f

Cosa guardare: in df -hT la colonna Use% e il mount point che satura; in findmnt -D eventuali filesystem separati per /var, /home, /tmp; in lsblk -f il tipo di filesystem e se hai partizioni dedicate che meritano una pulizia mirata.

Se df dice che il disco è pieno ma vedi pochi file grossi, controlla anche gli inode.

df -ih

Se gli inode sono al 100%, il problema non è il volume dei dati ma il numero di file piccoli: cache, sessioni, spool, directory di lavoro, miniature, file temporanei di applicazioni o maildir con troppa frammentazione.

Trova i consumatori reali senza fare danni

Il comando più utile resta du, ma va usato con criterio. Su un VPS con filesystem grandi, l’errore tipico è partire da / e aspettare troppo. Meglio scendere per livelli.

du -xhd1 / | sort -h
du -xhd1 /var | sort -h
du -xhd1 /home | sort -h
du -xhd1 /tmp | sort -h

Il flag -x evita di attraversare altri filesystem montati sotto la directory analizzata. È utile perché ti fa capire dove sta il consumo locale, non quello di volumi separati che potrebbero essere gestiti in altro modo.

Se hai ncdu, è spesso il modo più rapido per fare triage senza sparare nel mucchio.

ncdu -x /

In un ambiente operativo serio, ncdu è utile per la diagnosi, non per la pulizia cieca. Vedi il peso delle directory, poi entri nelle sole aree sospette e decidi caso per caso.

Le aree che riempiono quasi sempre un VPS

Ci sono zone che conviene controllare sempre prima di inventarsi pulizie creative. Ordinale così: log, cache, temporanei, backup locali, dati applicativi obsoleti.

1. Log di sistema e dell’applicazione

I log crescono perché qualcosa parla troppo o perché la rotazione non è configurata bene. Su systemd, il journal può diventare molto pesante se non limiti retention e dimensione.

journalctl --disk-usage
journalctl --vacuum-time=14d
journalctl --vacuum-size=500M

Prima di eseguire il vacuum, verifica quanto stai occupando. Dopo il taglio, controlla che i servizi continuino a scrivere correttamente e che non ci siano errori di permessi o path mancanti nei file di log applicativi.

Per i log classici sotto /var/log, cerca i file più grandi e verifica se la rotazione esiste davvero.

find /var/log -type f -size +100M -ls
ls -l /etc/logrotate.d/

Se trovi un file come /var/log/nginx/access.log o /var/log/php8.x-fpm.log cresciuto troppo, il rimedio corretto non è sempre troncarlo. Prima controlla la rotazione e poi, se serve, fai un taglio controllato con backup del file o con logrotate forzato dopo aver sistemato la policy.

2. Cache dei pacchetti e file temporanei

Su Debian e Ubuntu, la cache di apt può occupare spazio inutile se il server viene aggiornato spesso e nessuno la ripulisce. È una pulizia reversibile, ma va fatta sapendo cosa stai rimuovendo.

apt clean
apt autoclean
apt autoremove --purge

apt clean svuota la cache dei pacchetti scaricati. apt autoclean rimuove i pacchetti non più scaricabili dai repository. apt autoremove --purge elimina dipendenze rimaste orfane. Prima di quest’ultimo, controlla l’elenco proposto: non deve portarsi dietro librerie che servono ancora a pacchetti installati manualmente o da repository terzi.

Per i temporanei, il punto delicato è non cancellare file ancora in uso. /tmp e /var/tmp non vanno trattati come una discarica da svuotare a mano a caso. Se il sistema usa systemd-tmpfiles, sfrutta la politica già prevista.

systemd-tmpfiles --clean

Verifica prima la configurazione in /usr/lib/tmpfiles.d/, /etc/tmpfiles.d/ e le eventuali override locali. Se hai applicazioni che usano file temporanei in modo improprio, la vera correzione è spostarle su una directory dedicata con retention definita.

3. Backup locali e archivi dimenticati

Molti VPS si riempiono perché qualcuno ha lasciato backup compressi, export SQL, tarball di deploy o dump vecchi dentro /root, /opt o /var/backups. Qui il rischio è doppio: spazio e falsa sensazione di sicurezza.

Elenca i file più pesanti e controlla data, nome e destinazione. Non cancellare dump senza sapere se esiste una copia esterna valida e recente.

find /root /opt /var/backups -type f -printf '%TY-%Tm-%Td %TT %s %p
' | sort -n | tail -n 50

Se trovi archivi di deploy o backup manuali, la regola è semplice: tieni solo ciò che rientra nella retention concordata. Tutto il resto va spostato su storage esterno o su un sistema di backup vero, non su un VPS che deve anche servire traffico.

4. Log applicativi e directory di runtime

In stack LAMP/LEMP il consumo può arrivare da PHP-FPM, web server, queue worker, cron, cache applicative, sessioni, upload temporanei e directory di elaborazione. Qui il problema non è solo la crescita, ma anche la distribuzione: file piccoli ovunque, difficile da vedere con una sola occhiata.

Controlla i log del web server e di PHP-FPM, poi le directory usate dalle app per cache e sessioni. In alcuni casi la cache non va svuotata a mano perché il framework la rigenera subito; in altri casi è proprio la cache corrotta a bloccare il funzionamento. La differenza la fanno i path e il comportamento dell’app.

du -sh /var/lib/php/sessions 2>/dev/null
find /var/cache -maxdepth 2 -type d -printf '%p
'

Se il sistema usa sessioni PHP su disco, un numero enorme di file piccoli può saturare gli inode prima ancora del volume. In quel caso, la soluzione strutturale è controllare la retention delle sessioni e valutare un backend diverso, per esempio Redis, se il carico lo giustifica.

Procedura pratica di pulizia senza improvvisazione

Quando hai individuato le aree pesanti, pulisci in questo ordine: ciò che è chiaramente effimero, ciò che è sicuramente rigenerabile, ciò che è vecchio e documentato, e solo alla fine ciò che richiede verifica applicativa.

1. Misura il punto di partenza. Esegui df -hT e annota la percentuale di utilizzo del filesystem interessato. Se non fai questa fotografia, non saprai mai se la pulizia è stata davvero efficace.
2. Metti in sicurezza i dati dubbi. Se stai per rimuovere log o dump che potrebbero servire, spostali prima in un’area di quarantine o in un archivio temporaneo fuori dal filesystem critico. Esempio: /root/quarantine/ su un volume con spazio disponibile.
3. Pulisci la cache dei pacchetti. Su Debian/Ubuntu esegui apt clean e poi apt autoremove --purge solo dopo aver letto l’elenco dei pacchetti da rimuovere.
4. Riduci il journal se è fuori scala. Usa journalctl --disk-usage e poi un --vacuum-size o --vacuum-time coerente con le tue esigenze di troubleshooting. Su un VPS piccolo, mantenere mesi di journal locale spesso è inutile.
5. Applica la rotazione ai log applicativi. Se un log cresce senza controllo, correggi logrotate o la configurazione del servizio prima di toccare il file a mano. Il file va pulito una volta, il problema va chiuso per sempre.
6. Rimuovi temporanei e residui sicuri. Cancella file in /tmp o cache applicative solo se sono chiaramente rigenerabili e non in uso. Per gli ambienti con processi lunghi, verifica gli handle aperti prima di intervenire.

Per scoprire se un file è ancora aperto da un processo, usa lsof. È un controllo spesso ignorato e invece salva da cancellazioni stupide.

lsof +L1
lsof | grep deleted

Il primo comando mostra file cancellati ma ancora aperti: spazio apparentemente non liberato finché il processo non chiude il descriptor. Il secondo aiuta a scovare log o file rimossi ma ancora trattenuti da un servizio. Se trovi questo caso, spesso il vero fix è riavviare il servizio coinvolto, ma solo dopo aver verificato che il restart non rompa sessioni o code critiche.

Quando il disco sembra pieno ma lo spazio non torna

Capita spesso questo scenario: cancelli file grandi, df continua a mostrare il filesystem quasi pieno e il problema sembra non risolversi. Le cause più comuni sono file ancora aperti, snapshot, overlay filesystem o spazio riservato al root su ext4.

Se hai cancellato file ma lo spazio non è tornato, verifica prima gli handle aperti con lsof +L1. Se il problema è su ext4 e hai una quota di blocchi riservati, controlla la configurazione del filesystem. Se usi LVM, snapshot vecchi o quasi pieni possono trattenere spazio in modo poco intuitivo.

tune2fs -l /dev/XXX | grep -i 'Reserved block count\|Reserved block percentage'
lvs -a -o +devices

Qui il cambio è delicato: non toccare i parametri del filesystem a occhi chiusi. Prima misura, poi valuta se il guadagno di spazio vale il rischio operativo.

Una pulizia fatta bene si chiude con una policy, non con un gesto manuale

Il VPS non va “ripulito” una volta sola. Va governato. Se oggi hai liberato 20 GB e tra dieci giorni sei punto e a capo, il problema non era la mancanza di mano pesante: era l’assenza di retention, rotazione e monitoraggio.

Le tre misure che evitano il ritorno del disastro sono queste: rotazione dei log con soglie realistiche, backup esterni con retention definita e alert sul consumo disco prima della soglia critica. Anche un semplice allarme al 80% e 90% cambia tutto, perché ti lascia margine per agire con calma.

Per i log, controlla che logrotate sia presente e funzionante. Un esempio tipico di file da verificare è in /etc/logrotate.d/. Per i servizi systemd, puoi anche usare limiti di dimensione del journal. Per i backup, evita archivi locali senza scadenza. Per le cache applicative, definisci TTL e cleanup automatico. Per gli upload temporanei, usa directory dedicate con scadenza e non il filesystem di sistema.

systemctl status logrotate.timer
systemctl list-timers | grep logrotate

Se il timer non è attivo, la rotazione potrebbe dipendere da cron o da un’integrazione specifica della distribuzione. In quel caso, verifica il meccanismo effettivo e non dare per scontato che la policy esista solo perché il file di configurazione è presente.

Checklist operativa rapida per pulire davvero un VPS

1. Controlla df -hT e df -ih per distinguere spazio e inode.
2. Individua i maggiori consumatori con du -xhd1 o ncdu -x.
3. Verifica log e journal con journalctl --disk-usage e find /var/log -type f -size +100M.
4. Ripulisci cache pacchetti e residui orfani con apt clean e apt autoremove --purge.
5. Controlla file cancellati ma ancora aperti con lsof +L1.
6. Se serve, riduci retention del journal o correggi la rotazione dei log.
7. Documenta cosa hai rimosso e quale policy impedisce che il problema torni.

La pulizia corretta non è quella che libera più gigabyte nel minor tempo possibile. È quella che libera spazio, lascia il sistema stabile e riduce la probabilità di ritrovarti nella stessa emergenza al prossimo picco di traffico o al prossimo deploy rumoroso.

Assunzione: ambiente Linux recente con systemd, filesystem standard e accesso root o sudo; prima di rimuovere log, dump o cache applicative, verifica sempre se esiste una retention esterna o una copia di sicurezza valida.