Checklist per la manutenzione di un server Linux

Che cosa significa realmente la manutenzione di un server Linux

La manutenzione di un server Linux consiste in un breve elenco di controlli eseguiti secondo una pianificazione fissa, non in un progetto senza termine. Ogni settimana verificate che gli aggiornamenti siano stati installati, che il disco disponga di spazio sufficiente, che nessun servizio si sia arrestato e che il processo di backup sia terminato correttamente. Ogni mese testate un ripristino, controllate la scadenza dei certificati, verificate account e chiavi e rimuovete i kernel e i log obsoleti. Una volta per ogni release della distribuzione, pianificate l'aggiornamento di versione ed eseguite il riavvio che continuate a rimandare.

La configurazione del server è un'attività diversa e i primi dieci minuti su un nuovo VPS tratta questo argomento. Questa pagina riguarda l'anno successivo. Ogni voce seguente indica il guasto che previene, perché un elenco di controllo privo di conseguenze è un elenco che le persone smettono gradualmente di eseguire.

I comandi riportati sono esempi e devono essere letti prima di essere eseguiti. Confrontate il relativo output con quello del vostro server, perché un valore normale per lo spazio libero o per il numero di processi dipende dal ruolo del sistema. Quando un controllo varia tra le distribuzioni, il testo lo specifica. Gli esempi utilizzano Debian e Ubuntu con apt. Nella famiglia RHEL lo strumento è dnf e diversi percorsi sono differenti.

Come scegliere una cadenza di manutenzione dei server Linux che riuscirai a rispettare

I controlli settimanali riguardano gli elementi che cambiano senza interventi manuali: pacchetti, spazio su disco, stato dei servizi e attività pianificate. Questi elementi cambiano autonomamente, quindi una settimana è circa il periodo massimo per cui puoi rimandarne la verifica.

I controlli mensili riguardano il deterioramento graduale: certificati prossimi alla scadenza, account che nessuno ha eliminato, kernel che si accumulano in /boot e file di log che superano una regola di rotazione non più applicata correttamente. Nessuno di questi problemi causa necessariamente un guasto domani. Prima o poi, però, tutti possono causare un guasto.

I controlli delle release dipendono dal calendario. Una release della distribuzione è l'unico elemento di manutenzione con una scadenza esterna, perché il supporto per la versione corrente termina anche se non sei pronto.

Pianifica l'attività in una fascia oraria fissa: il lunedì mattina per il controllo settimanale e il primo giorno del mese per quello mensile. Un controllo eseguito "quando ne hai il tempo" non è una checklist. Quando gestisci più di pochi computer, esegui queste attività da un unico punto invece di procedere manualmente; questo è l'argomento di gestire più server Linux da un unico punto.

Settimanale: gli aggiornamenti sono stati effettivamente installati?

Abilitare unattended-upgrades non equivale a sapere che sia stato eseguito. Il servizio può essere mascherato, la configurazione può essere limitata a un’origine che non utilizzi e un singolo pacchetto bloccato può interrompere ogni esecuzione successiva. L’installazione è descritta in aggiornamenti di sicurezza automatici su Ubuntu. Il controllo settimanale serve a verificare che ciò che hai installato abbia svolto il proprio lavoro.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable è la misura più affidabile, perché riporta lo stato attuale anziché l’intenzione. Se gli aggiornamenti di sicurezza sono ancora presenti in quell’elenco, l’automazione non sta funzionando. Leggi quindi il log prima di presumere che la macchina sia aggiornata. Un pacchetto bloccato con apt-mark hold viene ignorato indefinitamente e non produce alcun report. Per questo apt-mark showhold deve rientrare nello stesso controllo.

Il problema che questo controllo previene è usare per mesi un pacchetto noto come vulnerabile, credendo che gli aggiornamenti fossero automatici.

Settimanale: margine disponibile su disco e inode

Un filesystem root pieno interrompe attività che sembrano non avere a che fare con il disco. Il database rifiuta le scritture, il logging si interrompe, un aggiornamento dei pacchetti termina con una configurazione incompleta e, in alcuni ambienti, non è possibile aprire una nuova sessione perché il sistema non riesce a scrivere i propri file.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i è la metà dei controlli che molti saltano. Gli inode sono strutture in numero fisso che contengono i metadati dei file. Un filesystem può esaurire gli inode mentre df -h indica ancora gigabyte liberi. In questo caso le scritture falliscono con No space left on device, accanto a un output che mostra spazio disponibile. La prima volta, il problema può richiedere un'ora di troubleshooting. La causa abituale è la presenza di milioni di file piccoli, ad esempio una coda di posta bloccata o una directory delle sessioni che nessuno pulisce.

du -xh resta su un singolo filesystem, come desiderato su un host con bind mount o storage collegato. Su un host Docker, la causa è solitamente negli image layer e nei volumi non più utilizzati. È possibile rimuoverli come descritto in rimozione dell'utilizzo del disco Docker su un VPS.

Lo spazio libero indica la capacità disponibile. Lo storage sottostante può guastarsi secondo tempistiche proprie. Per questo è necessario un controllo separato, descritto in monitoraggio dello stato del disco su un VPS.

Settimanale: quali servizi si sono arrestati senza avvisarti?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Un'unità che si è arrestata in modo anomalo e ha raggiunto il limite di riavvii resta nello stato failed e rimane lì, senza segnalazioni. Nessuna e-mail ti informa del problema. list-timers è la parte più utile: mostra l'ultima esecuzione di ogni timer e il momento della prossima, quindi un valore LAST più vecchio dell'intervallo del timer indica che il relativo job non è stato eseguito affatto.

Leggi il journal dell'unità prima di riavviarla, usando journalctl -u <unit> -n 100 --no-pager. Un riavvio elimina il sintomo e, a quel punto, non avrai motivo di controllare di nuovo il problema fino a quando non si ripresenterà in un momento peggiore.

Il problema che questa verifica consente di prevenire: un agente di monitoraggio, un worker per le code o un servizio di backup rimasto inattivo per tre settimane dopo un picco di utilizzo della memoria.

Settimanale: il processo di backup è terminato correttamente?

Un backup pianificato e un backup completato sono fatti diversi. Solo il secondo può essere usato per un ripristino. Verifica il completamento.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Verifica due elementi. L’ultima esecuzione deve terminare con codice 0 e l’archivio più recente deve essere aggiornato e avere dimensioni approssimativamente in linea con quelle previste. Un file di backup che all’improvviso ha un decimo delle dimensioni abituali indica un dump non riuscito che ha comunque creato un file. È la forma più rischiosa di errore del backup, perché tutto ciò che viene eseguito dopo sembra normale.

Se lo script passa un dump a un compressore tramite una pipe, aggiungi set -o pipefail all’inizio. In sua assenza, il codice di uscita della pipeline è quello del compressore, che termina correttamente: ha compresso il messaggio di errore. Il processo quindi segnala il successo ogni notte, creando un archivio piccolo e privo di dati.

Mensile: ripristinare un backup in un'altra posizione

Questo è il punto che la maggior parte delle persone salta, ma determina se il resto dell'elenco è servito a qualcosa.

Ripristina il backup su un'altra macchina o in un container nuovo, mai sui dati in uso. Poi apri ciò che hai ripristinato e verifica che sia integro. Conta le righe di una tabella. Apri un documento. Accedi all'applicazione ripristinata. Il completamento dell'estrazione dimostra che l'archivio è leggibile, ma non dimostra altro.

Gli strumenti dei repository hanno procedure di verifica proprie: restic check --read-data-subset=5% e borg check --verify-data leggono i dati archiviati, non solo l'indice. Eseguili e considerali un test preliminare, non un sostituto del ripristino. La verifica controlla che i byte siano sopravvissuti. Un ripristino controlla che i byte siano quelli necessari all'applicazione.

Ci sono due dettagli che molte persone imparano a proprie spese. Verifica la passphrase di decrittazione su una macchina che non contiene già la chiave in un agent, perché un backup che non puoi decrittare non è un backup. Inoltre, misura la durata del ripristino: quel valore rappresenta il tuo effettivo tempo di recupero, e il momento più comune per scoprirlo è durante un'interruzione del servizio.

Mensile: quali certificati scadranno a breve?

L'automazione dei rinnovi può fallire senza produrre messaggi evidenti. Il timer di certbot può rinnovare il file sul disco mentre il server Web continua a usare il vecchio certificato in memoria, perché l'hook di deploy che ricarica il servizio non è stato eseguito. Per questo è necessario verificare da un sistema esterno quale certificato sta effettivamente servendo il server in esecuzione.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Il flag -servername imposta SNI (server name indication), necessario su qualsiasi indirizzo che ospita più siti. In caso contrario viene restituito il certificato predefinito anziché quello del sito richiesto. Se certbot è stato installato tramite snap, il timer ha un nome diverso. Cercate quindi la parola invece di usare un'unità il cui nome è stato dato per scontato.

Considerate anche i certificati per i quali non è configurata alcuna automazione: quelli di un server di posta, di una VPN o di un'autorità di certificazione interna. Sono i certificati che scadono durante il fine settimana; browser e client li rifiutano direttamente, invece di mostrare un avviso.

Mensile: utenti, accesso sudo e chiavi SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T stampa la configurazione effettiva dopo aver unito tutti i file Include, cioè la configurazione che il demone utilizzerà realmente. Le immagini Ubuntu recenti includono file di override in /etc/ssh/sshd_config.d/, che possono sovrascrivere il file principale. Per questo, leggere soltanto sshd_config può restituire informazioni opposte alla configurazione effettiva. Nella famiglia RHEL, il gruppo amministrativo è wheel anziché sudo. Modificate quindi la riga getent.

Leggete poi direttamente i file authorized_keys. L'accesso viene concesso tramite chiave, non tramite account. Una chiave lasciata da un collaboratore che ha terminato il rapporto sei mesi fa consente ancora l'accesso e non viene rilevata da alcun elenco di utenti. Le chiavi includono un campo commento. Usatelo e rimuovete ogni chiave che non riuscite ad attribuire a una persona.

Per la cronologia degli accessi, journalctl -t sshd --since "30 days ago" | grep -i accepted cerca l'identificatore syslog anziché il nome di un'unità. Questo è importante perché Ubuntu 24.04 attiva SSH tramite un socket. Di conseguenza, ogni connessione viene registrata in un'unità generata specifica per quella connessione, e un semplice journalctl -u ssh può non rilevarla.

Mensile: kernel obsoleti e una partizione /boot piena

/boot è spesso una partizione separata di poche centinaia di megabyte nelle immagini standard dei VPS. Ogni aggiornamento del kernel aggiunge un'immagine e un initramfs. Quando si riempie, l'aggiornamento successivo non va a buon fine e lascia i pacchetti non configurati. È una situazione che non dovrebbe presentarsi all'improvviso di venerdì.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r prima di tutto: indica il kernel in esecuzione e quello deve rimanere disponibile, indipendentemente da ciò che si rimuove. apt autoremove gestisce il caso normale su Debian e Ubuntu, perché i kernel sono contrassegnati come installati automaticamente e quello corrente è protetto. I casi particolari, come un kernel installato manualmente o un /boot già abbastanza pieno da impedire il funzionamento di apt, sono descritti in rimozione dei kernel obsoleti su Ubuntu.

Mensile: crescita dei log e journal di systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug esegue una simulazione e non scrive nulla, quindi è sicuro anche su un sistema in produzione. Conviene eseguirlo perché le regole di rotazione corrispondono ai percorsi: se un'applicazione cambia la posizione del log durante un aggiornamento, il file non è più gestito dalla regola prevista e continua a crescere senza limiti finché il disco non si riempie.

systemd limita le dimensioni del journal, ma in base a una frazione del filesystem e non a un valore scelto dall'utente. Impostare SystemMaxUse= in /etc/systemd/journald.conf e riavviare systemd-journald se si desidera un limite massimo specifico. sudo journalctl --vacuum-time=14d recupera immediatamente spazio, ma agisce una sola volta e non definisce una policy; eseguirlo quindi insieme alla modifica della configurazione.

Per release: il riavvio che continui a rimandare

Un pacchetto del kernel aggiornato presente sul disco non significa che sia in esecuzione un kernel aggiornato. Fino al riavvio, la macchina continua a usare quello precedente. Il live patching, quando disponibile, copre solo una parte delle correzioni.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Quel file indicatore è una convenzione Debian e Ubuntu, creato dagli script dei pacchetti. I sistemi della famiglia RHEL non lo creano. In questi sistemi, la stessa verifica si esegue tramite needs-restarting -r, fornito da dnf-utils. needrestart, installato per impostazione predefinita nelle immagini recenti di Ubuntu Server, verifica il livello inferiore al kernel: elenca i processi che mappano ancora una libreria sostituita sul disco. Per questo motivo, una versione corretta di OpenSSL non diventa effettiva finché non vengono riavviati i servizi che la utilizzano.

Pianifica il riavvio invece di evitarlo. In /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; e Unattended-Upgrade::Automatic-Reboot-Time "03:00"; puoi affidare la decisione all'orario che hai scelto. Un riavvio pianificato è anche l'unico modo per verificare che il server torni operativo: una voce fstab non valida o un servizio che non hai mai abilitato si manifesta all'avvio e in nessun altro momento.

Pianificazione dell'aggiornamento della distribuzione

Le release Ubuntu LTS ricevono cinque anni di supporto standard, mentre le release intermedie ricevono nove mesi. Questa scelta determina il lavoro di aggiornamento per gli anni successivi. Il compromesso è descritto in release LTS e intermedie su un server.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade legge quel file e Prompt=lts limita l'operazione agli aggiornamenti da una release LTS alla successiva release LTS. Il percorso tra release LTS normalmente diventa disponibile con la prima point release della nuova versione, non il giorno del rilascio. Verifica quindi quale versione viene proposta alla macchina, invece di pianificare sulla base di una data presunta. La procedura dell'aggiornamento è descritta in aggiornare Ubuntu 24.04 a 26.04.

Pianifica un margine di tre mesi. Crea uno snapshot e verifica di poterlo ripristinare. Elenca i repository apt di terze parti: l'aggiornamento li disabilita e per ciascuno devi configurare una nuova destinazione compatibile con la nuova release. Definisci la procedura di rollback prima di iniziare. Ad agosto 2026, Ubuntu 24.04 LTS ha supporto standard fino ad aprile 2029. Si tratta quindi di un'attività da pianificare, non di un'emergenza.

Cosa automatizzare e cosa mantenere manuale

Automatizza le decisioni che hai già preso: aggiornamenti di sicurezza, rotazione dei log, rinnovo dei certificati e processi di backup. Automatizza anche gli avvisi, perché un controllo che dipende dal fatto che tu te ne ricordi è un controllo che alle 2am non verrà eseguito. Un monitor esterno, come monitoraggio dello stato self-hosted con Uptime Kuma, rileva l'unico problema che nessuno script eseguito sul server può segnalare: l'irraggiungibilità del server.

Mantieni manuali due attività: il test di ripristino e l'audit degli account. In entrambi i casi, una persona deve stabilire se il risultato è corretto. Se preferisci leggere lo stato del sistema in un browser invece che in un terminale, Cockpit e Webmin per la gestione dei server confronta le due console web più comuni.

L'automazione richiede quindi a sua volta un controllo. Per questo, il primo elemento settimanale dell'elenco consiste nel verificare l'updater. Un'automazione che fallisce senza produrre avvisi è peggiore della sua assenza, perché elimina contemporaneamente il guasto e l'abitudine di controllare.

L'intera checklist in un unico punto

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Con quale frequenza devo eseguire la manutenzione di un server Linux?

Ogni settimana per tutto ciò che cambia autonomamente: stato degli aggiornamenti, spazio disponibile su disco e inode, unità in errore e completamento del job di backup. Ogni mese per i problemi che si accumulano lentamente: un test di ripristino, la scadenza dei certificati, la verifica degli account e delle chiavi SSH, i kernel precedenti e la crescita dei log. A ogni rilascio della distribuzione per l'aggiornamento di versione e il riavvio con il kernel corrente. Il controllo settimanale richiede pochi minuti su un server in condizioni normali. Questo è il motivo per cui va eseguito ogni settimana, invece di aspettare che qualcosa non funzioni.

Perché devo testare un ripristino se il job di backup segnala il completamento corretto?

Perché il job segnala il proprio codice di uscita, che può essere corretto anche quando l'archivio è inutilizzabile. Un dump passato a un compressore senza set -o pipefail restituisce il codice del compressore. Di conseguenza, un dump non riuscito che ha prodotto soltanto un messaggio di errore termina comunque con codice zero e scrive un file di piccole dimensioni. Esegui il ripristino su un'altra macchina, apri i dati e conta qualche elemento. Il test misura anche la propria durata. Questa durata rappresenta il tempo effettivo di ripristino.

Devo riavviare il sistema dopo ogni aggiornamento del kernel?

Devi riavviare il sistema prima che il nuovo kernel diventi quello in esecuzione. Su Debian e Ubuntu, la presenza di /var/run/reboot-required indica che un pacchetto ha richiesto il riavvio, mentre /var/run/reboot-required.pkgs indica quale pacchetto lo ha richiesto. Nella famiglia RHEL quel file non esiste. Il comando needs-restarting -r di dnf-utils risponde alla stessa domanda. Imposta una finestra di riavvio automatico in /etc/apt/apt.conf.d/50unattended-upgrades invece di rimandare il riavvio indefinitamente. Una macchina che non è stata riavviata per un anno ha infatti un percorso di avvio non verificato, oltre a un kernel obsoleto.

Quali di questi controlli posso automatizzare in sicurezza?

Automatizza le attività la cui decisione è già definita: aggiornamenti di sicurezza, rotazione dei log, rinnovo dei certificati e backup pianificati. Automatizza anche le notifiche, così un'unità in errore o un disco quasi pieno ti viene segnalato senza che una persona debba eseguire un comando. Mantieni manuali il test di ripristino e la verifica delle chiavi, perché entrambi richiedono una persona che valuti se il risultato è corretto. Aggiungi quindi un controllo sull'automazione stessa, perché un aggiornamento automatico che non funziona senza produrre errori appare esattamente come un sistema operativo correttamente aggiornato.