Aggiornare un VPS Linux a Ubuntu 26.04 o Debian 13 senza rompere la produzione

Ubuntu 26.04 LTS è uscito ad aprile 2026 e, da settembre, l'aggiornamento da 24.04 è aperto a tutti. Debian 13 è la versione stabile da agosto 2025 e Debian 12 è ormai seguito solo dal team LTS. Ecco come portare il vostro VPS Linux alla nuova versione senza trasformare un aggiornamento in un disservizio: situazione attuale, checklist, comandi e piano di ripristino.

A che punto sono Ubuntu e Debian a ottobre 2026

Dati tratti dalle note di rilascio di Canonical e dal calendario LTS di Debian:

Versione	Uscita	Supporto	Da quale versione
Ubuntu 26.04 LTS (Resolute Raccoon)	23 aprile 2026, point release 26.04.1 il 27 agosto 2026	5 anni di aggiornamenti standard (aprile 2031), 10 anni con l'ESM di Ubuntu Pro	solo 24.04 LTS o 25.10
Ubuntu 24.04 LTS	aprile 2024	supporto standard fino al 2029	22.04 LTS
Debian 13 (trixie)	9 agosto 2025 (13.7 a settembre 2026)	team di sicurezza fino al 9 agosto 2028, poi LTS fino al 30 giugno 2030	solo Debian 12
Debian 12 (bookworm)	10 giugno 2023	in LTS dall'11 giugno 2026, fino al 30 giugno 2028	Debian 11

Due conseguenze pratiche:

Da Ubuntu 22.04 non esiste un salto diretto. Canonical lo scrive chiaramente: prima si passa a 24.04 LTS (o 25.10), poi a 26.04. Mettete in conto due aggiornamenti, con riavvio e test in mezzo.
Nemmeno Debian salta le versioni. È supportato solo l'aggiornamento dalla versione precedente: un server Debian 11 passa prima a 12, poi a 13.

Su un VPS con Ubuntu 24.04 non c'è fretta: è coperto fino al 2029. Un server Debian 12, invece, riceve ormai solo le correzioni del team LTS, con un perimetro più ristretto: pianificate il passaggio a Debian 13 con calma, non di corsa nel 2028.

Aggiornamento sul posto o nuovo server?

In produzione, l'aggiornamento sul posto non è sempre la via più sicura. Avete due opzioni:

Aggiornamento sul posto (do-release-upgrade o apt full-upgrade): rapido, mantiene IP e configurazione, ma il servizio si interrompe durante l'operazione e tornare indietro significa ripristinare.
Nuovo VPS con 26.04 o 13, poi migrazione: spostate i dati, testate con calma e poi cambiate il DNS. Il vecchio server resta intatto ed è il vostro ripristino immediato.

Per un server semplice, l'aggiornamento sul posto basta se la preparazione è seria. Con molti repository di terze parti o container datati, una reinstallazione pulita è spesso meno rischiosa.

La checklist prima di toccare la produzione

1. Uno snapshot E un vero backup

Lo snapshot del VPS, se il vostro provider lo offre, è il modo più rapido per tornare indietro: congela l'intero disco. Ma risiede sulla stessa infrastruttura del server e non sostituisce un backup. Fate entrambe le cose:

uno snapshot subito prima dell'operazione, con i servizi o almeno i database fermi, per avere uno stato coerente;
un backup esterno di ciò che conta, fuori dal server: dump dei database, /etc, directory dei siti, volumi Docker, crontab.

# Come root (sudo -i), adattate alla vostra installazione
mkdir -p /root/backup

# Dump dei database
mysqldump --all-databases --single-transaction > /root/backup/mysql-all.sql
su - postgres -c pg_dumpall > /root/backup/pg-all.sql

# Configurazione e pacchetti installati
tar czf /root/backup/etc.tar.gz /etc
dpkg --get-selections '*' > /root/backup/pacchetti.txt
apt-mark showmanual > /root/backup/pacchetti-manuali.txt

Poi copiate /root/backup su un'altra macchina (rsync, object storage, il vostro computer). Un backup mai ripristinato è solo un'ipotesi: testate almeno un dump.

2. Verificare cgroup v2 (bloccante per Ubuntu 26.04)

È il cambiamento che sta causando più danni quest'anno. systemd 259, fornito con Ubuntu 26.04, non supporta più cgroup v1 (gerarchie legacy e hybrid). Secondo le note di rilascio di Canonical:

un'installazione Ubuntu che usa cgroup v1 non potrà essere aggiornata a 26.04;
i carichi containerizzati 26.04 non girano su un host avviato con cgroup v1;
un host 26.04 non supporta i container che richiedono cgroup v1, per esempio le immagini Ubuntu precedenti alla 18.04.

Ubuntu e Debian usano cgroup v2 di default da diverse versioni, ma alcuni server sono stati forzati in v1 per far girare container vecchi, versioni datate di Docker o agenti di monitoraggio. Verificate:

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2, tutto a posto
# tmpfs      -> cgroup v1 o ibrido, da correggere prima dell'aggiornamento

grep -o 'systemd.unified_cgroup_hierarchy=[0-9]' /proc/cmdline
grep -n 'cgroup' /etc/default/grub /etc/default/grub.d/* 2>/dev/null

Se nella configurazione di GRUB è rimasto un parametro systemd.unified_cgroup_hierarchy=0, rimuovetelo, eseguite sudo update-grub, riavviate e verificate che i container funzionino ancora prima dell'aggiornamento. Lato Docker, elencate container e immagini con docker ps -a e individuate le distribuzioni molto vecchie: un'immagine il cui systemd interno è precedente a cgroup v2 va sostituita, non aggirata, perché systemd 259 non sa più avviarsi in cgroup v1 e su 26.04 non esiste un'impostazione per tornare indietro.

Su Debian 13, systemd 257 considera già obsoleto cgroup v1: la stessa verifica vi eviterà brutte sorprese al prossimo aggiornamento.

3. Censire i repository di terze parti

Docker, PHP da un repository esterno, Node.js, PPA vari: sono loro a rompere gli aggiornamenti. Elencateli:

ls /etc/apt/sources.list.d/
grep -rhE '^(deb|URIs|Suites)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Per ognuno, verificate che pubblichi pacchetti per la versione di destinazione (resolute per Ubuntu 26.04, trixie per Debian 13). Il repository ufficiale di Docker, per esempio, supporta Ubuntu 26.04 e Debian 13. do-release-upgrade disattiva i repository di terze parti durante l'operazione; su Debian tocca a voi. In ogni caso, annotateli per riattivarli dopo.

4. I pacchetti bloccati

apt-mark showhold

Un pacchetto essenziale in stato hold fa fallire l'aggiornamento. Le note di Debian raccomandano di togliere i blocchi prima di iniziare (sudo apt-mark unhold pacchetto), tranne per un pacchetto che avete ricompilato voi.

5. Spazio su disco, accesso di emergenza e finestra di manutenzione

Lasciate diversi GB liberi su / e controllate /boot: df -h / /boot. Su Debian, apt -o APT::Get::Trivial-Only=true full-upgrade stima lo spazio necessario una volta impostate le nuove sorgenti.
Individuate la console di emergenza del vostro provider (console VNC o equivalente nell'area clienti): è lei che vi salva se la rete non torna dopo il riavvio.
Lavorate dentro tmux o screen: se la connessione SSH cade, l'aggiornamento prosegue e potete ricollegarvi alla sessione.
Avvisate gli utenti, abbassate in anticipo il TTL dei record DNS se prevedete una migrazione e scegliete un momento tranquillo.

6. Scrivere il piano di ripristino

Decidete prima, non durante: «se i servizi non sono tornati entro X minuti, ripristino lo snapshot». Annotate dove si trova il ripristino, quanto tempo richiede e cosa perdete (tutto ciò che è stato scritto dopo lo snapshot).

Da Ubuntu 24.04 a 26.04, passo dopo passo

Dall'uscita di 26.04.1 l'aggiornamento viene proposto normalmente: l'opzione -d, che serviva a forzarlo prima dell'apertura ufficiale, non è più necessaria.

# 1. Aggiornare completamente la 24.04 e riavviare se è stato installato un nuovo kernel
sudo apt update && sudo apt full-upgrade
sudo reboot

# 2. Verificare lo strumento e la politica di aggiornamento
sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades   # deve mostrare Prompt=lts

# 3. Avviare l'aggiornamento dentro tmux
tmux new -s upgrade
sudo do-release-upgrade

Avviato via SSH, lo strumento propone di aprire un secondo demone SSH su un'altra porta come riserva; se accettate, aprite temporaneamente quella porta nel firewall. Alle domande sui file di configurazione, nel dubbio mantenete la vostra versione e confrontatela poi con il file .dpkg-dist.

Se partite da Ubuntu 22.04, lo stesso comando vi porta a 24.04. Riavviate, controllate i servizi, poi rilanciate do-release-upgrade per arrivare a 26.04.

Cosa cambia su un server Ubuntu 26.04

Kernel 7.0 e systemd 259; 26.04 è l'ultima versione che supporta gli script System V: migrateli a unit systemd.
sudo-rs sostituisce sudo di default; il sudo originale resta disponibile come sudo.ws. Testate script e playbook che usano opzioni di sudoers poco comuni.
rust-coreutils fornisce ora le utility di base. Canonical continua a fornire gli strumenti GNU per i casi di incompatibilità: testate i vostri script shell.
/tmp in tmpfs di default: ciò che stava in /tmp ora occupa RAM e sparisce al riavvio.
OpenSSH 10.2: le chiavi DSA non sono più supportate.
Chrony è il servizio orario delle nuove installazioni; su un server aggiornato il passaggio è manuale (sudo apt-mark auto systemd-timesyncd poi sudo apt install chrony).
Apache e mod_php: la unit systemd di Apache attiva MemoryDenyWriteExecute=yes, che rompe il JIT di PHP con libapache2-mod-php. Canonical consiglia di passare a php-fpm o, in alternativa, di sovrascrivere l'opzione con sudo systemctl edit apache2.
PostgreSQL: Canonical segnala una regressione di prestazioni con il kernel 7.0 e consiglia di attivare le huge pages.
Versioni: PHP 8.5, MySQL 8.4 LTS. Rileggete le note di migrazione delle vostre applicazioni.

Da Debian 12 a Debian 13, passo dopo passo

Debian non ha un equivalente di do-release-upgrade: si cambiano le sorgenti APT e si aggiorna in due fasi.

# 1. Aggiornare completamente Debian 12 (inclusa la correzione OpenSSH per gli aggiornamenti remoti)
sudo apt update && sudo apt full-upgrade
sudo reboot

Le note di rilascio avvertono che una sessione SSH interrotta durante l'aggiornamento poteva rendere il server irraggiungibile con l'OpenSSH originale di bookworm: assicuratevi di avere almeno la versione 1:9.2p1-2+deb12u7 (dpkg -l openssh-server) e lavorate in tmux.

Poi passate le sorgenti al formato deb822 raccomandato da Debian 13: un solo file /etc/apt/sources.list.d/debian.sources, rimuovendo il vecchio /etc/apt/sources.list.

sudo mv /etc/apt/sources.list /root/backup/sources.list.bookworm
sudo tee /etc/apt/sources.list.d/debian.sources <<'EOF'
Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF

Aggiungete contrib o non-free alla riga Components se la vecchia configurazione li usava. Disattivate i repository di terze parti (rinominate i file in .disabled) e rimuovete le voci bookworm-backports-sloppy, per cui Debian non prevede un percorso di aggiornamento pulito.

# 2. Aggiornamento minimo, poi completo
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

Prima di riavviare, controllate il nome dell'interfaccia di rete: il passaggio a systemd 257 può cambiare il nome generato per alcune schede, e un VPS la cui interfaccia cambia nome riparte senza rete. Le note di rilascio indicano il comando da eseguire subito prima del riavvio:

ip -br link
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Sostituite eth0 con il nome mostrato da ip -br link. Se ID_NET_NAME è diverso dal nome attuale, adattate /etc/network/interfaces o fissate il nome con un file .link di systemd prima di riavviare. Verificate anche che sia installato un metapacchetto del kernel (dpkg -l 'linux-image*' | grep ^ii | grep -i meta).

Dopo il riavvio, fate pulizia e convertite le sorgenti rimaste:

sudo apt modernize-sources   # converte i file .list rimasti in deb822
sudo apt autoremove
apt list '?obsolete'          # pacchetti che non provengono più da alcun repository

Debian 13 segnala inoltre che i percorsi dei portachiavi in .gpg sono ormai solo link di compatibilità verso i file .pgp: una volta concluso l'aggiornamento potete sostituire debian-archive-keyring.gpg con debian-archive-keyring.pgp nelle sorgenti.

Cosa cambia su un server Debian 13

Kernel 6.12, OpenSSH 10.0 (niente più chiavi DSA), OpenSSL 3.5, PHP 8.4, PostgreSQL 17, MariaDB 11.8, Nginx 1.26, Python 3.13.
/tmp passa in tmpfs (fino al 50% della RAM di default), e /tmp e /var/tmp vengono puliti regolarmente: un servizio che vi lascia file duraturi va spostato.
i386 non è più un'architettura completa: non aggiornate un server a 32 bit.

Dopo il riavvio: i controlli

lsb_release -a               # versione giusta?
systemctl --failed           # nessun servizio in errore?
journalctl -p err -b         # errori dall'avvio
ss -tlnp                     # le porte previste sono in ascolto?
stat -fc %T /sys/fs/cgroup/  # cgroup2fs
docker ps -a                 # container ripartiti?

Riattivate poi i repository di terze parti con il nome della nuova versione. Per Docker di solito basta impostare Suites: resolute (Ubuntu 26.04) o Suites: trixie (Debian 13) in /etc/apt/sources.list.d/docker.sources, poi sudo apt update && sudo apt full-upgrade. Infine testate siti e API dall'esterno, i cron, i backup automatici e il rinnovo dei certificati (sudo certbot renew --dry-run se usate Certbot).

Se qualcosa si rompe: il ripristino

Il server non risponde più: usate la console di emergenza del provider. La causa più frequente è la rete (nome dell'interfaccia, Netplan) o il firewall.
Un servizio non parte: journalctl -u servizio -b dà quasi sempre il motivo (opzione di configurazione rimossa, modulo PHP mancante, versione del database).
Il problema non è risolto entro il tempo che vi eravate dati: ripristinate lo snapshot, rimettete online il servizio e analizzate con calma su una copia. Non esiste un «downgrade» pulito di una distribuzione: il ripristino è lo snapshot o il backup.

FAQ

Si può passare direttamente da Ubuntu 22.04 a 26.04?

No. Canonical impone di passare prima da 24.04 LTS (o 25.10). Su un server, fate due aggiornamenti successivi con test in mezzo.

Perché do-release-upgrade dice che non ci sono nuove versioni?

Verificate Prompt=lts in /etc/update-manager/release-upgrades e che la 24.04 sia completamente aggiornata. Ricordate anche che un sistema in cgroup v1 non può essere aggiornato a 26.04: passate prima a cgroup v2.

Debian 12 è ancora sicuro in produzione?

Riceve correzioni di sicurezza dal team LTS fino al 30 giugno 2028, ma su un insieme di pacchetti più ristretto. È ancora utilizzabile, ma pianificate il passaggio a Debian 13.

I miei vecchi container Docker funzioneranno su Ubuntu 26.04?

Quelli che richiedono cgroup v1, come le immagini Ubuntu precedenti alla 18.04, no. Aggiornate quelle immagini prima dell'aggiornamento, se possibile su un server di test.