Revenire la SLES Btrfs Snapper după o actualizare eșuată: Ghid de recuperare sigură

O actualizare SLES eșuată nu înseamnă întotdeauna că trebuie să reinstalați serverul. Într-o instalare standard de SUSE Linux Enterprise Server care utilizează Btrfs pentru sistemul de fișiere rădăcină și are Snapper activat, puteți adesea să porniți o instantanee pre-actualizare, să o testați fără a modifica sistemul curent și apoi să transformați acea stare cunoscută în noua rădăcină cu posibilitate de scriere.

Decizia importantă nu este pur și simplu „care instantaneu este cel mai nou?”, ci „cât de mult ar trebui să revin la versiunea anterioară?”. O revenire completă la versiunea inițială a sistemului Snapper este potrivită atunci când o actualizare a modificat mai multe pachete, biblioteci, servicii sau fișiere de configurare, iar mașina nu se mai comportă fiabil. Dacă un singur fișier de configurare este greșit, restaurarea acelui fișier este de obicei mai puțin perturbatoare. Acest ghid explică ambele opțiuni și respectă modelul de recuperare SLES 15 SP7 documentat de SUSE, disponibil în octombrie 2026.

Alegeți metoda de recuperare înainte de a schimba ceva

SUSE face distincția între anularea modificărilor și o revenire la sistemul de fișiere. Anularea modificărilor compară instantaneele și anulează modificările fișierelor selectate. O revenire la sistemul de fișiere face ca un instantaneu să stea baza pentru o nouă versiune rădăcină cu posibilitate de scriere. SUSE recomandă în mod specific pornirea mai întâi a instantaneului țintă atunci când se efectuează o revenire la sistemul de fișiere rădăcină, deoarece acest lucru vă oferă șansa de a verifica candidatul înainte de a-l valida. Consultați Ghidul de administrare SLES 15 SP7 .

Pasul 1: Confirmați că acest server acceptă calea standard de rollback Snapper

Înainte de a alege o instantanee, confirmați trei lucruri: sistemul de fișiere rădăcină este Btrfs, Snapper are o configurație numită root, iar rădăcina Btrfs se află pe un singur dispozitiv. SUSE documentează suportul pentru rollback-ul bootabil pentru aspectul implicit al subvolumului rădăcină și precizează că sistemul de fișiere rădăcină Btrfs trebuie să raporteze un singur dispozitiv.

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

Dacă findmnt /raportează un sistem de fișiere precum XFS sau Ext4, opriți-l: fluxul de lucru de bootare cu instantaneu Btrfs nu este disponibil pentru acel sistem rădăcină. Dacă snapper list-configsnu are nicio rootintrare, este posibil ca instantaneele automate ale sistemului rădăcină să nu fi fost activate. De asemenea, opriți-l dacă btrfs filesystem show /raportează mai mult de un dispozitiv; documentația SLES 15 SP7 nu listează acel aspect ca fiind acceptat pentru revenirea la sistemul rădăcină bootabil.

Pasul 2: Identificați instantaneul de imediat înainte de actualizarea eșuată

Enumerați instantaneele și analizați data, tipul, relația anterioară instantaneului și descrierea acestora:

sudo snapper list

În configurația SLES implicită, activitatea YaST și Zypper poate crea perechi prede postinstantanee. O preinstantanee reprezintă starea sistemului de fișiere înainte de tranzacție; postinstantaneul corespunzător reprezintă starea ulterioară. Nu selectați o instantanee doar pentru că este mai veche decât eroarea. Potriviți marcajul de timp și descrierea instantaneului cu fereastra de actualizare.

Dacă modificarea eșuată a fost o migrare a unui pachet service pack, Ghidul de actualizare SLES 15 SP7 de la SUSE le spune administratorilor în mod specific să localizeze instantaneul creat imediat înainte de migrare și menționează că instantaneul relevant este marcat ca important.

Pasul 3: Inspectați ce s-ar schimba de fapt în imaginea de ansamblu a candidatului

Dacă sistemul actual încă pornește, comparați instantaneul candidat cu starea actuală înainte de repornire. Acest lucru poate dezvălui dacă actualizarea a atins doar un fișier de configurare sau a modificat un set larg de fișiere de sistem.

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

Când restaurarea selectivă este cel mai bun compromis

Dacă un fișier cunoscut este greșit și restul sistemului actualizat este funcțional, restaurarea doar a acelui fișier evită anularea modificărilor de sistem fără legătură. SUSE documentează acest formular:

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

Nu omiteți numele fișierului în mod accidental. Fără nume de fișiere, undochangese pot inversa toate fișierele modificate între cele două stări. SUSE avertizează că utilizarea restaurării fișierelor pentru a imita o revenire completă la rădăcină nu este metoda recomandată. Tranzacțiile pachetelor pot modifica multe fișiere interdependente, așa că o revenire completă testată este de obicei mai ușor de justificat atunci când eșecul actualizării este sistemic.

Pasul 4: Porniți instantaneul candidat din GRUB

Reporniți mașina. În meniul SLES GRUB 2, alegeți opțiunea de pornire a încărcătorului de boot dintr-un snapshot doar pentru citire, apoi selectați snapshot-ul care corespunde stării de dinainte de actualizare. Aspectul exact al ecranului poate varia în funcție de firmware și de configurația de boot, dar SLES 15 SP7 documentează intrarea ca Start Bootloader from a read-only snapshot .

Doar instantaneele din configurația implicită Snapper rootsunt bootabile prin acest mecanism SLES. Dacă meniul instantaneelor ​​lipsește, nu creați o intrare de boot. Verificați din nou dacă Snapper a fost activat, dacă aspectul rădăcină este încă structura implicită acceptată și dacă încărcătorul de boot instalat este funcțional.

Pasul 5: Testați instantaneul în timp ce rădăcina este doar pentru citire

După ce snapshot-ul pornește, verificați dacă rulați de pe acesta și dacă sistemul de fișiere rădăcină este doar pentru citire:

findmnt /
mount | grep ' on / '

Acum testați lucrurile care au eșuat după actualizare: pornirea serviciului, configurația rețelei, autentificarea, lansarea aplicației, comportamentul dependent de kernel sau alte verificări relevante. Evitați să tratați instantaneul doar pentru citire ca pe o pornire normală de producție. Unele operațiuni vor eșua pur și simplu pentru că partea instantanee a sistemului de fișiere rădăcină nu poate fi scrisă.

Dacă instantaneul nu este cel corect, reporniți sistemul și încercați un alt candidat. Până când nu executați comanda rollback, nu ați transformat acel instantaneu în noua funcție rădăcină de sistem cu posibilitate de scriere.

Pasul 6: Validați revenirea la versiunea inițială numai după ce instantaneul trece verificările.

Când instantaneul pornit se comportă conform așteptărilor, setează-l permanent:

sudo snapper rollback

Puteți adăuga o descriere pentru a face instantaneul rezultat mai ușor de identificat ulterior:

sudo snapper rollback -d "Rollback after failed update"

Conform documentației de administrare SLES, Snapper creează o instantanee a stării de dinainte de rollback și creează o nouă instantanee inscriptibilă care devine rădăcina implicită. Aceasta este o proprietate importantă de siguranță: rollback-ul nu suprascrie pur și simplu vechea rădăcină.

Reporniți după ce comanda se termină:

sudo reboot

La următoarea pornire, alegeți intrarea SLES implicită normală, în loc să porniți din nou vechea instantanee doar pentru citire.

Pasul 7: Verificați dacă rădăcina restaurată poate fi scrisă și este acum implicită

După bootarea normală, verificați lista de montare și snapshot-uri de la root:

findmnt /
sudo snapper list

Repetați verificările funcționale care inițial au eșuat. Dacă o aplicație încă eșuează, verificați dacă o parte a acelei aplicații se află într-un director pe care instantaneul rădăcină nu l-a inclus.

Pasul 8: Reîmprospătați repozitoriile și verificați starea pachetului

Pentru o actualizare obișnuită a pachetului, reîmprospătați repozitoriile și verificați dependențele pachetului înainte de a încerca o altă actualizare. Pentru o revenire la o versiune anterioară a unui service pack, verificările înregistrării repozitoriului și a produsului sunt deosebit de importante, deoarece un set de repozitorii nepotrivite poate readuce imediat sistemul într-o stare inconsistentă.

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

Pentru recuperarea pachetului service pack, urmați verificările din Ghidul oficial de actualizare SLES , care solicită în mod explicit verificarea configurației depozitului și a înregistrării produsului după revenirea la versiunea inițială.

Ce nu restaurează o revenire la root a Snapper

Aceasta este cea mai importantă limitare de înțeles înainte de a utiliza revenirea la versiunea inițială pe un server de producție. Instantaneul rădăcină SLES implicit exclude mai multe subvolume, astfel încât datele volatile și datele utilizatorilor sau ale aplicațiilor să nu fie anulate în mod neașteptat. Lista specifică produsului poate include /home, /opt, /usr/local, /srv, /tmp, /var, /run, și căi de bootloader specifice arhitecturii. Consultați documentația SUSE privind conceptele de bază Snapper pentru lista actuală și justificare.

Acest design protejează datele, dar creează un compromis: codul sistemului se poate muta înapoi, în timp ce datele dintr-un subvolum exclus rămân în starea mai nouă. SUSE semnalează câteva consecințe posibile, inclusiv /optnepotrivirea software-ului terț, modificarea permisiunilor și imposibilitatea ca aplicațiile să înțeleagă formatele de date scrise după realizarea instantaneului.

Acest lucru este important în special pentru bazele de date și aplicațiile de server. Dacă o actualizare a inclus o migrare a schemei sau a modificat datele aplicației sub /varsau /srv, o revenire la versiunea inițială (rollback) poate să nu anuleze modificarea datelor respective. Verificați procedura proprie de downgrade sau restaurare a aplicației înainte de a presupune că instantaneul sistemului este suficient.

Greșeli frecvente de evitat

• Revenirea la versiunea anterioară testării instantaneului. Pornirea mai întâi a instantaneului doar pentru citire este fluxul de lucru SLES mai sigur, deoarece vă permite să verificați starea țintă.
• Alegerea accidentală a unui instantaneu post-actualizare. Verificați tipul, data, descrierea și relația pre/post, în loc să vă bazați doar pe numărul instantaneului.
• Se utilizează undochangepentru o tranzacție a întregului pachet. Este utilă pentru anumite fișiere; SUSE recomandă metoda boot-and-rollback pentru recuperarea completă de la root.
• Se așteaptă /varsau /homese deplasează înapoi cu rădăcina. Excluderile implicite ale subvolumelor sunt intenționate.
• Ignorând cerința unui singur dispozitiv. SLES 15 SP7 documentează suportul pentru rollback-ul root bootabil pentru un root Btrfs pe un singur dispozitiv.
• Reîncercarea aceleiași actualizări imediate. Mai întâi identificați motivul eșuării actualizării, confirmați depozitele și stabiliți dacă eroarea a fost un defect al pachetului, un software terț incompatibil, spațiu insuficient pe disc sau o problemă de configurare locală.

Dacă sistemul utilizează actualizări tranzacționale

SLES poate fi instalat și cu rolul de Server tranzacțional. Acesta este un model de operare diferit: actualizările sunt aplicate instantaneelor ​​și activate la repornire. Pe aceste sisteme, SUSE oferă posibilitatea transactional-update rollbackde a seta un instantaneu ca rădăcină implicită. Nu combinați o rețetă de recuperare de tip server tranzacțional într-o instalare SLES convențională de citire-scriere fără a identifica mai întâi rolul de sistem. Comportamentul oficial este descris în documentația actualizărilor tranzacționale SLES 15 SP7 .

Listă de verificare pentru recuperare

• Confirmați /că este Btrfs, că rootconfigurația Snapper există și că sistemul de fișiere rădăcină Btrfs se află pe un dispozitiv.
• Identificați instantaneul imediat înainte de actualizarea eșuată.
• Folosește snapper statusși snapper diffatunci când trebuie să înțelegi amploarea schimbării.
• Preferați opțiunea selectivă undochangedoar pentru fișierele clar izolate.
• În cazul eșecului de actualizare sistemică, porniți instantaneul candidat din GRUB și testați-l doar în citire.
• Candidatul snapper rollbackse comportă corect.
• Reporniți intrarea implicită normală și verificați dacă rădăcina restaurată poate fi scrisă.
• Reîmprospătați repozitoriile, verificați starea pachetului și verificați înregistrarea după recuperarea pachetului service pack.
• Verificați subvolumele excluse pentru neconcordanțe de aplicație sau format de date înainte de a declara recuperarea finalizată.

Compromisul central este precizia versus consecvența. Restaurarea selectivă a fișierelor modifică mai puțin, dar necesită să știți exact ce a defect. O revenire la sistemul testat modifică mai mult, dar restaurează o stare rădăcină coerentă, înregistrată ca instantaneu, și este mai potrivită pentru o actualizare eșuată care a afectat mai multe componente. Pe SLES, cel mai sigur flux de lucru este să utilizați bootarea instantaneului doar pentru citire ca punct de decizie, mai degrabă decât să faceți revenirea la sistemul ireversibilă înainte de a verifica candidatul.