'docker system prune -a' è sicuro?

Rimuove container fermi, reti inutilizzate, cache di build orfana e ogni immagine non usata da un container in esecuzione. I dati restano, a meno che non aggiungi --volumes. Con --volumes elimina anche i volumi inutilizzati — e il volume di un container di database fermo conta come inutilizzato. Evita quel flag se non sei sicuro.

Ho cancellato un log enorme ma df mostra ancora il disco pieno. Perché?

Un processo in esecuzione tiene ancora aperto il file, quindi il kernel non libera lo spazio. Trovalo con 'lsof +L1' e riavvia quel servizio. La prossima volta svuota un log attivo con 'truncate -s 0 file' invece di cancellarlo.

Quanto spazio libero conviene lasciare?

Almeno il 10–15%. Database, aggiornamenti dei pacchetti e pull di Docker hanno bisogno di spazio temporaneo, e un disco al 100% può corrompere un database a metà scrittura.

Posso aggiungere disco senza reinstallare?

Sì. Passare a un piano più grande amplia il disco sul posto e conserva i dati — Nano ha 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. L'upgrade riavvia il server una volta.

Cosa riempie di solito un piccolo VPS?

Per esperienza: immagini e cache di build di Docker, il journal di systemd, log applicativi che nessuno ruota e dump di database o archivi di backup dimenticati in /root.

Come liberare spazio su disco su un VPS senza romperlo

Disco pieno sul VPS? Trova cosa occupa spazio con du e ncdu, poi svuota cache apt, journal, residui Docker e log senza perdere dati.

"No space left on device" non arriva mai al momento giusto. Il database smette di accettare scritture, apt non riesce a finire un aggiornamento e Docker si rifiuta di scaricare proprio l'immagine che ti serve adesso. La buona notizia: su un piccolo VPS il colpevole è quasi sempre una di cinque cose, e lo trovi in due minuti.

1. Quanto è grave?

df -h /
df -i /

La prima riga mostra lo spazio usato. La seconda gli inode: se gli inode arrivano al 100% mentre lo spazio sembra a posto, hai milioni di file minuscoli (file di sessione, una coda di posta, una cartella di cache). Problema diverso, stesso sintomo.

2. Trova cosa pesa

Percorri l'albero dall'alto e ordina per dimensione:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x resta su un solo filesystem, così non finisce dentro /proc. Poi scendi in quello che pesa di più. Per navigare in modo interattivo, ncdu è molto più comodo:

apt install -y ncdu
ncdu -x /

Frecce per muoversi, d per cancellare. Attenzione con quest'ultimo.

3. Le vittorie facili

Sono sicure su qualsiasi server Ubuntu o Debian:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove elimina anche i vecchi kernel. Il journal di systemd è quello che sorprende tutti: lasciato a sé stesso può crescere fino a diversi gigabyte. Per limitarlo una volta per tutte, imposta SystemMaxUse=200M in /etc/systemd/journald.conf ed esegui systemctl restart systemd-journald.

4. Residui di Docker

Se usi Docker, guarda prima qui. Immagini vecchie e cache di build si accumulano a ogni deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a elimina le immagini che nessun container in esecuzione usa. Di solito è quello che vuoi, ma il deploy successivo le riscaricherà.

Quello pericoloso è docker system prune -a --volumes. I volumi contengono i tuoi dati, e un volume collegato a un container fermo conta come inutilizzato. È così che si perdono database. Non incollarlo da una risposta su un forum.

L'altro divoratore nascosto sono i log dei container. Limitali in /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Poi riavvia Docker. Il limite vale solo per i container creati dopo, quindi ricrea quelli più rumorosi con docker compose up -d --force-recreate.

5. Log e file dimenticati

Trova i file grandi ovunque sul disco:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

I ritrovamenti tipici: un backup.tar.gz di sei mesi fa in /root, un dump del database che qualcuno voleva scaricare, un log applicativo che non viene mai ruotato.

Un log su cui un servizio sta ancora scrivendo non va cancellato con rm: va svuotato.

truncate -s 0 /var/log/myapp/app.log

Se ne hai già cancellato uno e lo spazio non è tornato, un processo lo tiene ancora aperto:

lsof +L1

Riavvia il servizio indicato e lo spazio ritorna.

Quando pulire non basta

A volte i dati sono semplicemente reali: un database che cresce, file caricati dagli utenti, un modello. Allora la soluzione onesta è più disco. L'upgrade del piano amplia il disco sul posto e conserva tutto: Nano ha 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Il server si riavvia una volta. I dettagli sono nella documentazione dei piani.

Un'altra cosa che consuma spazio in silenzio: il file di swap. Se hai seguito la nostra guida allo swap, quei 1–2 GB sono messi in conto apposta. E se Docker è il consumatore principale, la guida all'installazione di Docker e quella sugli stack Compose mostrano come tenere a bada le immagini.

L'abitudine che previene tutto questo: limita il journal e i log di Docker dal primo giorno. Due righe di configurazione, e il "disco pieno" smette quasi del tutto di capitare.