Gli aggiornamenti sono il momento in cui un homelab stabile diventa instabile. Rimandarli all'infinito, però, è peggio: si accumulano vulnerabilità e, quando finalmente si aggiorna, il salto tra versioni è così grande che i problemi si moltiplicano. Serve un metodo che renda gli aggiornamenti frequenti, prevedibili e reversibili.
I livelli da aggiornare
Un homelab ha più strati, ciascuno con il proprio ritmo:
| Livello | Esempi | Frequenza indicativa |
|---|---|---|
| Firmware | BIOS, BMC, firmware di dischi e schede di rete | quando esce una correzione rilevante |
| Hypervisor | Proxmox VE, XCP-ng | aggiornamenti minori regolari, versioni maggiori pianificate |
| Sistemi operativi delle VM | Debian, Ubuntu, altre distribuzioni | settimanale o automatico per la sicurezza |
| Container e applicazioni | immagini Docker, servizi | secondo l'importanza del servizio |
| Dispositivi di rete | router, switch, access point | quando esce una correzione di sicurezza |
Trattarli separatamente evita di cambiare troppe cose insieme: se qualcosa smette di funzionare, si sa dove cercare.
Prima di aggiornare
Leggere le note di rilascio
Per le versioni maggiori è il passo più importante. Le note di rilascio indicano cambiamenti incompatibili, componenti rimossi, procedure di migrazione. Proxmox, per esempio, pubblica per ogni versione maggiore una guida di aggiornamento con uno script di controllo preliminare che segnala i problemi noti prima di iniziare.
Avere un modo per tornare indietro
- Snapshot delle VM prima di aggiornarne il sistema o le applicazioni: il ritorno allo stato precedente richiede pochi secondi.
- Backup recente e verificato per ciò che non si può sottoporre a snapshot, come l'host stesso.
- Versione precedente delle immagini dei container: fissare il tag della versione nel file Compose permette di tornare indietro cambiando una riga.
- Configurazione salvata dei dispositivi di rete prima di un aggiornamento del firmware.
Gli snapshot non vanno lasciati per settimane: occupano spazio crescente e, su alcuni tipi di storage, rallentano il disco. Si eliminano quando l'aggiornamento è confermato.
L'ordine conta
Una sequenza che funziona bene:
- servizi meno importanti per primi: un aggiornamento problematico emerge su una VM di prova o poco usata;
- poi i servizi principali, uno alla volta, verificando ciascuno;
- l'hypervisor per ultimo, quando tutto il resto è stabile;
- il firmware separatamente, in un momento dedicato, perché richiede riavvii e talvolta reset delle impostazioni.
In un cluster si aggiorna un nodo alla volta: si spostano le VM su un altro nodo, si aggiorna, si riavvia, si verifica, si passa al successivo. Il quorum va tenuto d'occhio per tutto il tempo.
Una finestra di manutenzione anche in casa
Aggiornare il server di casa la sera prima di una videochiamata importante è un rischio inutile. Conviene scegliere un momento fisso, con tempo per rimediare: un sabato mattina, per esempio. Se in casa altre persone usano i servizi, avvisarle evita sorprese.
Nel mio lavoro tengo una breve lista di controllo per ogni sessione:
- backup e snapshot fatti;
- note di rilascio lette per tutto ciò che cambia versione maggiore;
- accesso di emergenza disponibile, come la console fuori banda o un monitor e una tastiera;
- aggiornamento e riavvio;
- verifica dei servizi;
- eliminazione degli snapshot e annotazione nel registro delle modifiche.
Verificare dopo l'aggiornamento
«Il comando è terminato senza errori» non significa «funziona». Le verifiche minime:
- i servizi rispondono, controllati dal sistema di monitoraggio o a mano;
- i log non mostrano errori nuovi dopo il riavvio;
- i job pianificati, come backup e scrub, partono alla prossima esecuzione;
- l'accesso da remoto, per esempio tramite VPN, funziona ancora.
Molti problemi emergono solo al primo riavvio successivo: un kernel nuovo che non carica un modulo, una scheda di rete che cambia nome. Conviene riavviare subito dopo l'aggiornamento, quando si è presenti, invece di scoprirlo al prossimo blackout.
Automatizzare con giudizio
Gli aggiornamenti di sicurezza dei sistemi operativi delle VM si possono automatizzare con strumenti come unattended-upgrades su Debian e Ubuntu: il rischio è basso e il beneficio alto. Per gli aggiornamenti automatici delle immagini dei container, invece, la regola è distinguere:
- servizi senza stato o facilmente ricreabili: aggiornamento automatico accettabile;
- servizi con database o dati importanti: aggiornamento manuale, con snapshot e lettura delle note.
L'hypervisor e il firmware non vanno aggiornati in automatico: richiedono riavvii e attenzione.
Quando qualcosa va storto
- non insistere con altri comandi a caso: si rischia di peggiorare la situazione;
- tornare allo snapshot o alla versione precedente;
- leggere i log per capire la causa;
- cercare nelle note di rilascio e nei forum ufficiali del progetto se il problema è noto;
- riprovare solo dopo aver capito cosa è successo.
In sintesi
- Aggiornare spesso e a piccoli passi è più sicuro che rimandare.
- Note di rilascio lette, snapshot e backup prima di ogni versione maggiore.
- Ordine consigliato: servizi secondari, servizi principali, hypervisor, firmware a parte.
- Dopo l'aggiornamento si riavvia e si verificano servizi, log, job e accesso remoto.
- Automatizzare la sicurezza dei sistemi, non i salti di versione delle applicazioni con dati.
