Annullare in modo sicuro un aggiornamento SLES non riuscito con Snapper

Su un'installazione standard di SUSE Linux Enterprise Server (SLES) con root Btrfs e Snapper abilitato, il ripristino più sicuro consiste nell'avviare uno snapshot creato prima dell'aggiornamento non riuscito, testarlo in modalità di sola lettura e quindi eseguire sudo snapper rollback. Questo crea una nuova root scrivibile dallo stato testato; non ripristina ogni disco, sottovolume o database dell'applicazione.

Le attuali linee guida per l'amministrazione di SLES 15 SP7 utilizzano ancora questo flusso di lavoro di avvio e test. Prima di seguirlo, verificare che la macchina soddisfi il layout di rollback supportato da SUSE e identificare lo snapshot precedente per la transazione Zypper o YaST non riuscita.

Un rollback di Snapper ripristinerà l'intero server?

No. Il rollback del sistema avviabile si applica agli snapshot nella rootconfigurazione Snapper predefinita. SUSE documenta il supporto per la configurazione predefinita del sottovolume root, con Btrfs su un singolo dispositivo root e un boot loader installato e funzionante. Il rollback modifica il contenuto del sottovolume /; gli altri sottovolumi non sono inclusi. Nei layout SLES tipici, percorsi come /var, /srv, /opt, /usr/locale spesso /homesi trovano al di fuori dello snapshot. Un database o un servizio potrebbe quindi conservare i dati scritti dopo lo snapshot anche se i relativi pacchetti di sistema vengono ripristinati.

Prima di procedere con il rollback, esegui o verifica un backup separato dei dati importanti delle applicazioni. Evita questa procedura anche se hai modificato il layout predefinito del sottovolume Btrfs o se utilizzi una directory root multi-dispositivo: i requisiti di rollback avviabile documentati per SLES 15 SP7 non coprono tali configurazioni. Prima di procedere, consulta i requisiti di ripristino Snapper di SUSE .

Quale snapshot è stato creato prima dell'aggiornamento non riuscito?

Utilizza la configurazione Snapper per il file system root e confronta la coppia pre/post della transazione. Su un tipico sistema SLES con snapshot root Btrfs abilitati, Zypper e YaST creano snapshot intorno alle operazioni sui pacchetti. Lo snapshot pre rappresenta lo stato del root prima di tale operazione; lo snapshot post rappresenta lo stato dopo la sua esecuzione, inclusa una transazione parzialmente fallita.

1. Verifica che la configurazione radice esista con sudo snapper list-configs. Cerca una configurazione denominata root.
2. Conferma il tipo di filesystem root con findmnt -no FSTYPE /. Per questa procedura di rollback avviabile dovrebbe riportare btrfs. Quindi esegui sudo btrfs filesystem show /e conferma che il filesystem root riporta Total devices 1.
3. Elenca le coppie di transazioni con sudo snapper -c root list -t pre-post. Abbina la data e la descrizione all'aggiornamento non riuscito. Registra il numero nella Pre #colonna, non l'accoppiato Post #.
4. Analizza le differenze tra i due valori. Sostituisci PREe POSTcon i numeri visualizzati sul tuo dispositivo:

sudo snapper -c root status PRE..POST
sudo snapper -c root diff PRE..POST

Questi comandi elencano i percorsi modificati e le differenze tra i file. I numeri degli snapshot, le date, le descrizioni dei pacchetti e l'output variano a seconda dell'host; non copiare un numero di esempio da uno screenshot. Se non viene visualizzata alcuna coppia pertinente, verificare se Snapper è abilitato e se una policy di pulizia ha già rimosso lo snapshot. Uno snapshot mancante non può essere ricreato da Snapper in un secondo momento.

Come si fa a testare la vecchia radice prima di renderla permanente?

Riavvia e utilizza la voce snapshot del boot loader. Su SLES, scegli Start Bootloader from a read-only snapshot, quindi seleziona lo snapshot datato immediatamente prima della transazione non riuscita. Il menu di avvio etichetta le voci con la loro data e descrizione, che può includere zypp(zypper)o un'operazione YaST. Scegli lo snapshot pre-aggiornamento che hai registrato; non selezionare lo snapshot post solo perché la sua descrizione è più facile da riconoscere.

Accedi e verifica i servizi o le applicazioni che hanno riscontrato problemi. I file di root dello snapshot sono di sola lettura durante questa prova, quindi questo avvio da solo non modifica la directory root predefinita. Se lo snapshot non è corretto o il sistema continua a non funzionare, riavvia e prova un altro snapshot oppure utilizza il sistema di ripristino. Non forzare un rollback solo per rendere permanente la scelta del menu.

Quando è opportuno eseguire il rollback di Snapper?

Eseguire il rollback solo dopo che lo snapshot precedente si è avviato e ha superato i controlli. Da quello snapshot di sola lettura, eseguire:

sudo snapper rollback

Quindi riavvia il computer e seleziona la voce di avvio predefinita:

sudo reboot

Snapper conserva un'istantanea dello stato del sistema precedente al rollback e crea una nuova directory radice di lettura/scrittura basata sull'istantanea testata. Nel flusso di lavoro di avvio da snapshot documentato, non è necessario passare il vecchio numero dell'istantanea a questo comando. Il risultato è una nuova directory radice predefinita, non una conversione in scrittura dell'istantanea di sola lettura. Le istantanee possono essere successivamente rimosse dalle regole di pulizia, quindi è consigliabile copiare tutti i file necessari prima di fare affidamento su una vecchia istantanea di rollback come archivio a lungo termine.

Cosa bisogna verificare dopo il riavvio?

Avvia il sistema con l'opzione predefinita e verifica il ripristino effettivo, non solo il completamento del comando. Conferma lo stato previsto del kernel e dei pacchetti, esamina lo stato e i log del servizio non riuscito ed esegui un breve controllo a livello di applicazione. Infine, controlla il nuovo stato di Snapper:

sudo snapper -c root list

Per un normale aggiornamento di pacchetto, di solito è sufficiente verificare che la macchina si avvii dalla nuova directory radice. Se l'operazione non riuscita riguardava la migrazione di un service pack , seguire anche i controlli post-rollback di SUSE: aggiornare e ispezionare i repository, quindi verificare la registrazione:

sudo zypper ref -fs
sudo zypper lr
sudo SUSEConnect --status

I repository devono corrispondere al service pack a cui si è effettuato il ripristino e i prodotti installati devono essere registrati. Se la registrazione non viene ripristinata, la procedura di ripristino del service pack SLES 15 SP7 di SUSE descrive sudo SUSEConnect --rollbackil passaggio di riparazione. Tale comando di registrazione è specifico per il ripristino della migrazione; non eseguirlo per un normale aggiornamento dei pacchetti.

Se questo host utilizza transactional-update(ad esempio, un sistema SLE Micro transazionale), seguire la procedura di quel prodotto anziché applicare la classica sequenza di comandi SLES. La sua documentazione utilizza sudo transactional-update rollback SNAPSHOT_NUMBERper selezionare uno snapshot dal sistema in esecuzione e un flusso di lavoro separato per lo snapshot di sola lettura all'avvio quando la root corrente è danneggiata. Vedere le istruzioni di SUSE per il rollback degli aggiornamenti transazionali .