Guida all'Aggiornamento da Debian 12 Bookworm a Debian 13 Trixie

Il tuo server, che sia un dedicato Hetzner, un VPS OVH o una macchina in un datacenter italiano, è il motore silenzioso della tua attività. Giorno dopo giorno, Debian 12 "Bookworm" ha servito le tue applicazioni con la stabilità che ha reso questa distribuzione una scelta di default per chi vuole un sistema operativo che non sorprende. Ma il ciclo di vita di una release Debian non è eterno, e per chi gestisce infrastruttura in produzione le date contano: ignorarle significa accorgersi del problema quando una vulnerabilità non viene più chiusa, non prima. Il passaggio a Debian 13 "Trixie" non è un semplice aggiornamento di pacchetti: è un salto generazionale che porta un kernel 6.12 LTS, nuove versioni di PHP, Python, Nginx e migliaia di altri componenti, oltre a un periodo di supporto fresco che ti compra anni di tranquillità.

Partiamo dai fatti, perché su questo tema circolano date imprecise. Debian 12 è stato rilasciato il 10 giugno 2023. Il supporto di sicurezza ordinario, quello gestito dal Debian Security Team, è terminato il 10 giugno 2026: da quella data Bookworm è passato sotto la responsabilità del progetto Debian LTS, che ne estende la copertura, con cadenza di patch più lenta e perimetro di pacchetti ridotto, fino al 30 giugno 2028 (fonte: Debian Wiki LTS). Questo è il punto che molti sbagliano: il LTS di Bookworm non scade nel 2026, dura due anni in più. Ma "essere in LTS" non è uno stato in cui si vuole vivere a lungo su un sistema esposto, perché non tutti i pacchetti restano coperti e la velocità di reazione cambia.

Essere in LTS non è un porto sicuro, è una sala d'attesa. La copertura c'è, ma più lenta e più stretta: è il momento giusto per pianificare l'upgrade, non per rimandarlo di un altro anno.

Sull'altro versante, Debian 13 "Trixie" è stato rilasciato il 9 agosto 2025 (fonte: Debian Releases). Il supporto di sicurezza ordinario è garantito fino al 9 agosto 2028, seguito dalla fase LTS fino al 30 giugno 2030. Tradotto: spostarti su Trixie oggi significa comprare circa tre anni di patch piene prima ancora di pensare al LTS. Al momento in cui scrivo la distribuzione è arrivata al point release 13.5 (16 maggio 2026), quindi non stai aggiornando a una .0 appena nata, ma a una release che ha già diverse iterazioni di stabilizzazione alle spalle.

L'idea di eseguire un full-upgrade su un sistema di produzione genera, comprensibilmente, una certa ansia. Cosa succede se un servizio non riparte? Se una configurazione personalizzata smette di funzionare? La tentazione di restare sulla versione "vecchia ma sicura" è forte, ma è una strategia che a lungo termine accumula debito tecnico e, soprattutto, espone il sistema a vulnerabilità che a un certo punto nessuno chiuderà più. In oltre vent'anni a gestire infrastrutture Linux ho sviluppato un approccio metodico che trasforma l'aggiornamento del sistema operativo da salto nel buio in un processo controllato e prevedibile. Questa guida non è una lista di comandi da copiare e incollare: è la procedura operativa che applico quando porto un parco di server da una major all'altra senza fermare il business.

Stai cercando un Consulente Informatico esperto per gestire l'infrastruttura della tua azienda senza affidarti all'improvvisazione? Nel mio profilo professionale trovi l'esperienza concreta su server dedicati Hetzner e OVH, hardening Linux, migrazioni di sistema operativo e recupero di infrastrutture mal gestite.

Conviene davvero aggiornare a Debian 13 ora, o è più prudente restare su Bookworm in LTS?

Conviene aggiornare ora, in una finestra pianificata, ed è la scelta più prudente proprio per chi gestisce produzione. Debian 12 è in fase LTS dal 10 giugno 2026: la copertura di sicurezza c'è ancora, fino al 30 giugno 2028, ma è più lenta e non riguarda tutti i pacchetti. Restare su Bookworm fino all'ultimo significa trovarsi a fare l'upgrade sotto pressione, magari di fronte a una CVE che il LTS non copre, invece che in una finestra di manutenzione scelta da te. La differenza non è tecnica, è di controllo: chi pianifica decide quando e in quali condizioni eseguire l'operazione; chi rimanda subisce la scadenza.

La logica è la stessa che applico al resto dello stack. Quando un componente entra in supporto ridotto, la domanda non è "funziona ancora?", ma "per quanto tempo qualcuno chiuderà i buchi che si apriranno?". Su un kernel, su OpenSSL, su un web server esposto, questa distinzione è la linea tra un'infrastruttura mantenuta e una che sta accumulando rischio in silenzio. Trixie ti riporta in piena copertura ordinaria fino al 2028 e ti dà un kernel 6.12 LTS con supporto hardware più ampio: per chi gira su VPS o dedicati recenti, è anche un guadagno di compatibilità, non solo di sicurezza.

La pianificazione: il 90% del successo di un aggiornamento

Un aggiornamento di sistema riuscito non si basa sulla fortuna, ma su una preparazione meticolosa. Prima di digitare il primo comando, è fondamentale eseguire una serie di controlli preliminari per assicurarsi che il terreno sia pronto. Salto questa fase solo chi non ha mai dovuto ripristinare un server alle tre di notte.

1. Backup completo e snapshot

Questo punto non è negoziabile. Prima di qualsiasi modifica devi avere un piano di ripristino testato, non solo un backup che speri funzioni. Se il tuo provider lo consente, come fanno Hetzner e OVH dalla console, crea uno snapshot completo del server: è un'operazione di pochi minuti e rappresenta la tua rete di sicurezza definitiva. Se qualcosa va catastroficamente storto a metà upgrade, ripristini lo stato esatto della macchina e riparti. Oltre allo snapshot dell'intero disco, un backup applicativo (database, file caricati dagli utenti, configurazioni) resta sempre la prima cosa da mettere al sicuro.

# Dump di un database MySQL/MariaDB in modo consistente, senza lock prolungati
mysqldump --single-transaction --quick -u utente -p nome_database > /percorso/backup.sql

# Tarball compresso di una directory applicativa
tar -czvf /percorso/backup/app.tar.gz /var/www/app

# Copia del backup su un host remoto (previa configurazione di ~/.ssh/config)
scp /percorso/backup/app.tar.gz utente@host-remoto:/percorso/destinazione

Una nota dall'esperienza: un backup che vive sullo stesso disco del server non è un backup, è un'illusione. Per un major upgrade, lo snapshot del provider è il tuo paracadute immediato; il backup offsite, su un host o uno storage separato, è quello che ti salva se il paracadute non si apre.

2. Controllo dello spazio su disco

Un aggiornamento di versione scaricherà centinaia di nuovi pacchetti. Assicurati di avere spazio a sufficienza prima di iniziare, perché un full-upgrade che si ferma a metà per disco pieno è uno degli scenari più sgradevoli da gestire.

df -h

Una buona regola è avere almeno 5 GB liberi sulla partizione di root (/). Se lo spazio è risicato, recuperane con la pulizia di apt:

sudo apt clean
sudo apt autoremove

Puoi liberare ulteriore spazio ripulendo i log vecchi, ma con attenzione: non rimuovere log che potrebbero servire a un'indagine post-incidente. Per eliminare i .log più vecchi di 30 giorni:

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

Se il problema dello spazio è cronico e il server ha poca RAM, vale la pena rivedere anche la configurazione di memoria prima di iniziare: un upgrade su una macchina che va in OOM durante la ricompilazione delle configurazioni è un altro modo classico per rovinarsi la serata.

3. Aggiornamento completo del sistema attuale

L'upgrade a Debian 13 Trixie è supportato ufficialmente solo partendo da un Bookworm completamente aggiornato. Esegui quindi un ultimo ciclo di update sulla versione corrente:

sudo apt update && sudo apt full-upgrade

Se questo comando installa un nuovo kernel, è fondamentale riavviare il sistema per assicurarti che stia girando con la versione più recente prima di procedere con il salto di major. Per capire se il kernel è stato aggiornato, guarda l'output di apt: vedrai righe relative ai pacchetti linux-image-amd64 e linux-headers-amd64, con la versione specifica del kernel installato.

sudo reboot

Riavviare prima dell'upgrade vero e proprio non è pedanteria: aggiornare i repository a Trixie mentre il sistema gira ancora su un kernel Bookworm non riavviato è uno dei modi più sottili per incappare in incoerenze difficili da diagnosticare.

4. Identificazione dei repository di terze parti

I repository ufficiali di Debian verranno aggiornati automaticamente quando cambierai il nome della release, ma cosa succede con quelli che hai aggiunto tu (Docker, Node.js, PHP da Sury, MariaDB upstream e simili)? Di norma i repository aggiuntivi vivono in /etc/apt/sources.list.d: è lì che devi guardare per identificarli.

ls -la /etc/apt/sources.list.d

Per ognuno dei repository di terze parti devi verificare che esista già una versione compatibile con Trixie prima di procedere. Se un repository non offre ancora pacchetti per Trixie, l'upgrade può rompersi o, peggio, tenere il sistema in uno stato misto e instabile. In quel caso la procedura corretta è disabilitarlo temporaneamente prima dell'upgrade e ripristinarlo dopo, quando l'upstream avrà pubblicato i pacchetti per la nuova release. Aggiornare con un repository di terze parti puntato alla release sbagliata è una delle cause più frequenti di upgrade fallito che mi capita di dover ricostruire.

L'esecuzione: passo dopo passo verso Debian 13

Con la preparazione completata, possiamo iniziare il processo di aggiornamento vero e proprio. Per evitare che una disconnessione di rete interrompa l'operazione a metà (e ti lasci con un sistema in stato indeterminato), è caldamente consigliato eseguire l'intera procedura dentro una sessione screen o tmux. Se la connessione SSH cade, la sessione continua a girare sul server e tu ti riattacchi.

# Installa screen se assente e avvia una nuova sessione persistente
sudo apt install -y screen && screen

1. Modifica delle fonti software

Il cuore dell'operazione consiste nel dire ad apt di guardare ai repository di Trixie invece che a quelli di Bookworm. La via più rapida è una sostituzione testuale del nome della release nei file delle fonti:

# Sostituisce 'bookworm' con 'trixie' nel file principale
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# Fa lo stesso per i file dei repository aggiuntivi
sudo find /etc/apt/sources.list.d -type f -exec sed -i 's/bookworm/trixie/g' {} \;

Nota importante: dalla riga non-free in poi. Da Debian 12 il firmware non libero è stato separato in un componente dedicato chiamato non-free-firmware. Se usavi non-free, verifica con cat /etc/apt/sources.list che le tue fonti includano sia non-free sia non-free-firmware, altrimenti rischi di perdere il firmware di rete o storage al primo reboot.

2. Aggiornamento del sistema

Ora sincronizza le fonti e lancia l'aggiornamento vero e proprio.

sudo apt update
sudo apt full-upgrade

Il processo richiederà tempo. apt ti mostrerà un riepilogo dei pacchetti che verranno installati, aggiornati e rimossi: leggilo davvero, non premere Invio meccanicamente. Una rimozione inattesa di un pacchetto chiave si individua qui, prima che diventi un problema. Durante l'installazione ti verranno poste alcune domande:

• Restart services during package upgrades without asking? Rispondi Yes su un sistema headless: permette ai servizi (Nginx, database, PHP-FPM) di riavviarsi in autonomia senza bloccare la procedura.
• Keep the local version currently installed? In caso di dubbio, mantieni la versione attuale del file di configurazione. Le differenze le rivedi a freddo dopo, con dpkg --get-selections e i file .dpkg-dist lasciati da apt, invece di prendere decisioni di merge a metà upgrade.

3. Gestione di casi particolari: mdadm e RAID software

A volte emergono problemi specifici con singoli pacchetti durante una major. Un caso noto su Trixie riguarda mdadm, il gestore di RAID software: l'aggiornamento può fallire quando mdadm viene processato prima di systemd, generando un errore in cui non trova il componente da cui dipende. Il problema è tracciato in un bug report ufficiale Debian.

Per prima cosa, verifica se il sistema usa effettivamente mdadm:

sudo mdadm --detail --scan

Se il comando restituisce array RAID, il workaround corretto è bloccare temporaneamente l'aggiornamento di mdadm, eseguire l'upgrade principale, poi sbloccarlo e aggiornarlo separatamente:

# Blocca temporaneamente mdadm
sudo apt-mark hold mdadm

# Esegui l'aggiornamento principale a Trixie
sudo apt update && sudo apt full-upgrade

# Sblocca e aggiorna mdadm
sudo apt-mark unhold mdadm
sudo apt update && sudo apt full-upgrade

Questo è esattamente il tipo di dettaglio che fa la differenza tra un upgrade liscio e una macchina che non riavvia: su un server con il root su RAID, sbagliare l'ordine di aggiornamento di mdadm può lasciarti con un sistema che non monta i dischi. Se per qualsiasi ragione ti ritrovi con un filesystem in stato incoerente dopo l'operazione, ho documentato la procedura di recupero nell'articolo sul ripristino di un filesystem corrotto su VPS Debian e Ubuntu.

4. Riavvio e pulizia finale

Quando l'aggiornamento si completa senza errori, è il momento del riavvio finale per avviare il nuovo kernel 6.12 e il sistema Trixie.

sudo reboot

Dopo il riavvio, verifica che tutto funzioni come previsto: la versione di sistema con cat /etc/debian_version (deve riportare 13), i servizi critici con systemctl --failed, e i log di boot con journalctl -b -p err. Infine, rimuovi i pacchetti obsoleti e le dipendenze non più necessarie:

sudo apt autoremove && sudo apt clean

5. Modernizzare le fonti software (opzionale)

Debian 13 incoraggia il nuovo formato deb822 per i file delle fonti, più leggibile e robusto del vecchio sources.list su una riga. Puoi convertire la configurazione con un solo comando:

sudo apt modernize-sources

Il comando crea i nuovi file .sources in sources.list.d e svuota il vecchio sources.list. È un passo facoltativo ma consigliato: ti allinea al formato che Debian userà come standard d'ora in avanti.

La sicurezza dopo l'upgrade: chiudere la superficie, non solo aggiornarla

Un errore frequente è considerare l'upgrade concluso al primo boot su Trixie. Aggiornare il sistema operativo riporta in copertura le patch, ma un major upgrade è anche il momento ideale per fare hardening, perché stai già toccando configurazioni e servizi. La prima mossa è automatizzare le patch di sicurezza: su un sistema appena aggiornato non vuoi che il prossimo buco resti aperto per settimane perché nessuno ha lanciato apt update.

# Installa e configura gli aggiornamenti di sicurezza automatici
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Configurato in modo conservativo, unattended-upgrades applica solo gli aggiornamenti del repository di sicurezza, lasciando intatto il resto: è il giusto compromesso tra restare protetti e non rischiare un cambio di comportamento inatteso in produzione. La gestione dei point release di Trixie, e la distinzione fra un aggiornamento minore e un cambio di versione, è un tema operativo a sé che ho approfondito nell'articolo su come gestisco gli aggiornamenti di un parco VPS su Debian 13.5.

La seconda mossa è verificare il perimetro di rete. Un upgrade può ripristinare configurazioni di default su pacchetti che hai sostituito, e i servizi possono ripresentarsi in ascolto su porte che credevi chiuse. Controlla cosa è esposto:

# Cosa sta ascoltando sulla rete dopo l'upgrade
sudo ss -tulpn

Se trovi servizi in ascolto che non dovrebbero esserlo, è il momento di rivedere il firewall: la regola d'oro è esporre solo ciò che serve davvero. Per chi gestisce un VPS senza personale sistemistico dedicato, ho scritto una guida pratica su come configurare un firewall con nftables su un VPS, che ti permette di chiudere la superficie d'attacco senza dover diventare un esperto di iptables. Aggiornare il sistema e poi lasciarlo con un firewall permissivo è come cambiare la serratura e lasciare la finestra aperta.

L'upgrade non finisce al reboot. Finisce quando hai automatizzato le patch di sicurezza, verificato cosa è esposto e ristretto il firewall a ciò che serve davvero. Il resto è solo aver spostato il problema in avanti.

Domande frequenti sull'aggiornamento a Debian 13

Posso saltare Bookworm e aggiornare direttamente da Debian 11 a Debian 13? No. Debian supporta ufficialmente solo l'upgrade tra release consecutive. Da Debian 11 "Bullseye" devi passare prima a Debian 12 "Bookworm", aggiornare completamente, riavviare, e solo allora procedere verso Trixie. Saltare una major non è testato dal progetto e ti espone a stati intermedi non gestiti dai pacchetti.

Quanto tempo richiede l'upgrade su un server di produzione? Il download e l'installazione dei pacchetti su un VPS standard richiedono tipicamente da venti minuti a un'ora, a seconda della quantità di software installato e della banda. La parte critica però non è il tempo macchina, è la finestra di manutenzione: pianifica il riavvio in un orario di basso traffico e tieni pronto lo snapshot per il rollback.

Cosa faccio se un servizio non riparte dopo l'upgrade? Per prima cosa, systemctl status nome-servizio e journalctl -u nome-servizio -b per leggere l'errore reale. Spesso si tratta di un file di configurazione obsoleto sopravvissuto all'upgrade: confronta la tua versione con quella nuova (i file .dpkg-dist o .ucf-dist che apt lascia accanto). Se il problema è più profondo e tocca i dischi o il boot, lo snapshot pre-upgrade è il modo più rapido per tornare operativo mentre indaghi a freddo.

L'upgrade rimuove le mie configurazioni personalizzate? No, se rispondi correttamente alle domande di apt. Quando ti chiede se mantenere la versione locale di un file di configurazione, scegliendo di mantenerla preservi le tue modifiche; il pacchetto deposita la versione nuova come file affiancato (.dpkg-dist) che potrai riconciliare con calma. È proprio per questo che leggere quelle domande, invece di accettarle al volo, è importante.

Debian 13 supporta ancora le architetture a 32 bit? No, da Trixie alcune architetture come i386 non sono più supportate come piattaforma di installazione completa. Se gestisci hardware molto datato a 32 bit, valuta una migrazione su macchina a 64 bit prima dell'upgrade: il salto di major è l'occasione naturale per pianificare anche il ricambio hardware.

Una rete di sicurezza, non un atto di fede

Affrontare un'operazione come l'aggiornamento di un sistema operativo di produzione con un piano e una metodologia precisa è ciò che distingue un approccio amatoriale da uno professionale. Non si tratta di conoscere i comandi a memoria, ma di costruire intorno a quei comandi una rete di sicurezza: lo snapshot che ti riporta indietro, il backup offsite che ti salva se lo snapshot fallisce, la finestra di manutenzione scelta da te invece che imposta da una scadenza, la verifica dei servizi e del firewall a operazione conclusa. Debian 13 ti restituisce anni di supporto pieno e un kernel moderno, ma il valore vero dell'operazione non è il sistema più nuovo: è la disciplina con cui ci sei arrivato, perché è la stessa disciplina che ti servirà la prossima volta che qualcosa, inevitabilmente, andrà storto.

Se gestisci uno o più server dedicati o VPS presso Hetzner, OVH, Contabo, Digital Ocean o un provider italiano e devi pianificare il passaggio a Debian 13 senza fermare la produzione, oppure ti trovi con un upgrade andato male da recuperare, contattami per una consulenza diretta: tra la diagnosi e la prima contromisura, di solito, passano ore, non settimane. Posso aiutarti a impostare la procedura di upgrade, le copie di sicurezza testate e l'hardening post-aggiornamento perché la longevità della tua infrastruttura smetta di dipendere dalla fortuna.