Come pulire in modo sicuro un server Linux senza interrompere i servizi

Livello: Intermedio (sistemi di produzione)
Tempo stimato: circa 30 minuti
Obiettivo: liberare spazio su disco su un server Linux rimuovendo pacchetti inutilizzati, kernel obsoleti, log non più necessari e file nella cache, senza interrompere alcun servizio in esecuzione.

Questa guida presuppone l’accesso SSH a un VPS di produzione o simile. Non eseguire queste operazioni alla cieca su sistemi critici senza aver prima creato uno snapshot.

Introduzione

Con il passare del tempo, anche un VPS poco utilizzato accumula "peso morto": pacchetti orfani, kernel obsoleti, gigabyte di log non ruotati e residui della cache dei pacchetti. Se non controllato, un disco pieno causerà il crash del server web, interromperà le operazioni di scrittura sul database e riempirà la coda di posta. Questa guida alla pulizia del sistema Linux illustra come ripulire un server Linux in modo sicuro: controllando prima l’utilizzo del disco, rimuovendo ciò che è sicuro rimuovere e verificando che i servizi abbiano superato indenni il processo. Ogni comando qui riportato può essere eseguito in tutta sicurezza su un server attivo senza tempi di inattività.

Cosa pulirai

Categoria	Esempi	Risparmio tipico
Pacchetti e dipendenze inutilizzati	Librerie orfane, driver sostituiti	da 100 MB a 2 GB
Vecchi kernel	Versioni precedenti del kernel	200 MB per kernel
Cache dei pacchetti	File .deb / .rpm scaricati	da 500 MB a 5 GB
Log del journal	Archivi dei log di systemd	da 100 MB a 10 GB
File di log ruotati	/var/log/*.gz, *.1	Variabile

Prerequisiti

Prima di iniziare, assicurati che siano soddisfatte le seguenti condizioni:

• Sistema operativo: Ubuntu 24.04/26.04 LTS, Debian 13 o AlmaLinux 10
• Accesso: accesso con privilegi sudo o root al server tramite SSH
• Conoscenze richieste: padronanza del terminale Linux e navigazione di base nella riga di comando
• Backup: eseguire sempre uno snapshot o un backup prima di rimuovere in blocco i pacchetti su un server di produzione. Su INTROSERV è possibile richiedere un backup completo direttamente dall’Area Clienti.

Non procedere se si verifica una delle seguenti condizioni:

• La partizione/ è piena per oltre il 95%: il sistema potrebbe già non riuscire a eseguire le operazioni di scrittura. Risolvi prima la causa immediata (individua ed elimina manualmente un singolo file di grandi dimensioni).
• I servizi sono già inattivi o si comportano in modo imprevisto. Indagare sulla causa principale prima della pulizia per evitare di compromettere i servizi da cui dipendono i sistemi Linux.
• Non disponi di un backup o di uno snapshot. Esegui prima un backup o uno snapshot: su INTROSERV l’operazione richiede meno di 2 minuti dall’Area Clienti.

Passaggio 1: Controlla l'utilizzo del disco prima di iniziare

Livello di rischio: BASSO – Solo comandi di sola lettura. Nulla viene modificato.

Non eseguire mai una pulizia alla cieca. Innanzitutto, cerca di capire cosa sta effettivamente occupando spazio.

1.1 Verifica l’utilizzo complessivo del disco

Esegui il comando `df` per verificare l’utilizzo del disco a livello di filesystem:

df -h

Risultato previsto:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   34G  3.8G  90% /
tmpfs           1.0G     0  1.0G   0% /dev/shm

Una partizione / con un utilizzo superiore all'80% è un segnale di allarme. Oltre il 95%, i servizi inizieranno a non funzionare correttamente.

1.2 Individuare i principali consumatori di spazio

Utilizzare il comando `du` per analizzare le directory. Iniziare dalla radice e procedere verso il basso:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Questo mostra le prime 20 directory più grandi sotto /. I principali responsabili sono solitamente /var/log, /var/cache, /usr e /home.

Restringete ulteriormente il campo:

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 Controllare l’utilizzo degli inode

Lo spazio su disco non è l’unico limite. Gli inode tengono traccia del numero di file. Una partizione può avere spazio libero ma esaurire gli inode, il che causerà comunque il fallimento delle operazioni di scrittura.

df -i

Risultato atteso:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 210543 2410897    9% /

Se IUse% è superiore all'80%, probabilmente c'è una directory contenente decine di migliaia di file di piccole dimensioni — spesso una coda di posta, una directory di sessione o una cache PHP. Utilizza du --inodes per individuarla:

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Passaggio 2: Rimuovere i pacchetti e le dipendenze inutilizzati

Livello di rischio: MEDIO - La rimozione dei pacchetti è reversibile tramite la cronologia del gestore dei pacchetti, ma è consigliabile rivedere l’elenco prima di confermare.

I pacchetti inutilizzati sono gli elementi più sicuri da eliminare. Occupano spazio sul disco, non servono a nessun processo in esecuzione e, in alcuni casi, contengono vulnerabilità CVE non corrette.

2.1 Ubuntu / Debian - apt autoremove

apt autoremove rimuove i pacchetti che sono stati installati come dipendenze ma che non sono più necessari a nulla:

sudo apt autoremove --purge -y

L'opzione --purge rimuove anche i file di configurazione residui. Senza di essa, il binario del pacchetto viene eliminato ma i file di configurazione rimangono al loro posto.

Risultato atteso:

The following packages will be REMOVED:
  libfoo1 libbar2 old-driver-utils ...
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

2.2 AlmaLinux / RHEL - dnf autoremove

sudo dnf autoremove -y

Sui sistemi RHEL 7 / CentOS 7 meno recenti, utilizzare `yum autoremove`:

sudo yum autoremove -y

2.3 Pulizia della cache dei pacchetti

Dopo gli aggiornamenti e le installazioni, i gestori di pacchetti memorizzano localmente i file di archivio scaricati. È sicuro eliminarli una volta completata l’installazione.

Ubuntu / Debian:

sudo apt clean

Questo comando rimuove tutti i file .deb memorizzati nella cache dalla directory /var/cache/apt/archives/. Per rimuovere solo i pacchetti che non sono più disponibili nel repository (versioni sostituite):

sudo apt autoclean

AlmaLinux / RHEL:

sudo dnf clean all

Risultato atteso:

16 files removed

Passaggio 3: Eliminare i vecchi kernel

Livello di rischio: ALTO - La rimozione del kernel sbagliato rende il server non avviabile dopo il successivo riavvio. Verificare sempre con ` uname -r ` prima di procedere.

Ogni aggiornamento del kernel lascia la versione precedente al suo posto come misura di sicurezza. Dopo aver verificato che il server funzioni stabilmente con il nuovo kernel, è possibile rimuovere in tutta sicurezza i vecchi kernel: ciascuno di essi libera in genere 200-400 MB.

3.1 Verificare quale kernel è in esecuzione

Non rimuovere mai il kernel con cui il sistema è attualmente avviato:

uname -r

Risultato atteso:

5.15.0-105-generic

3.2 Elencare tutti i kernel installati

Ubuntu / Debian:

dpkg -l | grep linux-image | awk '{print $2}'

Risultato atteso:

linux-image-5.15.0-100-generic
linux-image-5.15.0-105-generic
linux-image-generic

Il meta-pacchetto non deve essere rimosso: tiene traccia del kernel attualmente consigliato:

• Ubuntu: linux-image-generic
• Debian: linux-image-amd64
• AlmaLinux: Non viene utilizzato alcun metapacchetto, si basa su installonly_limit in dnf.

Rimuovere solo i pacchetti con versione specifica che non corrispondono al kernel attuale.

AlmaLinux / RHEL:

rpm -q kernel

Risultato previsto:

kernel-5.14.0-284.11.1.el9_2.x86_64
kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Rimuovere i vecchi kernel

Ubuntu / Debian - metodo automatico:

Il comando `apt autoremove` del Passo 2 gestisce già i vecchi kernel su Ubuntu se è installato `linux-image-generic`. È anche possibile selezionarli in modo esplicito. Sostituisci la versione con quella che desideri rimuovere (non quella attualmente in esecuzione):

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL:

Il gestore di pacchetti dnf conserva un numero configurabile di vecchi kernel. Impostare il limite nel file /etc/dnf/dnf.conf:

sudo nano /etc/dnf/dnf.conf

Aggiungere o aggiornare la riga:

installonly_limit=2

Quindi eseguire:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Questo comando rimuove tutti i kernel tranne i due più recenti.

Passaggio 4: Pulizia dei log di journal

Livello di rischio: BASSO - Rimuove solo le voci di log archiviate. I servizi in esecuzione non ne risentono.

systemd-journald raccoglie i log da ogni servizio presente sul sistema. Per impostazione predefinita, può crescere senza limiti fino a raggiungere il limite di spazio su disco o fino a quando tale limite non si azzeri.

4.1 Verifica delle dimensioni attuali del journal

journalctl --disk-usage

Risultato atteso:

Archived and active journals take up 2.3G in the filesystem.

4.2 Ridurre il journal

Per conservare solo i log degli ultimi 7 giorni:

sudo journalctl --vacuum-time=7d

Per conservare solo gli ultimi 500 MB:

sudo journalctl --vacuum-size=500M

Risultato atteso:

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Impedire la crescita futura del journal

Creare un file di configurazione drop-in per limitare in modo permanente le dimensioni del journal (su AlmaLinux 10, il file di configurazione principale non è comunque presente in /etc/ per impostazione predefinita, rendendo questo l'approccio standard):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Applicare la modifica:

sudo systemctl restart systemd-journald

Passaggio 5: Pulizia dei file di log ruotati e obsoleti

Livello di rischio: MEDIO - Vengono eliminati solo gli archivi compressi. Non modificare i file privi dell’estensione .gz o di un suffisso numerico.

I log delle applicazioni in /var/log/ sono gestiti da logrotate. Normalmente, logrotate conserva un numero prestabilito di copie ruotate e le comprime automaticamente. Se logrotate è stato configurato in modo errato o non è in esecuzione, è possibile che si accumulino grandi quantità di file .gz, .1, .2.

5.1 Individuare i file di log di grandi dimensioni

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

Oppure, più semplicemente:

sudo du -h /var/log | sort -rh | head -20

5.2 Eliminare i vecchi archivi di log compressi

I log ruotati compressi (.gz) possono essere eliminati in tutta sicurezza. Si tratta di archivi di file di log già chiusi.

Per prima cosa, visualizza in anteprima ciò che verrà rimosso: esegui il comando senza l'opzione -delete per visualizzare l'elenco:

sudo find /var/log -name "*.gz" -mtime +30

Se l'output sembra corretto, esegui l'eliminazione vera e propria:

sudo find /var/log -name "*.gz" -mtime +30 -delete

Questo comando elimina gli archivi di log .gz più vecchi di 30 giorni.

5.3 Verificare che logrotate sia configurato correttamente

Verificare quali servizi dispongono di configurazioni logrotate:

ls /etc/logrotate.d/

Eseguire logrotate manualmente in modalità debug per verificare che funzioni senza errori:

sudo logrotate -d /etc/logrotate.conf

Il flag -d è una simulazione: non viene modificato nulla, ma è possibile vedere esattamente cosa accadrebbe. Se un servizio non è presente in /etc/logrotate.d/, creare una configurazione apposita. Consultare la guida alla rotazione dei log per le istruzioni complete sulla configurazione di logrotate.

Passaggio 6: Eliminare i file temporanei

Livello di rischio: MEDIO - Le sessioni PHP e le cache delle applicazioni influiscono sugli utenti attivi. Eseguire un'anteprima prima di procedere all'eliminazione.

6.1 Pulizia di /tmp

Nella maggior parte delle distribuzioni, la directory /tmp viene svuotata al riavvio. Se il server è in esecuzione da mesi, potrebbe aver accumulato file temporanei di grandi dimensioni:

du -sh /tmp

Per rimuovere i file più vecchi di 7 giorni, visualizza prima l’anteprima:

sudo find /tmp -type f -mtime +7

Se l’elenco sembra sicuro, eseguire l’eliminazione:

sudo find /tmp -type f -mtime +7 -delete

6.2 Pulizia delle cache delle applicazioni

Molte applicazioni creano le proprie cache. Controlla queste posizioni comuni (nota: verifica che queste directory esistano sul tuo sistema; su un sistema pulito potrebbero non essere presenti e potresti ricevere un errore del tipo «File o directory inesistente»):

# PHP session files (often forgotten, if installed)
sudo du -sh /var/lib/php/sessions/

# Pip / Python package caches (if running as root and installed)
sudo du -sh /root/.cache/pip/

# npm cache (if node is installed system-wide)
sudo du -sh /root/.npm/

Queste directory possono essere eliminate in tutta sicurezza se l’applicazione non le sta utilizzando attivamente.

Passaggio 7: Verificare che i servizi siano ancora in esecuzione

Livello di rischio: BASSO - Verifica in sola lettura. Eseguite questa operazione dopo ogni passaggio, non solo alla fine.

Dopo ogni ciclo di pulizia, verifica che i servizi siano ancora attivi. Esegui questa operazione prima di chiudere la sessione SSH.

7.1 Verifica dello stato dei servizi critici

Controlla solo i servizi effettivamente installati sul tuo server (su un sistema pulito, controllando nginx o mysql verrà restituito il messaggio " Unità non trovata").

Ubuntu / Debian:

systemctl status nginx
systemctl status mysql
systemctl status ssh

AlmaLinux / RHEL:

systemctl status nginx
systemctl status mysqld
systemctl status sshd

Ciascuno dovrebbe mostrare " Active: active (running)". Se uno qualsiasi risulta "failed" o "inactive", controlla i relativi log:

journalctl -u nginx --since "10 minutes ago"

7.2 Verifica il miglioramento dell’utilizzo del disco

df -h

Confronta la colonna "Use%" con i dati osservati nel Passo 1. La variazione dovrebbe riflettere lo spazio che hai liberato.

7.3 Testare l'applicazione

Se si gestisce un server web, inviare una richiesta di prova:

curl -I http://localhost

Risultato atteso:

HTTP/1.1 200 OK
Server: nginx/1.24.0

Un codice di stato 200 OK conferma che nginx sta gestendo il traffico normalmente.

Risoluzione dei problemi

`df` non mostra alcun miglioramento dopo la rimozione dei pacchetti

La rimozione dei pacchetti libera immediatamente spazio. Se ` df ` non cambia, significa che i file sono ancora aperti. Individua i file aperti ma eliminati:

sudo lsof | grep deleted

Riavviare il servizio che mantiene il file aperto e lo spazio verrà recuperato.

`apt autoremove` vuole rimuovere qualcosa che sembra importante

Leggi attentamente l'elenco. Se vedi il nome di un pacchetto che riconosci come dipendenza di un servizio in esecuzione, premi N e verifica. Esegui ` apt-cache rdepends <pacchetto> ` per vedere cosa dipende da esso.

`journalctl --vacuum-time` non produce alcun cambiamento

Il journal potrebbe essere già più piccolo della dimensione target. Verifica con `journalctl --disk-usage`. Assicurati inoltre che il journal sia persistente: controlla che esista `/var/log/journal/`. Se esiste solo `/run/log/journal/`, il journal è memorizzato nella RAM e viene cancellato automaticamente al riavvio.

Il servizio non funziona dopo `apt autoremove`

Esegui `systemctl status <servizio> ` e controlla l'errore. Se è stata rimossa una libreria condivisa, reinstalla il pacchetto che la fornisce:

sudo apt install --fix-broken

Esaurimento degli inode nonostante lo spazio libero su disco

Individuare la directory con il maggior numero di file:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Cause comuni: code di posta in /var/spool/mail, sessioni PHP in /var/lib/php/sessions o un processo cron fuori controllo che crea file temporanei.

Rollback

La maggior parte delle operazioni di pulizia non è reversibile: i file eliminati sono persi. Questo rende la fase di backup descritta nei Prerequisiti imprescindibile.

Per la rimozione dei pacchetti in particolare, è possibile reinstallare ciò che è stato rimosso:

Ubuntu / Debian:

sudo apt install <package-name>

AlmaLinux / RHEL:

sudo dnf install <package-name>

Per visualizzare la cronologia di ciò che è stato rimosso nella sessione corrente:

Ubuntu / Debian:

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL:

sudo dnf history list
sudo dnf history undo last

Il comando `dnf history undo last ` reinstalla i pacchetti rimossi nell'operazione più recente: uno strumento di ripristino utile se la funzione di rimozione automatica è andata oltre il previsto.

Conclusione

La pulizia di un server Linux senza tempi di inattività si basa su tre principi: misurare prima, rimuovere solo ciò che il sistema conferma essere inutilizzato e verificare i servizi dopo ogni passaggio. Eseguire `df -h ` e `du` prima di intervenire. Utilizzate apt autoremove / yum autoremove per i pacchetti inutilizzati, journalctl --vacuum-time per la pulizia dei log di journal e find /var/log -name "*.gz" per i vecchi archivi ruotati. Rimuovete i vecchi kernel solo dopo aver verificato che uname -r corrisponda a quello che intendete mantenere. E controllate sempre systemctl status prima di chiudere il terminale.

Per un VPS INTROSERV, mantenere l’utilizzo di / al di sotto dell’80% è un obiettivo pratico: lascia spazio per picchi di log e aggiornamenti dei pacchetti senza interventi di emergenza. Se lo spazio su disco è un problema ricorrente, valuta di ridimensionare lo spazio di archiviazione del tuo VPS direttamente dall’Area Clienti INTROSERV.

Versione del documento: 1.0
Ultimo aggiornamento: maggio 2026
Responsabile: Team di documentazione tecnica