Quando un server è pieno: trovare cosa occupa il disco e prevenirlo
Un disco saturo ferma database, gestionali e rinnovo dei certificati nel momento peggiore. Come capire cosa lo riempie, liberare spazio senza danni e non ripetere l'errore.
Quando un server è pieno: da dove si comincia
Quando un server è pieno, quasi sempre a esaurirsi è lo spazio disco, e a occuparlo sono log, dump di database, copie locali o file temporanei cresciuti senza controllo. Si individua la cartella più pesante, si libera spazio solo dove si è certi di poter farlo e poi si rimuove la causa della crescita.
I sintomi raramente dicono «disco pieno». Dicono che il gestionale non salva, che il database si ferma con un errore in scrittura, che un certificato non si rinnova, che la posta in uscita resta in coda. Chi lo vive lo descrive come «il server è impazzito». In realtà il server sta facendo ciò che deve: non ha più dove scrivere.
C'è anche l'altro significato di «pieno», quello dei picchi di richieste, con processore e memoria saturi e le pagine che rispondono a rilento. È un problema diverso, con rimedi diversi. Qui parliamo del disco, dove la causa si lascia ricostruire con calma, perché la crescita lascia tracce.
Cosa riempie davvero un disco
Raramente è un file solo. Di solito è una crescita lenta, ignorata per mesi, che un giorno supera la soglia. I responsabili più comuni:
- Log applicativi e di sistema. Un'applicazione in errore può scrivere la stessa riga a ripetizione e riempire il disco in poche ore. Senza rotazione, anche i log sani (gli accessi di Nginx o Apache, il journal di sistema) si accumulano per anni.
- Database. In PostgreSQL i file del registro delle transazioni (WAL) restano sul disco se l'archiviazione o una replica si è bloccata. In MySQL i log binari possono accumularsi se non è impostata una scadenza. In SQL Server il log delle transazioni cresce quando il database richiede copie periodiche del log e nessuno le esegue.
- Docker. Immagini vecchie, container fermi, volumi orfani e log dei container senza limite di dimensione.
- Copie e dump locali. Il backup «temporaneo» salvato sullo stesso disco, mai ripulito, mai spostato altrove. Doppio problema: occupa spazio e, se il disco si rompe, si perde insieme ai dati.
Il caso del database merita attenzione, perché la tentazione è cancellare i file a mano. Non farlo. Eliminare a mano i file del registro delle transazioni di un database in funzione può impedirgli di ripartire. Si risolve la causa (la replica ferma, la copia del log mancante) e il database libera lo spazio da solo.
Cosa fare subito quando un server è pieno
L'ordine conta. Chi parte cancellando a caso rischia di togliere la cosa sbagliata con il sistema già in affanno.
- Misurare. Il comando df -h mostra quali partizioni sono piene e di quanto. Prima di toccare qualcosa, annotate i valori.
- Trovare la cartella pesante. Con du si scende per livelli, partendo dalla radice della partizione piena, finché si arriva al colpevole. Spesso è /var/log, la cartella dei dati di un database o quella di Docker.
- Liberare il minimo sicuro. Log vecchi già archiviati, file temporanei, pacchetti scaricati e non più utili, vecchie voci del journal di sistema. Comprimere è meglio che cancellare, quando si può.
- Riavviare il servizio che si era fermato, solo dopo aver recuperato spazio sufficiente, e controllare che scriva davvero.
- Trovare perché è cresciuto. Se un log ha riempito il disco in una notte, il problema è l'errore che lo genera, non la dimensione del file.
Per Docker, la pulizia di immagini e container inutilizzati recupera molto, ma va fatta sapendo cosa c'è in ognuno. Un volume «non usato» in quel momento può contenere i dati di un servizio fermo per manutenzione.
Disco libero sulla carta, ma non si scrive
Succede più spesso di quanto si pensi. df dice che c'è spazio, eppure il sistema risponde «nessuno spazio disponibile sul dispositivo». Due spiegazioni da conoscere.
La prima sono gli inode, cioè le voci con cui il file system tiene traccia dei file. Milioni di file minuscoli (sessioni, cache, code di posta) possono esaurirli prima dei byte. Si controlla con df -i.
La seconda: file cancellati ma ancora aperti da un processo. Lo spazio non torna finché il processo non li rilascia. Qualcuno ha svuotato a mano un log enorme, il disco è rimasto pieno uguale, e tutti si chiedono perché. Con lsof si cercano i file cancellati ancora aperti; riavviare il servizio che li trattiene li chiude e restituisce lo spazio.
Interventi preventivi: far sì che non succeda
Un disco pieno è quasi sempre un allarme che nessuno ha ricevuto. Il rimedio è meno spettacolare dell'emergenza, ma funziona.
Soglie e andamento. Un avviso a soglia fissa dice poco se non si sa se il disco cresce lentamente o a velocità di ora in ora. Servono la soglia e la tendenza: quanti giorni restano a questo ritmo. Il monitoraggio di risorse e scadenze serve a questo, non a produrre grafici.
Rotazione e conservazione dei log. Con logrotate si decide quanto tenere, quando comprimere, quando scartare. Su Debian e sulle altre distribuzioni Linux è di norma già presente, e molti pacchetti portano la propria regola: va verificato che l'abbiano anche le applicazioni installate a mano dopo.
Partizioni separate. Tenere log e dati su volumi distinti dal sistema evita che un log impazzito blocchi anche i servizi di base. È una scelta di progetto, facile all'inizio e laboriosa dopo.
Copie fuori dal server. Un backup che vive sullo stesso disco che protegge non è un backup. Vale anche la prova inversa: se le copie si accumulano, serve una regola di conservazione. Ne parliamo in backup che si possono davvero ripristinare.
Dimensionamento rivisto ogni tanto. I dati crescono, di solito più in fretta di quanto previsto all'acquisto. Come leggere le risorse di un server dedicato, di un VPS o di un ambiente cloud è spiegato in dimensionare e controllare le risorse.
Se leggendo questo elenco capite che in azienda nessuno ha il tempo di fare questi controlli con regolarità, non è una colpa. Vuol dire che la gestione dell'infrastruttura IT va affidata a qualcuno che lo faccia per mestiere, partendo da ciò che esiste oggi.
Chi controlla cosa: un compito da assegnare
Molti dischi pieni hanno la stessa storia: l'applicazione l'ha installata un fornitore, il server lo ha configurato un altro, e nessuno ricorda che i log vanno ruotati. Un inventario aggiornato (quali servizi girano, su quale macchina, con quali dati) è il punto di partenza di ogni controllo; ne abbiamo scritto in cosa proteggere davvero. Per le operazioni ordinarie sui sistemi Linux, la gestione di un server Linux ha la sua routine, e conviene che qualcuno ne risponda per nome.
Scrivete accanto a ogni server chi riceve l'avviso di spazio in esaurimento e quali verifiche fa per prime. Poi eseguite df su ciascuna macchina, annotate la percentuale e la cartella più grande: sarà il vostro punto di riferimento per accorgervi, la volta dopo, di quanto sta crescendo.
Domande frequenti
Come si capisce cosa sta riempiendo il disco di un server?
Si parte da df per vedere quale partizione è piena, poi con du si scende cartella per cartella fino a trovare quella più pesante. Spesso la causa è nei log, nei dati di un database o nei file di Docker.
Si possono cancellare i log di un server per liberare spazio?
I log applicativi vecchi sì, meglio comprimendoli o archiviandoli prima. I file del registro delle transazioni di un database in funzione invece non vanno rimossi a mano: si risolve la causa che li fa crescere.
Perché il disco risulta pieno anche dopo aver cancellato dei file?
Se un processo tiene ancora aperto il file cancellato, lo spazio non viene restituito finché il processo non lo rilascia. Si individuano questi file con lsof e di solito basta riavviare il servizio interessato.