Disco pieno sul VPS: trovare cosa lo occupa e liberarlo senza fare danni

Prima cosa: quanto è pieno e dove

Se il sito è giù con errori tipo "No space left on device" nei log di PHP o di Nginx, non perdere tempo a leggere: lancia subito

df -h

Guarda la colonna Use%: se il filesystem montato su / (o su /var se è una partizione separata) è al 100% o vicino, il problema è quello. Su VPS con disco unico di solito è una riga sola da controllare.

Trovato il filesystem pieno, serve sapere cosa lo occupa:

sudo du -x -h --max-depth=1 /var | sort -rh | head -20

Il flag -x evita di contare altri filesystem montati sotto /var (tipo tmpfs). Ripeti scendendo nella cartella più pesante finché non trovi il file o la directory specifica.

I soliti colpevoli, in ordine di frequenza

1. Log mai ruotati

Il caso più comune su VPS gestiti a mano. Controlla:

sudo du -sh /var/log/* | sort -rh | head -10

Su un sistema Ubuntu 24.04 con Nginx, i log vivono di default in /var/log/nginx/ (access.log e error.log), secondo la direttiva access_log path [ format [ buffer = size ] [ gzip[= level ] ] [ flush = time ] [ if = condition ]]; access_log off ; Default: access_log logs/access.log combined della documentazione ufficiale di Nginx. Se trovi un access.log da diversi gigabyte, la causa è quasi sempre logrotate non attivo o mai configurato per quel file. Vedi più sotto come sistemarlo.

2. Backup dimenticati

Cartelle tipo /root/backup, /home/*/backups, dump SQL lasciati da uno script di qualche mese fa. Si trovano con lo stesso comando du sopra, cercando nelle home e nelle cartelle di script custom. Qui si può cancellare a occhi chiusi solo se il backup è duplicato altrove (storage esterno, altro server): mai l'unica copia che hai.

3. Cache dei pacchetti

Su Ubuntu/Debian la cache di apt si accumula in /var/cache/apt/archives. Si libera senza rischio con:

sudo apt-get clean

Su sistemi con Plesk o cPanel, controlla anche le cache dei gestori pacchetti del pannello (yum/dnf su CentOS/AlmaLinux: sudo dnf clean all).

4. Immagini ridimensionate e cache applicative

WordPress con molti plugin di media, gallerie, o cache di thumbnail generate a runtime (wp-content/uploads/*-150x150.jpg e varianti) possono moltiplicare lo spazio usato dalle immagini originali. Si controllano con:

du -sh /var/www/*/wp-content/uploads 2>/dev/null

Qui occhio: cancellare le thumbnail è sicuro (vengono rigenerate), cancellare gli originali no.

5. Tabelle del database gonfie

Se il sito usa MySQL/MariaDB, i file di InnoDB vivono in /var/lib/mysql. Un du -sh /var/lib/mysql/* isola rapidamente il database o la tabella più pesante. Tabelle di log applicativo (sessioni, audit trail, cache di oggetti) cresciute senza manutenzione sono la causa più comune qui. Si risolve con un TRUNCATE sulla tabella interessata o con una pulizia periodica, non cancellando i file a mano.

6. Il caso che inganna: file cancellato ma ancora aperto

Hai cancellato un log enorme con rm, ma df -h continua a mostrare il disco pieno. Non è un bug: quando un processo ha un file aperto e tu lo cancelli, Linux non libera subito lo spazio su disco. Invece, rimuove la voce nella directory, quindi il file scompare dalla vista del filesystem. Lo spazio viene rilasciato solo quando il processo chiude il file o si riavvia.

Per trovare il processo che tiene ancora aperto il file cancellato:

sudo lsof +L1

Il valore mostrato nella colonna NLINK a 0 significa che il file non ha più una voce nella directory ma è ancora aperto. La riga che conta è quella con (deleted) accanto al nome del file: lì trovi PID e comando del processo responsabile.

Due strade per liberare lo spazio senza interrompere il servizio:

• riavviare il processo che lo tiene aperto (es. sudo systemctl restart nginx se è lui il responsabile);
• troncare il file descriptor direttamente, senza riavviare nulla:

sudo truncate -s 0 /proc/<PID>/fd/<FD>

sostituendo <PID> e <FD> con i valori letti dall'output di lsof. Questa seconda via è utile quando il processo non puoi permetterti di fermarlo (un database in produzione, per esempio).

Come si imposta la rotazione dei log perché non ricapiti

Su Ubuntu 24.04 logrotate è già installato e Ubuntu ships it preinstalled and already rotates the logs of system packages such as Nginx, rsyslog and apt. Il file che regola Nginx è /etc/logrotate.d/nginx e contiene di norma questa configurazione:

/var/log/nginx/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 0640 www-data adm
	sharedscripts
	postrotate
 invoke-rc.d nginx rotate >/dev/null 2>&1
	endscript
}

Se il log cresce comunque troppo in fretta per l'intervallo giornaliero, puoi aggiungere una regola per dimensione con la direttiva size (es. size 100M) accanto a daily: logrotate ruota appena il file supera quella soglia, indipendentemente dal giorno.

Per un'applicazione tua che scrive log fuori da /var/log (tipico con Laravel, Node, script custom), crea un file dedicato, ad esempio /etc/logrotate.d/myapp:

/home/deploy/apps/myapp/storage/logs/*.log {
	daily
	rotate 7
	missingok
	notifempty
	compress
	delaycompress
	create 0640 www-data www-data
}

Per testare la regola prima di fidarti, usa la modalità debug che simula la rotazione senza modificare nulla:

sudo logrotate -d /etc/logrotate.d/myapp

Verifica che è risolto

Dopo aver sistemato la regola, controlla lo stato della rotazione con:

sudo cat /var/lib/logrotate/status

e verifica che compaia la data dell'ultima rotazione per il tuo log. Da lì in poi, un df -h settimanale (o un alert di monitoraggio sulla soglia Use%) ti avvisa prima che il disco torni a riempirsi.

Su cPanel o Plesk

Su cPanel i log di Apache/Nginx sono già gestiti da cpanellogd, configurabile da WHM; su Plesk la rotazione dei log di dominio si imposta dal pannello in "Impostazioni di dominio > Gestione log", non toccando direttamente /etc/logrotate.d. Se lo spazio pieno dipende da log di sistema o di servizi non gestiti dal pannello, valgono comunque i comandi du e lsof di questa guida.

Se il disco è pieno ma non trovi nulla di grosso

Succede quando il VPS ha un disco piccolo (spesso capita su piani entry-level da 10-20 GB) e lo spazio è semplicemente esaurito dall'uso normale, non da un file anomalo. In questo caso il problema è il piano, non la configurazione: contatta l'assistenza del tuo provider per un upgrade di spazio o uno snapshot/resize del volume, allegando l'output di df -h e di du -x -h --max-depth=1 / così da escludere equivoci lato loro.

Koapanel e' un prodotto Prime Software.