Revenirea în siguranță la o actualizare SLES eșuată cu Snapper

Pe o instalare standard SUSE Linux Enterprise Server (SLES) cu o rădăcină Btrfs și Snapper activat, cea mai sigură recuperare este pornirea unui snapshot realizat înainte de actualizarea eșuată, testarea acestuia cât timp este doar în citire și apoi rularea acestuia sudo snapper rollback. Aceasta creează o nouă rădăcină cu posibilitate de scriere din starea testată; nu derulează înapoi fiecare disc, subvolum sau bază de date a aplicației.

Ghidul actual de administrare SLES 15 SP7 utilizează în continuare acest flux de lucru de tip boot-and-test. Înainte de a-l urma, confirmați că mașina respectă schemele de rollback acceptate de SUSE și identificați instantaneul inițial pentru tranzacția Zypper sau YaST eșuată.

O revenire la versiunea inițială a Snapper va restaura întregul server?

Nu. Revenirea la versiunea inițială a sistemului bootabil se aplică instantaneelor ​​din rootconfigurația implicită Snapper. SUSE documentează suportul pentru aranjamentul implicit al subvolumului rădăcină, cu Btrfs pe un singur dispozitiv rădăcină și un încărcător de boot instalat funcțional. Revenirea la versiunea inițială modifică conținutul subvolumului /; alte subvolume nu sunt incluse. În structurile SLES tipice, căile precum /var, /srv, /opt, /usr/localși /homese află adesea în afara instantaneului. Prin urmare, o bază de date sau un serviciu poate păstra datele scrise după instantaneu chiar și în timp ce pachetele sale de sistem revin la versiunea inițială.

Realizați sau verificați o copie de rezervă separată a datelor importante ale aplicației înainte de a efectua o revenire la versiunea inițială. De asemenea, evitați această procedură dacă ați modificat aspectul implicit al subvolumului Btrfs sau utilizați o unitate rădăcină cu mai multe dispozitive: cerințele documentate pentru revenirea la versiunea inițială bootabilă din SLES 15 SP7 nu acoperă aceste configurații. Citiți cerințele de recuperare Snapper de la SUSE înainte de a continua.

Ce instantaneu a fost făcut înainte de actualizarea eșuată?

Folosește configurația Snapper pentru sistemul de fișiere rădăcină și compară perechea pre/post a tranzacției. Pe un sistem SLES tipic cu instantaneele rădăcină Btrfs activate, Zypper și YaST creează instantanee în jurul operațiunilor de pe pachet. Instantaneul pre reprezintă starea rădăcină înainte de operația respectivă; instantaneul post reprezintă starea de după rularea acesteia, inclusiv o tranzacție parțial eșuată.

1. Verificați dacă există configurația rădăcină cu sudo snapper list-configs. Căutați o configurație numită root.
2. Confirmați tipul sistemului de fișiere rădăcină cu findmnt -no FSTYPE /. Pentru această procedură de rollback bootabilă, ar trebui să raporteze btrfs. Apoi, rulați sudo btrfs filesystem show /și confirmați rapoartele sistemului de fișiere rădăcină Total devices 1.
3. Enumerați perechile de tranzacții cu sudo snapper -c root list -t pre-post. Potriviți data și descrierea cu actualizarea eșuată. Înregistrați numărul în Pre #coloană, nu tranzacțiile pereche Post #.
4. Verificați ce s-a schimbat între pereche. Înlocuiți PREși POSTcu numerele afișate pe aparat:

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

Aceste comenzi listează căile modificate și diferențele de fișiere. Numerele, datele, descrierile pachetelor și ieșirea instantaneelor ​​variază în funcție de gazdă; nu copiați un număr exemplu dintr-o captură de ecran. Dacă nu apare nicio pereche relevantă, verificați dacă Snapper este activat și dacă o politică de curățare a eliminat deja instantaneul. Un instantaneu lipsă nu poate fi recreat de Snapper ulterior.

Cum testezi rădăcina veche înainte de a o face permanentă?

Reporniți și utilizați intrarea snapshot a încărcătorului de boot. În SLES, alegeți Start Bootloader from a read-only snapshot, apoi selectați snapshot-ul cu data imediat anterioară tranzacției eșuate. Meniul de boot etichetează intrările cu data și descrierea lor, care pot include zypp(zypper)sau o operațiune YaST. Alegeți snapshot-ul pre-actualizare pe care l-ați înregistrat; nu selectați snapshot-ul post doar pentru că descrierea sa este mai ușor de recunoscut.

Conectați-vă și testați serviciile sau aplicațiile care au eșuat. Fișierele rădăcină ale instantaneului sunt doar pentru citire în timpul acestei perioade de probă, deci această pornire nu modifică rădăcina implicită. Dacă este instantaneul greșit sau sistemul tot eșuează, reporniți sistemul și încercați un alt instantaneu sau utilizați sistemul de salvare. Nu forțați o revenire la versiunea inițială doar pentru a face permanentă opțiunea din meniu.

Când ar trebui să rulezi rollback-ul snapper?

Executați revenirea la versiunea inițială numai după ce snapshot-ul mai vechi pornește și trece verificările. Din acel snapshot doar pentru citire, executați:

sudo snapper rollback

Apoi reporniți sistemul și alegeți intrarea de boot implicită normală:

sudo reboot

Snapper păstrează o instantanee a stării sistemului de dinainte de revenire la versiunea inițială și creează o nouă rădăcină de citire-scriere bazată pe instantaneul testat. Nu transmiteți numărul vechiului instantaneu acestei comenzi în fluxul de lucru documentat de pornire din instantaneu. Rezultatul este o nouă rădăcină implicită, nu o conversie cu posibilitate de scriere a instantaneului doar de citire în sine. Instantaneele pot fi eliminate ulterior prin reguli de curățare, așadar copiați toate fișierele necesare înainte de a vă baza pe un instantaneu de revenire la versiunea inițială mai vechi ca arhivă pe termen lung.

Ce ar trebui să verifici după repornire?

Pornește intrarea implicită și verifică recuperarea propriu-zisă, nu doar finalizarea comenzii. Confirmă starea așteptată a kernelului și a pachetului, examinează starea și jurnalele serviciului eșuat și rulează o mică verificare la nivel de aplicație. Apoi inspectează noua stare a lui Snapper:

sudo snapper -c root list

Pentru o actualizare obișnuită a unui pachet, acest lucru este de obicei suficient pentru a confirma că mașina pornește de la noua versiune rădăcină. Dacă operațiunea eșuată a fost o migrare a unui service pack , urmați și verificările post-rollback ale SUSE: actualizați și inspectați repozitoriile, apoi verificați înregistrarea:

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

Depozitele ar trebui să corespundă cu service pack-ul la care ați returnat pachetul, iar produsele instalate ar trebui înregistrate. Dacă înregistrarea nu este restaurată, procedura de rollback a service pack-ului SLES 15 SP7 de la SUSE este documentată sudo SUSEConnect --rollbackca pas de reparare. Comanda de înregistrare este specifică recuperării migrării; nu o rulați pentru o actualizare de rutină a pachetului.

Dacă această gazdă folosește transactional-update(de exemplu, un sistem tranzacțional SLE Micro), urmați procedura produsului respectiv în loc să aplicați secvența clasică de comenzi SLES. Documentația sa folosește sudo transactional-update rollback SNAPSHOT_NUMBERpentru selectarea unui snapshot din sistemul care rulează și un flux de lucru separat pentru boot-read-only-snapshot atunci când rădăcina curentă este defectă. Consultați instrucțiunile SUSE pentru revenirea la actualizarea tranzacțională .