Przywracanie ustawień SLES Btrfs Snapper po nieudanej aktualizacji: przewodnik bezpiecznego odzyskiwania

Nieudana aktualizacja SLES nie zawsze oznacza konieczność ponownej instalacji serwera. W standardowej instalacji SUSE Linux Enterprise Server, która używa Btrfs jako głównego systemu plików i ma włączoną funkcję Snapper, często można uruchomić migawkę sprzed aktualizacji, przetestować ją bez zmiany bieżącego systemu, a następnie przekształcić ten znany, dobry stan w nowy, zapisywalny katalog główny.

Ważną decyzją nie jest po prostu pytanie: „która migawka jest najnowsza?”, ale „jak bardzo powinienem ją cofnąć?”. Pełne cofnięcie systemu Snapper jest wskazane, gdy aktualizacja zmieniła kilka pakietów, bibliotek, usług lub plików konfiguracyjnych, a komputer przestał działać niezawodnie. Jeśli tylko jeden plik konfiguracyjny jest nieprawidłowy, przywrócenie go jest zazwyczaj mniej uciążliwe. Niniejszy przewodnik wyjaśnia obie opcje i opiera się na modelu odzyskiwania systemu SLES 15 SP7 udokumentowanym przez firmę SUSE i dostępnym w październiku 2026 roku.

Wybierz metodę odzyskiwania przed wprowadzeniem jakichkolwiek zmian

SUSE odróżnia cofanie zmian od wycofywania systemu . Cofanie zmian porównuje migawki i cofa wybrane zmiany w plikach. Cofanie tworzy stan migawki jako podstawę dla nowego, zapisywalnego katalogu głównego. SUSE szczególnie zaleca, aby przed cofnięciem systemu plików głównego najpierw uruchomić docelową migawkę, ponieważ daje to możliwość weryfikacji kandydata przed jego zatwierdzeniem. Zobacz Podręcznik administratora SLES 15 SP7 .

Krok 1: Sprawdź, czy ten serwer obsługuje standardową ścieżkę przywracania Snappera

Przed wyborem migawki należy potwierdzić trzy rzeczy: system plików główny to Btrfs, Snapper ma konfigurację o nazwie root, a system główny Btrfs znajduje się na jednym urządzeniu. SUSE dokumentuje obsługę przywracania rozruchu dla domyślnego układu podwoluminów głównych i stwierdza, że ​​system plików główny Btrfs musi zgłaszać jedno urządzenie.

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

Jeśli findmnt /zgłasza system plików taki jak XFS lub Ext4, zatrzymaj: przepływ pracy rozruchu migawek Btrfs nie jest dostępny dla tego katalogu głównego. Jeśli snapper list-configsnie ma rootwpisu, automatyczne migawki katalogu głównego mogły nie zostać włączone. Zatrzymaj również, jeśli btrfs filesystem show /zgłasza więcej niż jedno urządzenie; dokumentacja systemu SLES 15 SP7 nie wymienia tego układu jako obsługiwanego dla rozruchowego przywracania katalogu głównego.

Krok 2: Zidentyfikuj migawkę wykonaną bezpośrednio przed nieudaną aktualizacją

Wypisz migawki i sprawdź ich datę, typ, relację przed migawką i opis:

sudo snapper list

W domyślnej konfiguracji SLES, YaST i aktywność Zypper mogą tworzyć pary premigawek post. preMigawka reprezentuje stan systemu plików przed transakcją; odpowiadająca jej postmigawka reprezentuje stan po niej. Nie wybieraj migawki tylko dlatego, że jest starsza niż awaria. Dopasuj znacznik czasu i opis migawki do okna aktualizacji.

Jeśli nieudana zmiana była migracją pakietu Service Pack, w Podręczniku uaktualnienia SLES 15 SP7 firmy SUSE wyraźnie napisano, że administratorzy muszą zlokalizować migawkę utworzoną bezpośrednio przed migracją i że odpowiednia migawka jest oznaczona jako ważna.

Krok 3: Sprawdź, co faktycznie zmieniłoby zdjęcie kandydata

Jeśli obecny system nadal się uruchamia, porównaj migawkę kandydującą ze stanem obecnym przed ponownym uruchomieniem. Może to wykazać, czy aktualizacja dotyczyła tylko jednego pliku konfiguracyjnego, czy też szerokiego zestawu plików systemowych.

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

Kiedy selektywne przywracanie jest lepszym rozwiązaniem

Jeśli jeden znany plik jest uszkodzony, a reszta zaktualizowanego systemu działa prawidłowo, przywrócenie tylko tego pliku pozwala uniknąć cofnięcia niezwiązanych z nim zmian w systemie. SUSE dokumentuje ten formularz:

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

Nie pomijaj nazwy pliku przypadkowo. Bez nazw plików undochangemożna cofnąć wszystkie zmiany w plikach między dwoma stanami. SUSE ostrzega, że ​​używanie przywracania plików do imitowania pełnego wycofania z poziomu roota nie jest zalecaną metodą. Transakcje pakietów mogą zmieniać wiele współzależnych plików, dlatego zazwyczaj łatwiej jest przeprowadzić pełne, przetestowane wycofanie, gdy błąd aktualizacji ma charakter systemowy.

Krok 4: Uruchom migawkę kandydata z GRUB

Uruchom ponownie komputer. W menu SLES GRUB 2 wybierz opcję uruchomienia bootloadera z migawki tylko do odczytu, a następnie wybierz migawkę odpowiadającą stanowi sprzed aktualizacji. Dokładny układ ekranu może się różnić w zależności od oprogramowania sprzętowego i konfiguracji rozruchu, ale w SLES 15 SP7 wpis ten jest opisany jako „ Uruchom bootloader z migawki tylko do odczytu” .

Tylko migawki z domyślnej rootkonfiguracji Snappera są możliwe do uruchomienia za pośrednictwem tego mechanizmu SLES. Jeśli menu migawek jest niedostępne, nie twórz wpisu rozruchowego. Sprawdź ponownie, czy Snapper został włączony, czy układ główny nadal jest domyślnie obsługiwaną strukturą i czy zainstalowany program ładujący działa.

Krok 5: Przetestuj migawkę, gdy katalog główny jest tylko do odczytu

Po uruchomieniu migawki sprawdź, czy rzeczywiście z niej korzystasz i czy główny system plików jest tylko do odczytu:

findmnt /
mount | grep ' on / '

Teraz przetestuj elementy, które nie powiodły się po aktualizacji: uruchamianie usług, konfigurację sieci, uwierzytelnianie, uruchamianie aplikacji, zachowanie zależne od jądra i inne istotne kontrole. Unikaj traktowania migawki tylko do odczytu jako normalnego rozruchu produkcyjnego. Niektóre operacje zakończą się niepowodzeniem tylko dlatego, że nie można zapisać części głównego systemu plików utworzonej w migawce.

Jeśli migawka nie jest prawidłowa, zrestartuj komputer i wypróbuj inną. Dopóki nie uruchomisz polecenia rollback, migawka nie zostanie ustawiona jako nowy, zapisywalny katalog główny systemu.

Krok 6: Zatwierdź wycofanie dopiero po pomyślnym przejściu kontroli migawki

Gdy uruchomiona migawka zachowuje się zgodnie z oczekiwaniami, należy ją uczynić trwałą:

sudo snapper rollback

Możesz dodać opis, aby później łatwiej było zidentyfikować utworzoną migawkę:

sudo snapper rollback -d "Rollback after failed update"

Zgodnie z dokumentacją administracyjną SLES, Snapper tworzy migawkę stanu sprzed wycofania i tworzy nową migawkę z możliwością zapisu, która staje się domyślnym katalogiem głównym. Jest to ważna właściwość bezpieczeństwa: wycofanie nie powoduje po prostu nadpisania starego katalogu głównego.

Po zakończeniu polecenia uruchom ponownie:

sudo reboot

Przy następnym uruchomieniu wybierz normalny domyślny wpis SLES zamiast ponownie uruchamiać starą migawkę tylko do odczytu.

Krok 7: Sprawdź, czy przywrócony katalog główny jest zapisywalny i jest teraz katalogiem domyślnym

Po normalnym uruchomieniu sprawdź miejsce montowania katalogu głównego i listę migawek:

findmnt /
sudo snapper list

Powtórz kontrole funkcjonalne, które pierwotnie zakończyły się niepowodzeniem. Jeśli aplikacja nadal nie działa, sprawdź, czy jej część znajduje się w katalogu, którego nie uwzględniono w migawce głównej.

Krok 8: Odśwież repozytoria i sprawdź stan pakietu

W przypadku standardowej aktualizacji pakietu, przed podjęciem próby kolejnej aktualizacji, należy odświeżyć repozytoria i sprawdzić zależności pakietów. W przypadku wycofywania Service Packa, sprawdzenie repozytoriów i rejestracji produktów jest szczególnie ważne, ponieważ niezgodny zestaw repozytoriów może natychmiast doprowadzić system do niespójnego stanu.

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

Aby odzyskać pakiet Service Pack, należy wykonać czynności opisane w oficjalnym Podręczniku aktualizacji systemu SLES , który wyraźnie nakazuje sprawdzenie konfiguracji repozytorium i rejestracji produktu po wycofaniu.

Czego nie przywróci cofnięcie uprawnień Snappera

To najważniejsze ograniczenie, które należy zrozumieć przed użyciem funkcji wycofywania na serwerze produkcyjnym. Domyślna migawka główna SLES wyklucza kilka podwoluminów, aby dane ulotne oraz dane użytkownika lub aplikacji nie zostały nieoczekiwanie przywrócone. Lista specyficzna dla produktu może obejmować ścieżki /home, /opt, /usr/local, /srv, /tmp, /var, /runoraz ścieżki bootloadera specyficzne dla architektury. Aktualną listę i uzasadnienie można znaleźć w dokumentacji podstawowych pojęć Snappera w systemie SUSE.

Taka konstrukcja chroni dane, ale wiąże się z pewnym kompromisem: kod systemowy może zostać cofnięty, podczas gdy dane w wykluczonym podwoluminie pozostaną w nowszym stanie. SUSE wskazuje na kilka możliwych konsekwencji, w tym na /optniezgodność oprogramowania innych firm, zmianę uprawnień oraz utratę przez aplikacje zdolności rozpoznawania formatów danych zapisanych po utworzeniu migawki.

Ma to szczególne znaczenie w przypadku baz danych i aplikacji serwerowych. Jeśli aktualizacja obejmowała migrację schematu lub zmianę danych aplikacji w systemie /varlub /srv, wycofanie z poziomu roota może nie odwrócić tej zmiany danych. Przed założeniem, że sama migawka systemu jest wystarczająca, należy sprawdzić procedurę obniżania wersji lub przywracania aplikacji.

Typowe błędy, których należy unikać

• Cofnięcie przed przetestowaniem migawki. Uruchomienie migawki tylko do odczytu to bezpieczniejszy proces w SLES, ponieważ pozwala zweryfikować stan docelowy.
• Przypadkowy wybór migawki po aktualizacji. Sprawdź typ, datę, opis i relację przed/po aktualizacji, zamiast polegać wyłącznie na numerze migawki.
• Używany undochangedo transakcji całego pakietu. Jest przydatny dla wybranych plików; SUSE zaleca metodę rozruchu i wycofania w celu pełnego odzyskania roota.
• Oczekiwanie /varlub /homecofanie się do katalogu głównego. Domyślne wykluczenia podwoluminów są celowe.
• Ignorując wymóg pojedynczego urządzenia. SLES 15 SP7 dokumentuje obsługę przywracania rozruchowego katalogu głównego dla pojedynczego urządzenia z systemem plików Btrfs.
• Natychmiast ponów próbę tej samej aktualizacji. Najpierw zidentyfikuj przyczynę niepowodzenia aktualizacji, potwierdź repozytoria i ustal, czy przyczyną niepowodzenia była wada pakietu, niezgodne oprogramowanie innych firm, za mało miejsca na dysku, czy problem z lokalną konfiguracją.

Jeżeli system korzysta z aktualizacji transakcyjnych

System SLES można również zainstalować z rolą serwera transakcyjnego. Jest to inny model operacyjny: aktualizacje są stosowane do migawek i aktywowane podczas ponownego uruchomienia. W takich systemach SUSE umożliwia transactional-update rollbackustawienie migawki jako domyślnego katalogu głównego. Nie należy mieszać procedury odzyskiwania serwera transakcyjnego z konwencjonalną instalacją SLES z funkcją odczytu i zapisu bez uprzedniego zidentyfikowania roli systemu. Oficjalne rozwiązanie opisano w dokumentacji aktualizacji transakcyjnych systemu SLES 15 SP7 .

Lista kontrolna odzyskiwania

• Sprawdź, /czy jest to Btrfs, czy rootkonfiguracja Snapper istnieje i czy główny system plików Btrfs znajduje się na jednym urządzeniu.
• Zidentyfikuj migawkę bezpośrednio przed nieudaną aktualizacją.
• Użyj go snapper status, snapper diffgdy musisz zrozumieć zakres zmiany.
• Preferuj selektywne ustawienie undochangetylko w przypadku wyraźnie odizolowanych plików.
• W przypadku niepowodzenia aktualizacji systemowej należy uruchomić migawkę kandydata z poziomu GRUB i przetestować ją w trybie tylko do odczytu.
• Uruchom snapper rollbackdopiero, gdy kandydat zachowa się poprawnie.
• Uruchom ponownie domyślny wpis i sprawdź, czy przywrócony katalog główny jest zapisywalny.
• Odśwież repozytoria, zweryfikuj stan pakietów i sprawdź rejestrację po odzyskaniu Service Packa.
• Przed uznaniem odzyskiwania za zakończone sprawdź wykluczone podwoluminy pod kątem niezgodności aplikacji lub formatu danych.

Kluczowym kompromisem jest precyzja kontra spójność. Selektywne przywracanie plików zmienia mniej, ale wymaga dokładnej wiedzy o przyczynie awarii. Przetestowane przywracanie systemu zmienia więcej, ale przywraca spójny stan główny z migawki i jest lepszym rozwiązaniem w przypadku nieudanej aktualizacji, która wpłynęła na wiele komponentów. W systemie SLES najbezpieczniejszym sposobem działania jest użycie rozruchu migawki tylko do odczytu jako punktu decyzyjnego, zamiast nadawania przywracaniu nieodwracalnego charakteru przed zweryfikowaniem kandydata.