1 18/10/2026 10 min

Timeshift non è un backup “magico”: è uno strumento per riportare il sistema a uno stato precedente quando un aggiornamento, un driver o una modifica di configurazione rompe qualcosa. Su Debian 12 e Debian 10 funziona bene, ma va scelto con criterio il backend giusto: Btrfs se vuoi snapshot nativi del filesystem, rsync se vuoi una soluzione più universale e meno invasiva.

La scelta non è cosmetica. Con Btrfs Timeshift lavora quasi da “orchestratore” degli snapshot del filesystem; con rsync copia file e directory in una struttura tradizionale, quindi è più lento ma più compatibile. Se il sistema è già su ext4, in pratica la via più lineare è rsync. Se stai progettando una reinstallazione o una nuova macchina e vuoi snapshot rapidi, Btrfs merita attenzione, ma richiede un layout coerente fin dall’inizio.

Debian 12 e Debian 10: cosa cambia davvero

La procedura di installazione è simile su entrambe le release, ma Debian 12 ha pacchetti e dipendenze più aggiornati, quindi tende a darti meno attriti. Debian 10 è ancora utilizzabile in molti contesti legacy, però qui conviene verificare con più attenzione la disponibilità del pacchetto nei repository configurati e l’eventuale stato del supporto della distribuzione nel tuo ambiente.

Se il tuo obiettivo è proteggere un server di produzione, il punto non è “installare Timeshift” e basta. Devi decidere:

  • quale filesystem stai usando oggi;
  • dove salverai gli snapshot;
  • quanta retention ti serve;
  • se Timeshift deve proteggere solo il sistema o anche dati applicativi specifici.

Timeshift è pensato soprattutto per il rollback del sistema, non per sostituire un backup applicativo completo. Se hai database, code, upload utenti o dati transazionali, quelli vanno trattati separatamente con backup veri, non con snapshot del sistema operativo.

Verifica preliminare: filesystem, spazio e repository

Prima di installare, controlla tre cose: filesystem, spazio disco e configurazione dei repository. È il modo più rapido per evitare di fare troubleshooting dopo l’installazione.

Per vedere filesystem e mount point:

df -Th
lsblk -f

Se vedi btrfs sulla root o su una partizione dedicata, puoi valutare l’uso del backend Btrfs. Se vedi ext4, xfs o altro filesystem tradizionale, il backend rsync è la scelta più semplice.

Controlla anche lo spazio disponibile. Gli snapshot occupano spazio reale e la crescita dipende da quanto cambia il sistema tra un punto di ripristino e l’altro.

df -h /
du -sh /home /var 2>/dev/null

Per i repository, verifica che il sistema abbia sorgenti APT sane e aggiornate:

sudo apt update
apt-cache policy timeshift

Se apt-cache policy mostra un candidato installabile, sei a posto. Se non compare nulla, il problema è quasi sempre nei repository configurati o in una release troppo vecchia per i pacchetti disponibili nel mirror attuale.

Installazione di Timeshift su Debian 12

Su Debian 12 l’installazione standard passa dai repository ufficiali, salvo ambienti molto minimali o mirror personalizzati. La sequenza tipica è questa:

sudo apt update
sudo apt install timeshift

Dopo l’installazione, verifica che il binario sia presente e che il pacchetto sia stato registrato correttamente:

timeshift --version
dpkg -l timeshift

Se il pacchetto è installato ma il comando non parte da sessione grafica, non è un’anomalia: in molte installazioni server Timeshift viene usato da CLI o da un desktop remoto. Il punto è che il servizio non gira in background in modo permanente; l’applicazione viene lanciata quando serve creare o gestire snapshot.

Installazione di Timeshift su Debian 10

Su Debian 10 la procedura è la stessa, ma conviene partire da una verifica dei repository perché molte installazioni legacy hanno mirror vecchi, repository disallineati o pinning particolari. Se il pacchetto è disponibile nei repository attivi, il comando rimane identico:

sudo apt update
sudo apt install timeshift

Se apt non trova il pacchetto, non forzare installazioni arbitrarie da sorgenti non verificate senza prima chiarire la provenienza del pacchetto e la compatibilità con la release. In un ambiente di produzione è meglio fermarsi, correggere i repository e riprovare, invece di introdurre dipendenze manuali che poi diventano difficili da mantenere.

Un controllo utile è questo:

apt-cache policy timeshift
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Se il pacchetto non è disponibile, il gap va chiuso qui: correggi le sorgenti APT, esegui sudo apt update e ripeti la verifica. Solo dopo ha senso pensare a un’installazione alternativa.

Scelta del backend: Btrfs o rsync

La prima decisione operativa, una volta installato Timeshift, è il backend. Qui non c’è una risposta universale: dipende dalla struttura del server.

Btrfs è il backend migliore quando il sistema è già costruito attorno a quel filesystem. Gli snapshot sono rapidi, lo spazio è gestito in modo efficiente e il rollback del sistema è molto più naturale. Il rovescio della medaglia è che devi avere una partizione o un volume Btrfs configurato correttamente.

Rsync è il backend più pratico su installazioni Debian classiche con ext4. È meno elegante, ma molto più flessibile: puoi usarlo senza riprogettare il disco. Il costo è il tempo di snapshot e lo spazio occupato, perché ogni copia è una vera copia di file e directory.

Se non sai quale scegliere, guarda il filesystem della root. Se è ext4 e il server è già in esercizio, rsync è la strada più prudente. Se stai preparando una nuova installazione e puoi decidere il layout disco, Btrfs è più interessante per chi vuole rollback frequenti del sistema.

Avvio guidato e configurazione iniziale

Dopo l’installazione puoi avviare l’interfaccia grafica, se presente, oppure usare il terminale. Su desktop:

sudo timeshift-gtk

In ambienti server o headless, spesso si preferisce il setup iniziale via CLI. Il comando di configurazione interattiva è utile per definire dispositivo, backend e policy di snapshot:

sudo timeshift --create --comments "snapshot iniziale" --tags D

Prima ancora di creare snapshot regolari, conviene configurare cosa viene incluso. In generale Timeshift protegge il sistema, non i dati utente pesanti. Directory come /home possono essere escluse o incluse a seconda del caso d’uso, ma su server con molti dati applicativi è spesso meglio gestire /home e i dati separatamente.

Nel wizard o nella GUI, il percorso tipico è quello delle impostazioni: selezione del tipo di snapshot, scelta del disco di destinazione, definizione della pianificazione e dei livelli di retention. Se lavori da CLI, la stessa logica va tradotta in policy operative.

Creazione del primo snapshot

Il primo snapshot è quello che ti dice se tutto il resto è coerente. Se fallisce, non ignorarlo: di solito indica problemi di permessi, spazio insufficiente o configurazione del backend.

sudo timeshift --create --comments "baseline post-install" --tags O

Dopo l’esecuzione, controlla che lo snapshot sia stato realmente creato. Con CLI puoi elencare gli snapshot disponibili:

sudo timeshift --list

Se usi Btrfs, controlla anche che il contenuto corrisponda al layout atteso. Se usi rsync, verifica che la destinazione abbia la struttura prevista e che non stia saturando il disco.

Schedulazione: snapshot automatici senza esagerare

La tentazione classica è creare snapshot troppo frequenti. In pratica, questo produce due problemi: consumo disco e rumore operativo. La retention va tarata sul ritmo delle modifiche del sistema, non sull’ansia di “avere tutto”.

Per un server Debian usato come base applicativa, una configurazione ragionevole è spesso questa:

  • snapshot giornalieri per un periodo breve;
  • snapshot settimanali per una finestra più ampia;
  • snapshot manuali prima di upgrade critici;
  • retention dimensionata sullo spazio disponibile.

Se l’hardware è piccolo, meglio pochi snapshot affidabili che una cronologia lunga ma fragile. La metrica da guardare non è solo il numero di snapshot, ma anche la crescita del disco e il tempo di creazione.

Uso pratico prima di un aggiornamento

Il caso d’uso più concreto è il pre-upgrade. Prima di un aggiornamento del kernel, di una migrazione di pacchetti o di un cambio importante sulla macchina, crea uno snapshot manuale. Se qualcosa va storto, il rollback è più semplice di una ricostruzione a mano del sistema.

sudo timeshift --create --comments "prima upgrade pacchetti" --tags D

Dopo lo snapshot, esegui l’operazione prevista. Se noti regressioni, puoi tornare allo stato precedente usando il ripristino di Timeshift. In ambiente grafico la procedura è guidata; in CLI dipende dal backend e dalla modalità di restore disponibile.

Qui vale una regola semplice: non usare Timeshift per coprire cambiamenti strutturali che non hai compreso. Se tocchi partizionamento, bootloader o migrazioni di filesystem, verifica prima la compatibilità del rollback con il layout reale della macchina.

Ripristino: cosa aspettarsi davvero

Il ripristino non è un pulsante “annulla tutto” in senso assoluto. Timeshift riporta indietro file di sistema, configurazioni e componenti installati, ma non risolve automaticamente ogni problema applicativo o ogni dato fuori dal perimetro del sistema operativo.

Dopo un restore, controlla almeno questi punti:

  • stato del boot;
  • servizi systemd principali;
  • integrità dei file di configurazione applicativi;
  • log di errore dopo il riavvio.

Comandi utili dopo il restore:

systemctl --failed
journalctl -p err -b

Se il sistema non parte come atteso, il problema non è sempre Timeshift. Può esserci un mismatch tra kernel, initramfs, driver o file di configurazione esclusi dal backup. Per questo il primo snapshot deve essere testato, non solo creato.

Retenzione, spazio e manutenzione

La manutenzione di Timeshift è soprattutto disciplina operativa. Se non controlli spazio e retention, prima o poi lo snapshot system diventa il primo colpevole quando il disco si riempie.

Controlli pratici periodici:

df -h
sudo timeshift --list

Se la destinazione si avvicina alla saturazione, riduci la retention o sposta il target su un volume più capiente. Evita di lasciare la crescita senza monitoraggio: gli snapshot sono utili solo finché non diventano un problema per la disponibilità del sistema.

Problemi comuni e come leggerli

Il problema più frequente è lo spazio insufficiente. L’errore tipico emerge durante la creazione dello snapshot o subito dopo, quando il filesystem di destinazione non ha margine. In quel caso la verifica minima è il disco libero e il log dell’operazione.

df -h
journalctl -xe | tail -n 50

Un secondo problema è il backend sbagliato rispetto al filesystem. Se provi a usare Btrfs su una root ext4 senza un layout adatto, non stai facendo una scelta audace: stai solo cercando guai. La verifica da fare è sempre la stessa: lsblk -f e il tipo di filesystem reale.

Un terzo caso è l’aspettativa sbagliata: usare Timeshift come se fosse un backup dei dati applicativi. Se il tuo sito web perde gli upload o il database, Timeshift non è lo strumento che ricostruisce quelle informazioni. Serve un backup dedicato per i dati e uno snapshot per il sistema.

Quando preferire Btrfs e quando restare su rsync

Se devi installare Timeshift su un server già online, senza rifare il layout disco, rsync è quasi sempre la scelta più pragmatica. Se invece stai allestendo una macchina nuova e vuoi rollback rapidi del sistema, Btrfs ha un vantaggio operativo evidente.

In sintesi:

  • Btrfs: migliore integrazione con snapshot, più efficiente, ma richiede progettazione del filesystem;
  • rsync: più semplice da adottare, compatibile con layout tradizionali, ma più pesante in termini di tempo e spazio.

La scelta giusta dipende dal contesto, non dalla moda del momento. Su Debian 12 o 10, un’installazione pulita con rsync è perfettamente sensata se l’obiettivo è proteggere il sistema senza toccare la struttura dei dischi. Btrfs ha senso quando il layout è pensato per quello fin dall’inizio.

Procedura sintetica consigliata

Se vuoi una sequenza essenziale e ripetibile, questa è la più solida:

  1. Verifica filesystem e spazio con lsblk -f e df -h.
  2. Aggiorna gli indici APT con sudo apt update.
  3. Installa Timeshift con sudo apt install timeshift.
  4. Controlla la versione con timeshift --version.
  5. Configura backend e destinazione in base al filesystem reale.
  6. Crea uno snapshot iniziale e verifica che compaia in elenco.
  7. Definisci retention e frequenza in modo conservativo.

Questa sequenza riduce gli errori più comuni e ti evita di scoprire troppo tardi che il disco è pieno o che il backend non corrisponde al layout della macchina.

Conclusione operativa

Installare Timeshift su Debian 12 o Debian 10 è semplice; usarlo bene richiede invece una decisione architetturale minima. Se il sistema è già in esercizio e vuoi una protezione ragionevole del layer OS, rsync è la scelta più lineare. Se stai costruendo una nuova macchina e puoi adottare Btrfs in modo coerente, gli snapshot nativi offrono un rollback più pulito.

Il punto chiave è non confondere snapshot del sistema con backup completo dei dati. Timeshift ti salva da molti guasti operativi, ma solo se lo usi per quello che fa davvero: riportare indietro il sistema quando una modifica rompe l’equilibrio della macchina.