Prima di iniziare: cosa cambia davvero nell'upgrade
L'aggiornamento da Debian 12 a Debian 13 è un upgrade di release, non un semplice aggiornamento di pacchetti. Significa passare da una base stabile a una successiva, con possibili cambi di versione di kernel, librerie, servizi di sistema, PHP, database, tool di rete e componenti di sicurezza.
La regola pratica è semplice: prima prepari, poi aggiorni, poi verifichi. Se il server ospita servizi esposti in produzione, considera l'operazione come un change controllato con finestra di manutenzione, snapshot o backup verificato e piano di rollback.
Se hai un ambiente critico, fai almeno una prova su una VM clonata o su uno staging con stessa configurazione. L'upgrade di Debian è affidabile, ma i problemi reali arrivano quasi sempre da repository terzi, pacchetti obsoleti, configurazioni locali o servizi applicativi non compatibili con le nuove versioni.
Checklist tecnica prima dell'upgrade
Prima di toccare i repository, verifica questi punti:
- spazio libero sufficiente su
/,/vare/boot; - backup completo o snapshot della VM;
- accesso console o KVM/IPMI, non solo SSH;
- finestra di manutenzione e possibilità di riavvio;
- elenco dei repository esterni e dei pacchetti non Debian;
- stato dei servizi critici: web, database, mail, DNS, reverse proxy;
- presenza di eventuali customizzazioni in
/etce script in/usr/local.
Se il server è remoto, la console fuori banda non è un optional: se l'upgrade rompe rete, bootloader o initramfs, ti serve un accesso alternativo per recuperare.
Verifica dello stato attuale
Parti dall'inventario. Devi sapere esattamente cosa hai prima di cambiare release.
cat /etc/debian_version
lsb_release -a 2>/dev/null || cat /etc/os-release
uname -a
apt-cache policy | head -n 30
Controlla i repository attivi e cerca sorgenti esterne:
grep -R --line-number -E '^[^#].*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/Se usi pacchetti di terze parti, annota quali sono. I candidati tipici a problemi sono repository di PHP, database, pannelli hosting, agent di monitoraggio, antivirus, software VPN, tool vendor-specific.
Controlla lo spazio disponibile:
df -h
apt-cache showpkg bash >/dev/null
Per /boot e il kernel, verifica quanti kernel vecchi hai installati. Se /boot è pieno, l'upgrade può fallire quando prova a installare kernel e initramfs nuovi.
dpkg -l 'linux-image*' | awk '/^ii/{print $2, $3}'
dpkg -l 'linux-headers*' | awk '/^ii/{print $2, $3}'
Backup e rollback: cosa salvare davvero
Il rollback di un upgrade di release non è banale. Non dare per scontato di poter tornare indietro solo con apt. La via corretta è avere un rollback esterno: snapshot VM, backup bare metal, immagine disco o almeno backup consistente di file di configurazione e dati applicativi.
Minimo sindacale:
/etccompleto;- dump dei database;
- dati applicativi in
/var/lib,/srvo path custom; - configurazioni dei servizi in uso;
- lista pacchetti installati.
Per inventario pacchetti:
dpkg --get-selections > /root/pkg-selections-debian12.txt
apt-mark showmanual > /root/pkg-manual-debian12.txt
Se hai database:
mysqldump --single-transaction --routines --events --all-databases > /backup/all-db.sql
pg_dumpall > /backup/all-db.sql
Usa il comando adatto al tuo motore, non entrambi. Il punto è avere un dump verificabile e ripristinabile, non un file enorme creato per tranquillizzarsi.
Pulizia prima del cambio di release
Prima dell'upgrade, porta il sistema in uno stato pulito. Questo riduce conflitti e dipendenze rotte.
- Aggiorna Debian 12 all'ultimo stato disponibile.
apt update
apt upgrade
apt full-upgrade
apt autoremove --purge
- Correggi eventuali pacchetti interrotti.
dpkg --configure -a
apt -f install- Rimuovi o disabilita repository terzi non compatibili con la nuova release, se non indispensabili.
Se un repository non ha supporto per Debian 13, lascialo fuori temporaneamente. È meglio reinstallare il pacchetto dal repo corretto dopo l'upgrade che trascinarsi un conflitto durante il cambio release.
- Verifica servizi in errore.
systemctl --failed
journalctl -p err -b --no-pager | tail -n 50Se ci sono già errori prima dell'upgrade, sistemali prima. Altrimenti non saprai più distinguere un problema preesistente da uno introdotto dal cambio release.
Modifica dei repository APT
Quando Debian 13 è disponibile sul ramo stabile che ti serve, si aggiorna la distribuzione nei repository. La pratica più semplice è sostituire i riferimenti a Debian 12 con quelli di Debian 13.
Fai prima un backup dei file APT:
cp -a /etc/apt/sources.list /etc/apt/sources.list.bak
cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.bak
Poi aggiorna i riferimenti. Se usi il file classico:
sed -i 's/bookworm/trixie/g' /etc/apt/sources.listSe hai più file in /etc/apt/sources.list.d/, controllali uno per uno. Non fare sostituzioni cieche su file di terze parti se non sei sicuro del formato supportato dal vendor.
Dopo la modifica, ricarica gli indici:
apt updateSe apt update segnala errori di firma o repository non raggiungibili, fermati e correggi prima di procedere. Non forzare l'upgrade con indici incoerenti.
Upgrade di Debian 12 a Debian 13
Il percorso standard è: prima un aggiornamento completo del sistema attuale, poi il cambio release, infine il completamento dei pacchetti rimasti indietro.
- Assicurati che il sistema sia aggiornato e che non ci siano pacchetti bloccati.
apt upgrade
apt full-upgrade- Avvia l'upgrade della nuova release.
apt update
apt upgrade
apt full-upgradeSu Debian, apt full-upgrade è spesso il passaggio decisivo perché gestisce rimozioni e sostituzioni necessarie tra versioni. Durante il processo, leggi con attenzione i prompt sui file di configurazione. Se hai personalizzazioni locali, di solito conviene mantenere le tue versioni e confrontare i file .dpkg-dist o .dpkg-old dopo il reboot.
- Se il sistema propone rimozioni importanti, fermati e valuta il pacchetto coinvolto.
Una rimozione di massa può indicare repository esterni non allineati, pacchetti obsoleti o dipendenze non risolte. In quel caso, non andare avanti alla cieca.
Gestione dei conflitti più comuni
Durante un upgrade di release, i problemi più frequenti sono prevedibili.
Repository terzi incompatibili
Se apt update o apt full-upgrade falliscono per dipendenze esterne, disabilita temporaneamente il repository colpevole. Verifica i file in /etc/apt/sources.list.d/ e commenta la riga incriminata. Poi ripeti:
apt update
apt full-upgradeDopo l'upgrade, reinstalla il pacchetto dal repository corretto per Debian 13 o dal canale ufficiale del vendor, se disponibile.
Pacchetti trattenuti
Se alcuni pacchetti restano indietro, individua i hold:
apt-mark showholdRimuovi il hold solo se sai perché esiste. In molti casi riguarda database, kernel, runtime PHP o agent di sicurezza. Sbloccare senza capire può portare a un cambio di versione non desiderato.
File di configurazione modificati
Quando compare il prompt sui file conffile, la scelta dipende dal tipo di modifica. Se il file è gestito quasi interamente da te, tieni la tua versione e confronta dopo. Se invece hai fatto poche modifiche e la nuova versione contiene fix importanti, valuta l'adozione della versione del maintainer.
Controlla poi i file differiti:
find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-dist' -o -name '*.ucf-old'Riavvio e verifica post-upgrade
Finito l'upgrade, riavvia. Il reboot serve a caricare kernel, moduli e servizi sulla nuova base di sistema.
rebootDopo il riavvio, verifica subito lo stato della release e dei servizi:
cat /etc/os-release
uname -r
systemctl --failed
Controlla i log del boot corrente:
journalctl -b -p err --no-pager | tail -n 100Se il sistema non sale correttamente, la prima distinzione da fare è semplice: problema di boot, rete, storage o servizio applicativo. Non partire dal codice dell'applicazione se il nodo non risponde nemmeno a livello systemd.
Verifica che APT sia pulito:
apt update
apt full-upgrade
apt autoremove --purgeSe apt segnala ancora pacchetti non configurati, risolvili prima di dichiarare concluso l'upgrade.
Controlli applicativi dopo il cambio di release
Il sistema operativo può essere corretto ma l'applicazione no. Dopo il reboot, controlla i servizi esposti.
- web server:
systemctl status apache2osystemctl status nginx; - PHP-FPM:
systemctl status php*-fpm; - database:
systemctl status mariadbosystemctl status postgresql; - mail:
systemctl status postfix,dovecot; - DNS:
systemctl status bind9o servizio equivalente.
Controlla la risposta HTTP dall'host stesso:
curl -I http://127.0.0.1
curl -I https://tuodominio.tldSe il sito risponde localmente ma non dall'esterno, il problema è spesso edge, firewall, DNS o binding del servizio. Se invece fallisce già in locale, guarda prima web server, PHP, app o DB.
Per PHP, verifica la versione installata e i moduli caricati:
php -v
php -m | sortMolti upgrade di Debian cambiano versione PHP o librerie correlate. Se l'app usa estensioni specifiche, controlla che siano presenti e compatibili.
Database, cache e servizi dipendenti
I servizi dipendenti sono il punto in cui un upgrade apparentemente riuscito si trasforma in incidente. Il database può partire ma non accettare connessioni dall'app; Redis o Memcached possono avere socket, permessi o unità systemd cambiate; code worker e cron possono non essere riavviati.
Verifica connessioni e porte:
ss -lntp
ss -lxnpVerifica i log dell'applicazione e del database. I percorsi cambiano, ma i candidati tipici sono /var/log/mysql/, /var/log/postgresql/, /var/log/nginx/, /var/log/apache2/, oppure i log sotto journalctl.
Se il database è in errore, non tentare fix strutturali prima di capire se il problema è di avvio, permessi, spazio disco o incompatibilità di versione.
Problemi tipici dopo l'upgrade e come leggerli
Alcuni segnali sono quasi sempre diagnostici.
- Pagina bianca o 500: spesso PHP-FPM, estensioni mancanti o app incompatibile con la nuova versione PHP.
- Timeout: DB lento, storage pieno, saturazione CPU o servizio non avviato.
- SSH ok ma web giù: web server o reverse proxy non partiti, firewall locale, binding su IP errato.
- Boot lento o fermo: fsck, mounting, unità systemd fallita, initramfs o kernel.
- APT rotto: repository terzi, pacchetti trattenuti, dipendenze non risolte.
Per ogni problema, la domanda giusta è: il guasto è nel layer di sistema, nel servizio o nell'applicazione? Questa distinzione evita di perdere ore su configurazioni che non c'entrano.
Hardening e manutenzione dopo l'upgrade
Una volta stabilizzato il sistema, fai pulizia e metti in sicurezza il risultato.
- Rimuovi i repository temporaneamente disabilitati solo se non servono più.
- Elimina pacchetti orfani e dipendenze inutili.
apt autoremove --purge- Confronta i file di configurazione nuovi con quelli locali.
diff -u /etc/esempio.conf /etc/esempio.conf.dpkg-dist- Verifica aggiornamenti di sicurezza e stato del sistema.
apt update
apt list --upgradableSe il server espone servizi pubblici, controlla anche certificati TLS, regole firewall, eventuali integrazioni con CDN o WAF, e log di accesso per vedere se il traffico reale si comporta come atteso.
Strategia consigliata in pratica
Se devi fare l'upgrade su un server reale, il flusso più solido è questo: inventario, backup, pulizia, aggiornamento completo di Debian 12, cambio repository, upgrade a Debian 13, reboot, verifica servizi, correzione dei pacchetti rimasti, controllo applicativo e solo alla fine rimozione di residui. Saltare uno di questi passaggi di solito non fa risparmiare tempo: lo sposta soltanto dopo, quando il sistema è già in modifica.
Il punto più importante è non trattare l'upgrade di release come un semplice apt upgrade. È un cambio di piattaforma con impatto su servizi, dipendenze e configurazioni. Se hai osservabilità buona e rollback pronto, l'operazione è lineare. Se no, il rischio non è l'upgrade in sé, ma la mancanza di visibilità su ciò che si rompe.
Assunzione: il server è in produzione o comunque non ricostruibile rapidamente; per questo il backup verificato e la console fuori banda sono considerati prerequisiti, non optional.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.