Sicheres Zurücksetzen eines fehlgeschlagenen SLES-Updates mit Snapper

Bei einer Standardinstallation von SUSE Linux Enterprise Server (SLES) mit Btrfs-Root-Verzeichnis und aktiviertem Snapper ist die sicherste Wiederherstellung, einen vor dem fehlgeschlagenen Update erstellten Snapshot zu starten, ihn im schreibgeschützten Zustand zu testen und anschließend den Befehl `snapshot --reset` auszuführen sudo snapper rollback. Dadurch wird ein neues beschreibbares Root-Verzeichnis aus dem getesteten Zustand erstellt; dabei werden weder alle Festplatten, Subvolumes noch Anwendungsdatenbanken zurückgesetzt.

Die aktuelle Administrationsanleitung für SLES 15 SP7 verwendet weiterhin diesen Boot- und Test-Workflow. Bevor Sie diesen befolgen, vergewissern Sie sich, dass das System die von SUSE unterstützte Rollback-Konfiguration erfüllt und ermitteln Sie den Pre- Snapshot für die fehlgeschlagene Zypper- oder YaST-Transaktion.

Wird durch ein Snapper-Rollback der gesamte Server wiederhergestellt?

Nein. Ein Rollback des bootfähigen Systems gilt für Snapshots in der Standard-Snapper- rootKonfiguration. SUSE dokumentiert die Unterstützung für die standardmäßige Root-Subvolume-Anordnung mit Btrfs auf einem einzelnen Root-Gerät und einem funktionierenden installierten Bootloader. Der Rollback ändert den Inhalt des Subvolumes `/root` /; andere Subvolumes sind nicht betroffen. Bei typischen SLES-Layouts liegen Pfade wie /var` /root`, /srv` /opt/root` /usr/local, `/root` und `/root` oft /homeaußerhalb des Snapshots. Eine Datenbank oder ein Dienst kann daher Daten beibehalten, die nach dem Snapshot geschrieben wurden, selbst wenn die zugehörigen Systempakete auf den vorherigen Stand zurückgesetzt werden.

Erstellen oder überprüfen Sie eine separate Sicherung wichtiger Anwendungsdaten, bevor Sie ein Rollback durchführen. Vermeiden Sie dieses Verfahren außerdem, wenn Sie das Standard-Btrfs-Subvolume-Layout geändert oder ein Root-Verzeichnis mit mehreren Geräten verwendet haben: Die dokumentierten Anforderungen für ein bootfähiges Rollback unter SLES 15 SP7 decken diese Konfigurationen nicht ab. Lesen Sie die Snapper-Wiederherstellungsanforderungen von SUSE, bevor Sie fortfahren.

Welcher Snapshot wurde vor dem fehlgeschlagenen Update erstellt?

Verwenden Sie die Snapper-Konfiguration für das Root-Dateisystem und vergleichen Sie die Vorher- und Nachher-Snapshots der Transaktion. Auf einem typischen SLES-System mit aktivierten Btrfs-Root-Snapshots erstellen Zypper und YaST Snapshots um Paketoperationen herum. Der Vorher-Snapshot repräsentiert den Zustand des Root-Dateisystems vor dieser Operation; der Nachher-Snapshot repräsentiert den Zustand nach deren Ausführung, einschließlich einer teilweise fehlgeschlagenen Transaktion.

1. Prüfen Sie, ob die Root-Konfiguration existiert sudo snapper list-configs. Suchen Sie nach einer Konfiguration mit dem Namen root.
2. Bestätigen Sie den Root-Dateisystemtyp mit findmnt -no FSTYPE /. Für dieses bootfähige Rollback-Verfahren sollte die Meldung erscheinen btrfs. Führen Sie anschließend aus sudo btrfs filesystem show /und bestätigen Sie, dass das Root-Dateisystem die Meldung meldet Total devices 1.
3. Listen Sie die Transaktionspaare auf sudo snapper -c root list -t pre-post. Ordnen Sie Datum und Beschreibung der fehlgeschlagenen Aktualisierung zu. Notieren Sie die Nummer in der Pre #Spalte, nicht die zugehörige Transaktion Post #.
4. Prüfen Sie, welche Änderungen sich zwischen den beiden Werten ergeben haben. Ersetzen Sie PREund POSTdurch die auf Ihrem Gerät angezeigten Zahlen:

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

Diese Befehle listen geänderte Pfade und Dateiunterschiede auf. Snapshot-Nummern, Datumsangaben, Paketbeschreibungen und die Ausgabe variieren je nach Host; kopieren Sie keine Beispielnummer aus einem Screenshot. Falls kein passendes Paar angezeigt wird, prüfen Sie, ob Snapper aktiviert ist und ob eine Bereinigungsrichtlinie den Snapshot bereits entfernt hat. Ein fehlender Snapshot kann von Snapper nachträglich nicht wiederhergestellt werden.

Wie testet man die alte Root-Version, bevor man sie endgültig festlegt?

Starten Sie den Computer neu und verwenden Sie den Snapshot-Eintrag des Bootloaders. Wählen Sie unter SLES die Option „Bootmenü“ Start Bootloader from a read-only snapshotund anschließend den Snapshot, der unmittelbar vor der fehlgeschlagenen Transaktion datiert ist. Die Einträge im Bootmenü sind mit Datum und Beschreibung gekennzeichnet, die beispielsweise zypp(zypper)„YaST-Operation“ oder „Update“ enthalten können. Wählen Sie den Snapshot vor dem Update, den Sie aufgezeichnet haben; wählen Sie nicht den Snapshot nach dem Update, nur weil dessen Beschreibung leichter verständlich ist.

Melden Sie sich an und testen Sie die Dienste oder Anwendungen, die nicht funktioniert haben. Die Stammdateien des Snapshots sind während dieses Tests schreibgeschützt, daher ändert dieser Neustart allein das Standard-Stammverzeichnis nicht. Falls es sich um den falschen Snapshot handelt oder das System weiterhin nicht funktioniert, starten Sie es neu und versuchen Sie es mit einem anderen Snapshot oder verwenden Sie das Rettungssystem. Erzwingen Sie kein Rollback, nur um die Menüauswahl dauerhaft zu speichern.

Wann sollte man Snapper Rollback ausführen?

Führen Sie das Rollback erst durch, nachdem der ältere Snapshot gestartet wurde und Ihre Prüfungen bestanden hat. Führen Sie anschließend von diesem schreibgeschützten Snapshot aus Folgendes aus:

sudo snapper rollback

Starten Sie das System anschließend neu und wählen Sie den normalen Standard-Starteintrag aus:

sudo reboot

Snapper speichert einen Snapshot des Systemzustands vor dem Rollback und erstellt basierend auf diesem Snapshot ein neues, beschreibbares Root-Verzeichnis. Im dokumentierten Workflow zum Booten von einem Snapshot wird die alte Snapshot-Nummer nicht an diesen Befehl übergeben. Das Ergebnis ist ein neues Standard-Root-Verzeichnis, keine beschreibbare Konvertierung des schreibgeschützten Snapshots selbst. Snapshots können später durch Bereinigungsregeln entfernt werden. Kopieren Sie daher alle benötigten Dateien, bevor Sie einen älteren Rollback-Snapshot als Langzeitarchiv verwenden.

Was sollten Sie nach dem Neustart überprüfen?

Starten Sie den Standardeintrag und überprüfen Sie die tatsächliche Wiederherstellung, nicht nur die Ausführung des Befehls. Bestätigen Sie den erwarteten Kernel- und Paketstatus, überprüfen Sie den Status und die Protokolle des ausgefallenen Dienstes und führen Sie eine kleine Anwendungsprüfung durch. Überprüfen Sie anschließend den neuen Status von Snapper.

sudo snapper -c root list

Bei einem normalen Paketupdate genügt es in der Regel, zu bestätigen, dass der Rechner vom neuen Stammverzeichnis bootet. Falls es sich bei dem fehlgeschlagenen Vorgang um eine Service-Pack-Migration handelte , führen Sie zusätzlich die SUSE-Prüfungen nach dem Rollback durch: Aktualisieren und überprüfen Sie die Paketquellen und anschließend die Registrierung.

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

Die Paketquellen sollten mit dem Service Pack übereinstimmen, zu dem Sie zurückgekehrt sind, und die installierten Produkte sollten registriert sein. Falls die Registrierung nicht wiederhergestellt wird, beschreibt die Rollback-Prozedur für das Service Pack von SUSE SLES 15 SP7sudo SUSEConnect --rollback den Reparaturschritt. Dieser Registrierungsbefehl ist speziell für die Wiederherstellung nach einer Migration vorgesehen; verwenden Sie ihn nicht für ein reguläres Paketupdate.

Wenn dieser Host transactional-updatebeispielsweise ein transaktionales SLE Micro-System verwendet, befolgen Sie die Vorgehensweise dieses Produkts anstelle der klassischen SLES-Befehlssequenz. Die zugehörige Dokumentation beschreibt sudo transactional-update rollback SNAPSHOT_NUMBERdie Auswahl eines Snapshots aus dem laufenden System und einen separaten Workflow für einen Boot-Read-Only-Snapshot, falls das aktuelle Root-Verzeichnis beschädigt ist. Beachten Sie die Anweisungen zum Rollback von Transaktionsupdates in SUSE .