SLES Btrfs Snapper Rollback dopo un aggiornamento non riuscito: Guida al ripristino sicuro

Un aggiornamento SLES non riuscito non significa necessariamente che sia necessario reinstallare il server. Su un'installazione standard di SUSE Linux Enterprise Server che utilizza Btrfs come file system root e ha Snapper abilitato, è spesso possibile avviare uno snapshot precedente all'aggiornamento, testarlo senza modificare il sistema corrente e quindi impostare tale stato funzionante come nuova directory root scrivibile.

La decisione importante non è semplicemente "quale snapshot è il più recente?", ma "quanto dovrei ripristinare?". Un ripristino completo del sistema Snapper è appropriato quando un aggiornamento ha modificato diversi pacchetti, librerie, servizi o file di configurazione e la macchina non si comporta più in modo affidabile. Se solo un file di configurazione è errato, il ripristino di quel file è in genere meno problematico. Questa guida illustra entrambe le opzioni e segue il modello di ripristino di SLES 15 SP7 documentato da SUSE e disponibile a ottobre 2026.

Scegli il metodo di ripristino prima di modificare qualsiasi cosa

SUSE distingue l'annullamento delle modifiche dal rollback del sistema . L'annullamento delle modifiche confronta gli snapshot e annulla le modifiche ai file selezionati. Un rollback, invece, rende lo stato di uno snapshot la base per una nuova root scrivibile. SUSE raccomanda specificamente di avviare prima lo snapshot di destinazione quando si esegue un rollback del file system root, perché ciò consente di verificare il candidato prima di confermarlo. Consultare la Guida di amministrazione di SLES 15 SP7 .

Passaggio 1: Verificare che questo server supporti il ​​percorso di rollback standard di Snapper

Prima di scegliere uno snapshot, verifica tre cose: il file system root è Btrfs, Snapper ha una configurazione denominata roote la root Btrfs si trova su un singolo dispositivo. SUSE documenta il supporto per il rollback avviabile per il layout predefinito del sottovolume root e afferma che il file system root Btrfs deve segnalare un singolo dispositivo.

findmnt /
sudo snapper list-configs
sudo /sbin/btrfs filesystem show /

Se findmnt /viene segnalato un file system come XFS o Ext4, interrompere l'operazione: il flusso di lavoro di avvio tramite snapshot Btrfs non è disponibile per quella root. Se snapper list-configsnon è presente rootalcuna voce, è possibile che gli snapshot automatici della root non siano stati abilitati. Interrompere l'operazione anche se btrfs filesystem show /vengono segnalati più dispositivi; la documentazione di SLES 15 SP7 non elenca tale configurazione come supportata per il ripristino della root avviabile.

Passaggio 2: Identificare l'istantanea scattata immediatamente prima dell'aggiornamento non riuscito.

Elenca le istantanee e osserva la data, il tipo, la relazione precedente allo scatto e la descrizione:

sudo snapper list

Nella configurazione SLES predefinita, YaST e Zypper possono creare coppie predi postsnapshot. Uno presnapshot rappresenta lo stato del file system prima della transazione; lo postsnapshot corrispondente rappresenta lo stato successivo. Non selezionare uno snapshot solo perché è precedente all'errore. Assicurati che il timestamp e la descrizione dello snapshot corrispondano alla finestra temporale di aggiornamento.

Se la modifica non riuscita riguardava la migrazione di un service pack, la Guida all'aggiornamento di SLES 15 SP7 di SUSE indica specificamente agli amministratori di individuare lo snapshot creato immediatamente prima della migrazione e precisa che lo snapshot in questione è contrassegnato come importante.

Passaggio 3: Esaminare cosa cambierebbe effettivamente l'istantanea candidata

Se il sistema corrente si avvia ancora, confronta lo snapshot candidato con lo stato attuale prima del riavvio. Questo può rivelare se l'aggiornamento ha modificato un solo file di configurazione o un'ampia serie di file di sistema.

sudo snapper status SNAPSHOT_ID..0
sudo snapper diff SNAPSHOT_ID..0 /etc/some-file.conf

Quando il ripristino selettivo rappresenta il miglior compromesso

Se un file noto è errato e il resto del sistema aggiornato è integro, il ripristino di quel solo file evita di annullare modifiche di sistema non correlate. SUSE documenta questa procedura:

sudo snapper -c root -v undochange SNAPSHOT_ID..0 /etc/some-file.conf

Non omettere casualmente il nome del file. Senza i nomi dei file, undochangeè possibile annullare tutte le modifiche apportate ai file tra i due stati. SUSE avverte che utilizzare il ripristino dei file per simulare un rollback completo del root non è il metodo consigliato. Le transazioni dei pacchetti possono modificare molti file interdipendenti, quindi un rollback completo e testato è solitamente più facile da gestire quando l'errore di aggiornamento è di sistema.

Passaggio 4: Avviare lo snapshot candidato da GRUB

Riavvia la macchina. Nel menu SLES GRUB 2, scegli l'opzione per avviare il boot loader da uno snapshot di sola lettura, quindi seleziona lo snapshot che corrisponde allo stato precedente all'aggiornamento. Il layout esatto della schermata può variare a seconda del firmware e della configurazione di avvio, ma SLES 15 SP7 documenta la voce come Avvia il boot loader da uno snapshot di sola lettura .

Solo gli snapshot della rootconfigurazione Snapper predefinita sono avviabili tramite questo meccanismo SLES. Se il menu degli snapshot non è presente, non creare una voce di avvio. Verifica nuovamente se Snapper è stato abilitato, se il layout della root è ancora la struttura predefinita supportata e se il boot loader installato è funzionante.

Passaggio 5: Testare lo snapshot mentre la directory root è in sola lettura.

Dopo l'avvio dello snapshot, verifica che tu stia effettivamente eseguendo il programma da esso e che il file system root sia di sola lettura:

findmnt /
mount | grep ' on / '

Ora testa le funzionalità che non hanno funzionato dopo l'aggiornamento: avvio dei servizi, configurazione di rete, autenticazione, avvio delle applicazioni, comportamento dipendente dal kernel o altri controlli pertinenti. Evita di trattare lo snapshot di sola lettura come un normale avvio di produzione. Alcune operazioni falliranno semplicemente perché la parte dello snapshot del file system root non può essere scritta.

Se lo snapshot non è quello corretto, riavvia il sistema e prova con un altro candidato. Finché non esegui il comando di rollback, quello snapshot non viene impostato come nuova directory radice di sistema scrivibile.

Passaggio 6: Conferma il rollback solo dopo che lo snapshot ha superato i tuoi controlli

Quando lo snapshot avviato si comporta come previsto, rendilo permanente:

sudo snapper rollback

È possibile aggiungere una descrizione per rendere più facile l'identificazione dell'istantanea risultante in un secondo momento:

sudo snapper rollback -d "Rollback after failed update"

Secondo la documentazione di amministrazione di SLES, Snapper crea un'istantanea dello stato precedente al rollback e una nuova istantanea scrivibile che diventa la directory radice predefinita. Questa è un'importante proprietà di sicurezza: il rollback non si limita a sovrascrivere la vecchia directory radice.

Riavvia il sistema al termine del comando:

sudo reboot

Al successivo avvio, scegli la voce SLES predefinita anziché avviare nuovamente la vecchia istantanea di sola lettura.

Passaggio 7: Verificare che la directory radice ripristinata sia scrivibile e che ora sia quella predefinita

Dopo l'avvio normale, controlla il mount della directory root e l'elenco degli snapshot:

findmnt /
sudo snapper list

Ripeti i controlli funzionali che inizialmente non hanno superato la verifica. Se un'applicazione continua a non funzionare, valuta se una parte di essa risiede in una directory non inclusa nello snapshot principale.

Passaggio 8: Aggiorna i repository e verifica lo stato del pacchetto

Per un normale aggiornamento di un pacchetto, è necessario aggiornare i repository e verificare le dipendenze del pacchetto prima di tentare un altro aggiornamento. Per il rollback di un service pack, i controlli dei repository e della registrazione del prodotto sono particolarmente importanti, poiché un set di repository non corrispondente può riportare immediatamente il sistema in uno stato incoerente.

sudo zypper ref -fs
sudo zypper lr -u
sudo zypper verify

Per il ripristino del service pack, seguire le verifiche indicate nella Guida ufficiale all'aggiornamento di SLES , che richiede esplicitamente di controllare la configurazione del repository e la registrazione del prodotto dopo il rollback.

Ciò che un rollback root di Snapper non ripristina

Questa è la limitazione più importante da comprendere prima di utilizzare il rollback su un server di produzione. Lo snapshot root predefinito di SLES esclude diversi sottovolumi in modo che i dati volatili e i dati utente o delle applicazioni non vengano ripristinati inaspettatamente. L'elenco specifico del prodotto può includere /home, /opt, /usr/local, /srv, /tmp, /var, /run, e percorsi del bootloader specifici dell'architettura. Consultare la documentazione sui concetti di base di Snapper di SUSE per l'elenco corrente e le relative motivazioni.

Questa progettazione protegge i dati, ma crea un compromesso: il codice di sistema può tornare a una versione precedente, mentre i dati in un sottovolume escluso rimangono allo stato più recente. SUSE segnala diverse possibili conseguenze, tra cui /optla mancata corrispondenza tra software di terze parti, la modifica delle autorizzazioni e l'impossibilità per le applicazioni di comprendere i formati di dati scritti dopo la creazione dello snapshot.

Questo è particolarmente importante per i database e le applicazioni server. Se un aggiornamento ha incluso una migrazione dello schema o ha modificato i dati dell'applicazione in /varo /srv, un rollback di root potrebbe non annullare tale modifica dei dati. Verificare la procedura di downgrade o ripristino dell'applicazione prima di presumere che il solo snapshot di sistema sia sufficiente.

Errori comuni da evitare

• Eseguire il rollback prima di testare lo snapshot. Avviare prima lo snapshot di sola lettura è il flusso di lavoro SLES più sicuro perché consente di verificare lo stato di destinazione.
• Selezionare per errore uno snapshot successivo all'aggiornamento. Verificare il tipo, la data, la descrizione e la relazione pre/post anziché affidarsi solo al numero dello snapshot.
• Utilizzabile undochangeper transazioni di pacchetti completi. È utile per file selezionati; SUSE consiglia il metodo di avvio e rollback per un ripristino completo dei privilegi di root.
• Prevedere /varo /homeviaggiare all'indietro con la directory radice. Le esclusioni predefinite dei sottovolumi sono intenzionali.
• Ignorando il requisito del dispositivo singolo. SLES 15 SP7 documenta il supporto per il rollback della root avviabile per una root Btrfs su un singolo dispositivo.
• Tentativo di ripetere immediatamente l'aggiornamento. Innanzitutto, identificare la causa dell'errore, verificare i repository e determinare se l'errore è dovuto a un difetto del pacchetto, a un software di terze parti incompatibile, a spazio su disco insufficiente o a un problema di configurazione locale.

Se il sistema utilizza aggiornamenti transazionali

SLES può essere installato anche con il ruolo di server transazionale. Si tratta di un modello operativo diverso: gli aggiornamenti vengono applicati agli snapshot e attivati ​​al riavvio. Su questi sistemi, SUSE offre la possibilità transactional-update rollbackdi impostare uno snapshot come root predefinito. Non combinare una procedura di ripristino per server transazionale con un'installazione SLES convenzionale in modalità lettura/scrittura senza prima aver identificato il ruolo di sistema. Il comportamento ufficiale è descritto nella documentazione relativa agli aggiornamenti transazionali di SLES 15 SP7 .

Lista di controllo per il recupero

• Conferma /che si tratti di Btrfs, che la rootconfigurazione Snapper esista e che il file system root Btrfs si trovi su un unico dispositivo.
• Individua l'istantanea scattata immediatamente prima dell'aggiornamento non riuscito.
• Utilizzalo snapper statusquando snapper diffhai bisogno di comprendere la portata del cambiamento.
• Preferire la selezione selettiva undochangesolo per file chiaramente isolati.
• In caso di errore di aggiornamento del sistema, avviare lo snapshot candidato da GRUB e testarlo in modalità di sola lettura.
• Eseguire l'operazione snapper rollbacksolo dopo che il candidato si è comportato correttamente.
• Riavvia il sistema con l'opzione predefinita e verifica che la directory root ripristinata sia scrivibile.
• Aggiorna i repository, verifica lo stato dei pacchetti e controlla la registrazione dopo il ripristino del service pack.
• Prima di dichiarare completato il ripristino, esaminare i sottovolumi esclusi per individuare eventuali incongruenze di applicazione o formato dati.

Il compromesso principale è tra precisione e coerenza. Il ripristino selettivo dei file apporta meno modifiche, ma richiede di sapere esattamente cosa si è rotto. Un rollback di sistema testato apporta più modifiche, ma ripristina uno stato radice coerente basato su snapshot ed è più adatto in caso di aggiornamento non riuscito che ha interessato più componenti. Su SLES, il flusso di lavoro più sicuro consiste nell'utilizzare l'avvio snapshot di sola lettura come punto di decisione, piuttosto che rendere irreversibile il rollback prima di aver verificato il candidato.