Een mislukte SLES-update veilig terugdraaien met Snapper

Op een standaard SUSE Linux Enterprise Server (SLES)-installatie met een Btrfs-root en Snapper ingeschakeld, is de veiligste herstelmethode het opstarten van een snapshot die is gemaakt vóór de mislukte update, deze te testen terwijl deze alleen-lezen is, en vervolgens het commando uit te voeren sudo snapper rollback. Dit creëert een nieuwe beschrijfbare root vanuit de geteste status; het herstelt niet elke schijf, subvolume of applicatiedatabase.

De huidige SLES 15 SP7-beheerhandleiding maakt nog steeds gebruik van deze opstart- en testworkflow. Controleer voordat u deze volgt of de machine voldoet aan de door SUSE ondersteunde rollback-indeling en identificeer de pre- snapshot voor de mislukte Zypper- of YaST-transactie.

Zal een Snapper-rollback de volledige server herstellen?

Nee. Het terugdraaien van een opstartbaar systeem is van toepassing op snapshots in de standaard Snapper- rootconfiguratie. SUSE-documentatie ondersteunt de standaard root-subvolume-indeling, met Btrfs op één root-apparaat en een werkende, geïnstalleerde bootloader. Het terugdraaien wijzigt de inhoud van subvolume /; andere subvolumes worden niet meegenomen. In typische SLES-lay-outs bevinden paden zoals /var, /srv, /opt, /usr/local, en zich vaak /homebuiten de snapshot. Een database of service kan daarom gegevens behouden die na de snapshot zijn geschreven, zelfs als de systeempakketten worden teruggezet.

Maak een aparte back-up van belangrijke applicatiegegevens of controleer deze voordat u een rollback uitvoert. Vermijd deze procedure ook als u de standaard Btrfs-subvolume-indeling hebt gewijzigd of een root met meerdere apparaten gebruikt: de gedocumenteerde opstartbare rollback-vereisten van SLES 15 SP7 dekken deze configuraties niet. Lees de Snapper-herstelvereisten van SUSE voordat u verdergaat.

Welke momentopname is gemaakt vóór de mislukte update?

Gebruik de Snapper-configuratie voor het rootbestandssysteem en vergelijk de pre- en post-snapshots van de transactie. Op een typisch SLES-systeem met ingeschakelde Btrfs rootsnapshots maken Zypper en YaST snapshots rondom pakketbewerkingen. De presnapshot vertegenwoordigt de rootstatus vóór die bewerking; de postsnapshot vertegenwoordigt de status nadat de bewerking is uitgevoerd, inclusief een gedeeltelijk mislukte transactie.

1. Controleer of de hoofdconfiguratie bestaat met sudo snapper list-configs. Zoek naar een configuratie met de naam root.
2. Bevestig het type rootbestandssysteem met findmnt -no FSTYPE /. Voor deze opstartbare rollbackprocedure moet het rapporteren btrfs. Voer vervolgens uit sudo btrfs filesystem show /en controleer of het rootbestandssysteem rapporteert Total devices 1.
3. Lijst transactieparen met sudo snapper -c root list -t pre-post. Koppel de datum en beschrijving aan de mislukte update. Noteer het nummer in de Pre #kolom, niet het bijbehorende paar Post #.
4. Bekijk wat er tussen de twee is veranderd. Vervang PREen POSTdoor de nummers die op uw apparaat worden weergegeven:

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

Deze opdrachten tonen gewijzigde paden en bestandsverschillen. Snapshotnummers, datums, pakketbeschrijvingen en uitvoer variëren per host; kopieer geen voorbeeldnummer uit een schermafbeelding. Als er geen relevant paar wordt weergegeven, controleer dan of Snapper is ingeschakeld en of een opschoonbeleid de snapshot al heeft verwijderd. Een ontbrekende snapshot kan achteraf niet door Snapper opnieuw worden aangemaakt.

Hoe test je de oude root voordat je deze permanent maakt?

Start de computer opnieuw op en gebruik de snapshot-optie van de bootloader. Kies in SLES de optie Start Bootloader from a read-only snapshoten selecteer vervolgens de snapshot van direct vóór de mislukte transactie. Het opstartmenu labelt de items met hun datum en beschrijving, waaronder bijvoorbeeld zypp(zypper)een YaST-bewerking. Kies de snapshot van vóór de update die u hebt gemaakt; selecteer niet de snapshot van na de update, ook al is de beschrijving daarvan makkelijker te herkennen.

Log in en test de services of applicaties die niet werken. De rootbestanden van de snapshot zijn tijdens deze test alleen-lezen, dus deze opstartprocedure alleen wijzigt de standaard rootmap niet. Als het de verkeerde snapshot is of als het systeem nog steeds niet werkt, start dan opnieuw op en probeer een andere snapshot of gebruik het herstelsysteem. Forceer geen terugdraaiing alleen om de menuoptie permanent te maken.

Wanneer moet je snapper rollback uitvoeren?

Voer de rollback pas uit nadat de oudere snapshot is opgestart en aan uw controles voldoet. Voer vanuit die alleen-lezen snapshot het volgende commando uit:

sudo snapper rollback

Start vervolgens de computer opnieuw op en kies de normale standaard opstartoptie:

sudo reboot

Snapper bewaart een momentopname van de systeemstatus van vóór de rollback en creëert een nieuwe lees-schrijfbare root op basis van de geteste momentopname. U hoeft het oude momentopnamenummer niet aan dit commando door te geven in de gedocumenteerde workflow voor opstarten vanaf een momentopname. Het resultaat is een nieuwe standaard root, geen beschrijfbare conversie van de alleen-lezen momentopname zelf. Momentopnamen kunnen later worden verwijderd door opschoonregels, dus kopieer alle benodigde bestanden voordat u een oudere rollback-momentopname als archief voor de lange termijn gebruikt.

Wat moet je controleren na het opnieuw opstarten?

Start de standaard opstartprocedure en controleer het daadwerkelijke herstel, niet alleen of de opdracht is voltooid. Bevestig de verwachte kernel- en pakketstatus, bekijk de status en logboeken van de mislukte service en voer een kleine controle op applicatieniveau uit. Inspecteer vervolgens de nieuwe status van Snapper:

sudo snapper -c root list

Bij een gewone pakketupdate is dit meestal voldoende om te bevestigen dat de machine opstart vanaf de nieuwe root. Als de mislukte bewerking een servicepackmigratie was , volg dan ook de SUSE-controles na de rollback: vernieuw en inspecteer de repositories en controleer vervolgens de registratie.

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

De repositories moeten overeenkomen met het servicepack waarnaar u bent teruggekeerd, en de geïnstalleerde producten moeten geregistreerd zijn. Als de registratie niet wordt hersteld, raadpleeg dan de procedure voor het terugdraaien van servicepacks in SUSE SLES 15 SP7sudo SUSEConnect --rollback als herstelstap. Deze registratieopdracht is specifiek voor herstel na een migratie; voer deze niet uit voor een routinematige pakketupdate.

Als deze host transactional-updatebijvoorbeeld gebruikmaakt van een transactioneel SLE Micro-systeem, volg dan de procedure van dat product in plaats van de klassieke SLES-opdrachtenreeks toe te passen. De documentatie beschrijft een aparte procedure sudo transactional-update rollback SNAPSHOT_NUMBERvoor het selecteren van een snapshot van het draaiende systeem en een aparte workflow voor het maken van een alleen-lezen-snapshot bij het opstarten, wanneer de huidige root beschadigd is. Zie de instructies van SUSE voor het terugdraaien van transactionele updates .