--- title: "Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu" description: "Disco pieno su VPS Debian/Ubuntu: diagnosi con ncdu e lsof, file cancellati ma aperti, inode esauriti, journal bloat, logrotate e prevenzione. Caso reale PMI." canonical: "https://www.mauriziofonte.it/blog/post/risolvere-problemi-spazio-disco-vps-debian-ubuntu.html" author: "Maurizio Fonte" date: "2025-07-14T07:20:06+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Linux & Server" tags: ["Linux & Server", "Performance"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) [Performance](https://www.mauriziofonte.it/blog/cat/performance.html) # [Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/risolvere-problemi-spazio-disco-vps-debian-ubuntu.html) Lunedì 14 Luglio 2025, alle 07:20 ![Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu](https://www.mauriziofonte.it/image/002090200-risolvere-problemi-spazio-disco-vps-debian-ubuntu.jpg) Il 19 maggio 2025, alle 11:30 di un lunedì mattina, il responsabile amministrativo di una PMI romagnola - azienda di distribuzione alimentare con gestionale Laravel 10 per ordini, fatturazione e logistica - mi ha chiamato perché il gestionale restituiva errore 500 su tutte le pagine. Il VPS era un Hetzner CX21 - 2 vCPU, 4 GB di RAM, 80 GB NVMe - con Debian 12, Nginx, PHP-FPM 8.2 e MySQL 8.0. I 18 operatori commerciali che normalmente usavano il gestionale per inserire ordini e stampare bolle di accompagnamento erano completamente fermi. Il fatturato giornaliero dell'azienda era circa 45.000 euro, e ogni ora di fermo significava ordini non processati, consegne ritardate e clienti della ristorazione che non ricevevano la merce per il servizio serale. La diagnosi è stata immediata: `df -h` mostrava `/dev/sda1` al 100%, zero byte disponibili. MySQL non riusciva a scrivere nel binary log e si era fermato, PHP-FPM non poteva scrivere i file di sessione e restituiva errore, e il `laravel.log` stesso non riusciva a registrare gli errori perché non c'era spazio per scrivere. Un disco pieno al 100% è il guasto più comune e più paralizzante su un VPS unmanaged, e il percorso di risoluzione ha almeno tre trappole che ho visto intrappolare sysadmin inesperti per ore. In questo articolo ti racconto la diagnosi completa, i fix immediati e il protocollo di prevenzione che installo su ogni VPS. > Stai cercando un **Consulente Informatico** esperto per risolvere emergenze sulla tua infrastruttura VPS? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su Hetzner, OVH, Contabo e Digital Ocean. [Contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami). ## Come si diagnostica un disco pieno e dove guardare per primo? Il primo comando è `df -hT` - mostra lo spazio usato per ogni filesystem con il tipo di filesystem. Il secondo comando è `ncdu /` (se installato) o `du -xsh /* | sort -rh | head -10` - mostra quali directory occupano più spazio. L'ordine è importante: prima capisci quanto spazio manca, poi capisci dove sta il problema. ```bash # 1. Panoramica del disco df -hT # 2. Trovare le directory più grandi (ricorsivo) du -xsh /* 2>/dev/null | sort -rh | head -10 # 3. Scendere nella directory colpevole du -xsh /var/* 2>/dev/null | sort -rh | head -10 du -xsh /var/log/* 2>/dev/null | sort -rh | head -5 ``` Per una diagnosi visuale e interattiva, [ncdu](https://dev.yorhel.nl/ncdu) (NCurses Disk Usage) è lo strumento migliore - un file manager per il terminale che mostra la dimensione di ogni directory in tempo reale con navigazione ad albero. Su Debian 12 si installa con `apt install ncdu` e si lancia con `ncdu /`. In meno di un minuto scansiona l'intero filesystem e ti mostra esattamente dove stanno i file più grandi, con la possibilità di cancellarli direttamente dall'interfaccia. Il flag `-x` in `du` è fondamentale: limita la scansione al filesystem corrente, evitando di attraversare mount point (come `/proc`, `/sys` o mount NFS) che falserebbero i risultati. Senza `-x`, `du` su un server con volumi montati può impiegare minuti e restituire numeri senza senso. Nel caso romagnolo, la gerarchia era chiara: `/var` occupava 71 GB su 80 GB totali. Dentro `/var`: `/var/log` occupava 38 GB e `/var/lib/mysql` occupava 29 GB. Dentro `/var/log`: un singolo file `laravel.log` da 34 GB - un anno di log senza rotazione, con livello di logging impostato su `debug` in produzione. ## La prima trappola: cancellare un file non libera lo spazio Questa è la trappola più insidiosa e quella che causa più confusione. Il responsabile IT dell'azienda - un diplomato con buone basi informatiche ma senza esperienza di sysadmin Linux - aveva già provato a risolvere il problema prima di chiamarmi: aveva fatto `rm /var/www/html/storage/logs/laravel.log` per rimuovere il file da 34 GB. Ma `df -h` continuava a mostrare il disco al 100%. Aveva provato a cancellare altri file. Ancora 100%. Aveva provato `sync`. Ancora 100%. Si era convinto che il disco fosse guasto. Il motivo è una proprietà fondamentale dei filesystem Linux: quando cancelli un file che è ancora aperto da un processo, il file scompare dal filesystem (non lo vedi più con `ls`) ma lo spazio non viene liberato finché il processo non chiude il file descriptor. PHP-FPM stava scrivendo continuamente su `laravel.log`, quindi anche dopo l'`rm` il file descriptor restava aperto e i 34 GB restavano occupati. La diagnosi di questa situazione si fa con `lsof`: ```bash # Trovare file cancellati ma ancora aperti (occupano spazio fantasma) lsof +L1 2>/dev/null | awk '{print $7, $1, $9}' | sort -rn | head -10 # Output tipico: # 35987456000 php-fpm8 /var/www/html/storage/logs/laravel.log (deleted) # 2147483648 mysql /var/lib/mysql/binlog.000047 (deleted) ``` Il fix è semplice: riavvia il servizio che tiene aperto il file. Dopo `systemctl restart php8.2-fpm`, i 34 GB sono stati liberati istantaneamente. Ma l'approccio migliore - che evita il riavvio del servizio - è **troncare** il file anziché cancellarlo: ```bash # CORRETTO: troncare il file a zero (il file descriptor resta valido) truncate -s 0 /var/www/html/storage/logs/laravel.log # SBAGLIATO: cancellare il file (lo spazio non si libera) rm /var/www/html/storage/logs/laravel.log ``` Il `truncate -s 0` imposta la dimensione del file a zero byte senza rimuoverlo dal filesystem. Il processo che lo ha aperto continua a scrivere nello stesso file (ora vuoto) senza problemi. È la differenza tra svuotare un bicchiere e rompere il bicchiere - nel primo caso puoi continuare a usarlo, nel secondo no. ## La seconda trappola: il disco è "pieno" ma non ci sono file grandi A volte `df -h` mostra il disco al 100% ma `du -sh /` riporta un totale molto inferiore allo spazio occupato. Oltre ai file deleted-but-open, c'è una seconda causa: l'esaurimento degli **inode**. Ogni file su un filesystem Linux occupa un inode, e il numero di inode è fisso (stabilito alla formattazione). Se crei milioni di file piccolissimi - tipicamente file di sessione PHP, file di cache, email in coda - puoi esaurire gli inode prima dello spazio disco. ```bash # Controllare l'utilizzo degli inode df -i # Se gli inode sono al 100%, trovare dove sono i milioni di file find / -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -10 ``` Nel caso romagnolo gli inode non erano il problema, ma l'ho verificato come parte della diagnosi standard. Su un altro VPS di un cliente con Magento, ho trovato 4.2 milioni di file di sessione PHP in `/var/lib/php/sessions/` - ogni sessione era un file da 2 KB, ma 4.2 milioni di file avevano esaurito il 98% degli inode disponibili. ## La terza trappola: il journal di systemd che cresce senza limiti Su Debian 12, `systemd-journald` salva i log di sistema in formato binario in `/var/log/journal/`. La [documentazione ufficiale di systemd](https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html) specifica che di default non c'è un limite esplicito alla dimensione del journal, che può crescere fino a occupare il 15% del filesystem. Su un VPS da 80 GB, significa fino a 12 GB di journal che pochi controllano. ```bash # Quanto spazio occupa il journal? journalctl --disk-usage # Ridurre immediatamente a 200MB journalctl --vacuum-size=200M # Impostare un limite permanente # In /etc/systemd/journald.conf: # SystemMaxUse=200M # MaxRetentionSec=7d systemctl restart systemd-journald ``` ## Il protocollo di pulizia che uso in emergenza Quando arrivo su un VPS con disco al 100% e i servizi fermi, eseguo questa sequenza in ordine di impatto decrescente: ```bash # 1. Liberare spazio immediato: cache APT e kernel vecchi apt clean apt autoremove --purge -y # 2. Journal systemd journalctl --vacuum-size=200M # 3. File grandi in /var/log (troncare, non cancellare) find /var/log -type f -name "*.log" -size +100M -exec truncate -s 0 {} \; # 4. Binary log MySQL (se non servono per replica) mysql -u root -p -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 1 DAY);" # 5. File cancellati ma aperti (dopo i truncate/purge precedenti) # Se lsof mostra ancora file (deleted), riavviare i servizi interessati lsof +L1 2>/dev/null | grep deleted # 6. File temporanei vecchi find /tmp -type f -mtime +7 -delete 2>/dev/null find /var/tmp -type f -mtime +30 -delete 2>/dev/null ``` Nel caso romagnolo, questa sequenza ha liberato 52 GB in meno di dieci minuti: 34 GB dal `laravel.log` (dopo il restart di PHP-FPM), 8 GB dalla cache APT, 6 GB dal journal systemd, e 4 GB dai binary log MySQL. Il disco è passato dal 100% al 35%, MySQL è ripartito, e il gestionale è tornato operativo. ## I cinque colpevoli più comuni dello spazio disco su VPS di PMI Dopo oltre venti interventi su disco pieno negli ultimi due anni, i colpevoli sono sempre gli stessi cinque, in ordine di frequenza: **Log applicativi non ruotati** - Laravel, Magento, WordPress, applicazioni custom. Il log cresce indefinitamente perché nessuno ha configurato `logrotate` o perché il livello di logging è impostato su `debug` in produzione. Il record personale: un `laravel.log` da 87 GB su un Hetzner AX51, causato da un middleware di logging che registrava il body completo di ogni richiesta API inclusi gli upload di immagini in base64. **Binary log MySQL** - MySQL scrive ogni operazione di scrittura nel binary log per la replica e il point-in-time recovery. Se `binlog_expire_logs_seconds` non è configurato (default: 2.592.000 secondi = 30 giorni), i binary log si accumulano per un mese intero. Su un database con molte scritture, 30 giorni di binary log possono occupare decine di GB. **Cache APT e kernel vecchi** - Ogni aggiornamento di sistema scarica i pacchetti `.deb` in `/var/cache/apt/archives/` e non li rimuove automaticamente. Ogni aggiornamento kernel installa un nuovo kernel image senza rimuovere il precedente. Dopo due anni di aggiornamenti, ho visto `/var/cache/apt/` a 8 GB e cinque kernel vecchi che occupavano 3 GB. **Docker e i suoi volumi** - Se il VPS usa Docker, la directory `/var/lib/docker/` può crescere in modo incontrollato: immagini non utilizzate, container fermati, volumi orfani, build cache. Un `docker system prune -a --volumes` può liberare decine di GB, ma va usato con cautela perché rimuove tutto ciò che non è attivamente in uso. **Backup locali dimenticati** - Dump MySQL schedulati con cron che si accumulano in `/root/backups/` o `/var/backups/` senza retention. Ho trovato VPS con 18 mesi di dump giornalieri - 540 file `.sql.gz` che occupavano 45 GB. Ho descritto la strategia corretta di [backup per VPS unmanaged](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html) con BorgBackup e retention GFS in un articolo dedicato. ## Prevenzione: logrotate e monitoring per non ritrovarsi mai più al 100% La pulizia d'emergenza risolve il sintomo. La prevenzione risolve la causa. Sul VPS romagnolo ho implementato tre misure che installo come standard su ogni VPS. Prima: **logrotate** per il log di Laravel e per tutti i log applicativi. Laravel non configura logrotate di default - il file `laravel.log` cresce indefinitamente se non intervieni: ```text # /etc/logrotate.d/laravel /var/www/html/storage/logs/laravel.log { daily missingok rotate 7 compress delaycompress notifempty create 644 www-data www-data postrotate /usr/lib/php/php8.2-fpm-reopenlogs > /dev/null 2>&1 || true endscript } ``` La direttiva `postrotate` è cruciale: dopo la rotazione, segnala a PHP-FPM di riaprire i file di log, evitando il problema dei file cancellati-ma-aperti. Ho descritto la [gestione strategica dei log Laravel](https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html) con Monolog, canali separati e centralizzazione su Loki in un articolo dedicato. Seconda: **limite ai binary log MySQL** con retention automatica: ```ini # In /etc/mysql/mysql.conf.d/mysqld.cnf binlog_expire_logs_seconds = 259200 # 3 giorni max_binlog_size = 100M ``` Terza: **monitoring dello spazio disco** con alert all'80%: ```bash # Cron ogni ora: alert se disco sopra 80% 0 * * * * df -h / | awk 'NR==2 && int($5)>80 {print "DISCO " $5 " pieno"}' | \ mail -s "DISK ALERT $(hostname)" admin@esempio.it ``` Ho documentato queste e altre misure preventive nell'articolo sulla [checklist emergenza per VPS Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html), e il piano completo di [disaster recovery per applicazioni PHP](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) che copre anche gli scenari in cui il disco non è solo pieno ma è corrotto. Il disco pieno è il problema più prevedibile e più prevenibile nell'amministrazione di un VPS. Un logrotate configurato, un limite ai binary log MySQL e un alert all'80% costano meno di un'ora di setup e prevengono il 90% delle emergenze disco che vedo nelle PMI. Se il tuo VPS non ha nessuna di queste protezioni, è una questione di tempo - non di se - prima che il disco si riempia e il business si fermi. [Contattami](https://www.mauriziofonte.it/pages/contattami) se vuoi mettere in sicurezza la tua infrastruttura prima che succeda. Un audit dello spazio disco con configurazione logrotate, retention dei binary log e monitoring automatico richiede meno di due ore e può evitare giorni di downtime e migliaia di euro di mancato fatturato - come il caso romagnolo ha dimostrato nel modo più costoso possibile. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteDiagnosi e risoluzione di connessioni lente al database MySQL su VPS senza supporto tecnico: guida operativa per Debian e Ubuntu11 Luglio 2025](https://www.mauriziofonte.it/blog/post/diagnosi-risoluzione-connessioni-lente-mysql-vps.html)[Articolo successivo »Ottimizzare sessioni PHP su VPS gestite senza supporto tecnico: guida avanzata per Debian e Ubuntu15 Luglio 2025](https://www.mauriziofonte.it/blog/post/ottimizzare-sessioni-php-vps-debian-ubuntu.html) ### Articoli correlati a Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu - [Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html) La checklist operativa in 7 fasi che uso quando un VPS Debian o Ubuntu va in crisi: triage in 60 secondi con lo USE method, diagnosi disco pieno, · 9 Luglio 2025 ![Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/image/002030070-checklist-emergenza-debian-ubuntu-vps-unmanaged.jpg) - [Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html) A novembre 2024 ho gestito un incidente su un magazzino logistico cuneese in cui il server di produzione era stato fermato da un file laravel.log · 12 Giugno 2025 ![Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/image/001750070-gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.jpg) - [Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html) Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna · 16 Giugno 2025 ![Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/image/001790070-ripristino-operativita-web-provider-vps-unmanaged.jpg) - [Recuperare un /boot pieno durante l'upgrade senza reinstallare](https://www.mauriziofonte.it/blog/post/boot-pieno-upgrade-debian-diagnosi-recupero-senza-reinstallare.html) Una partizione /boot da 256 MB, tre kernel accumulati, un initrd cresciuto negli anni fino a 80 MB, e l'aggiornamento del kernel muore a metà · 21 Ottobre 2026 ![Recuperare un /boot pieno durante l'upgrade senza reinstallare](https://www.mauriziofonte.it/image/005720070-boot-pieno-upgrade-debian-diagnosi-recupero-senza-reinstallare.jpg) - [Backup incrementale di MySQL con xtrabackup: recovery point granulare senza blocchi](https://www.mauriziofonte.it/blog/post/backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.html) mysqldump su database da 200GB richiede 4 ore e blocca le query durante l'esecuzione. Con Percona XtraBackup ho configurato backup incrementali · 26 Marzo 2026 ![Backup incrementale di MySQL con xtrabackup: recovery point granulare senza blocchi](https://www.mauriziofonte.it/image/003110070-backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Risolvere problemi critici di spazio disco su VPS gestite senza personale tecnico: guida operativa per Debian e Ubuntu", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/risolvere-problemi-spazio-disco-vps-debian-ubuntu.html Pubblicato: 2025-07-14 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.