Bezpieczne przywracanie nieudanej aktualizacji SLES za pomocą Snappera

W standardowej instalacji SUSE Linux Enterprise Server (SLES) z katalogiem głównym Btrfs i włączonym Snapperem, najbezpieczniejszym sposobem odzyskiwania jest uruchomienie migawki utworzonej przed nieudaną aktualizacją, przetestowanie jej w trybie tylko do odczytu, a następnie uruchomienie sudo snapper rollback. Tworzy to nowy, zapisywalny katalog główny z przetestowanego stanu; nie powoduje to przewijania każdego dysku, podwoluminu ani bazy danych aplikacji.

Aktualne instrukcje administracyjne dotyczące systemu SLES 15 SP7 nadal korzystają z tego schematu uruchamiania i testowania. Przed jego zastosowaniem należy upewnić się, że komputer spełnia wymagania dotyczące układu przywracania systemu SUSE i zidentyfikować migawkę wstępną dla nieudanej transakcji Zypper lub YaST.

Czy wycofanie Snappera przywróci cały serwer?

Nie. Funkcja przywracania systemu z możliwością rozruchu dotyczy migawek w domyślnej rootkonfiguracji Snapper. Dokumenty SUSE obsługują domyślny układ podwoluminów głównych, z systemem plików Btrfs na jednym urządzeniu głównym i działającym, zainstalowanym programem ładującym. Przywracanie zmienia zawartość podwoluminu /; inne podwoluminy nie są uwzględniane. W typowych układach SLES ścieżki takie jak /var, /srv, /opt, /usr/locali często /homeznajdują się poza migawką. Baza danych lub usługa może zatem zachować dane zapisane po utworzeniu migawki, nawet gdy jej pakiety systemowe zostaną cofnięte.

Przed wykonaniem operacji przywracania należy wykonać lub zweryfikować osobną kopię zapasową ważnych danych aplikacji. Należy również unikać tej procedury, jeśli zmieniono domyślny układ podwoluminów Btrfs lub używany jest katalog główny obejmujący wiele urządzeń: udokumentowane wymagania dotyczące przywracania rozruchu w systemie SLES 15 SP7 nie obejmują tych konfiguracji. Przed kontynuowaniem należy zapoznać się z wymaganiami dotyczącymi odzyskiwania Snapper w systemie SUSE.

Która migawka została wykonana przed nieudaną aktualizacją?

Użyj konfiguracji Snappera dla głównego systemu plików i porównaj parę pre/post transakcji. W typowym systemie SLES z włączonymi migawkami głównymi Btrfs, Zypper i YaST tworzą migawki wokół operacji na pakietach. Migawka pre reprezentuje stan główny przed daną operacją; migawka post reprezentuje stan po jej uruchomieniu, w tym częściowo nieudaną transakcję.

1. Sprawdź, czy konfiguracja główna istnieje sudo snapper list-configs. Poszukaj konfiguracji o nazwie root.
2. Potwierdź typ głównego systemu plików za pomocą findmnt -no FSTYPE /. W przypadku tej procedury przywracania systemu rozruchowego powinien zostać wyświetlony komunikat btrfs. Następnie uruchom sudo btrfs filesystem show /i potwierdź raporty głównego systemu plików Total devices 1.
3. Wypisz pary transakcji z sudo snapper -c root list -t pre-post. Dopasuj datę i opis do nieudanej aktualizacji. Zapisz numer w kolumnie Pre #, a nie sparowaną Post #.
4. Sprawdź, co zmieniło się między parami. Zastąp PREi POSTliczbami wyświetlanymi na komputerze:

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

Te polecenia wyświetlają zmienione ścieżki i różnice w plikach. Numery migawek, daty, opisy pakietów i dane wyjściowe różnią się w zależności od hosta; nie należy kopiować przykładowego numeru ze zrzutu ekranu. Jeśli nie pojawi się odpowiednia para, sprawdź, czy Snapper jest włączony i czy polityka czyszczenia usunęła już migawkę. Brakującej migawki nie można odtworzyć po fakcie.

Jak sprawdzić stary korzeń przed jego utrwaleniem?

Zrestartuj system i użyj wpisu migawki bootloadera. W systemie SLES wybierz Start Bootloader from a read-only snapshot, a następnie wybierz migawkę z datą bezpośrednio poprzedzającą nieudaną transakcję. Menu rozruchowe oznacza wpisy datą i opisem, który może obejmować zypp(zypper)operację YaST. Wybierz migawkę zarejestrowaną przed aktualizacją; nie wybieraj migawki po aktualizacji tylko dlatego, że jej opis jest łatwiejszy do rozpoznania.

Zaloguj się i przetestuj usługi lub aplikacje, które uległy awarii. Pliki główne migawki są tylko do odczytu podczas tego testu, więc samo uruchomienie nie zmienia domyślnego katalogu głównego. Jeśli migawka jest nieprawidłowa lub system nadal się zawiesza, zrestartuj system i spróbuj innej migawki lub skorzystaj z systemu ratunkowego. Nie wymuszaj wycofania tylko po to, aby wybór z menu był trwały.

Kiedy należy uruchomić snapper rollback?

Uruchom wycofanie dopiero po uruchomieniu starszej migawki i pozytywnym przejściu kontroli. Z tej migawki tylko do odczytu wykonaj:

sudo snapper rollback

Następnie uruchom ponownie i wybierz normalny domyślny wpis rozruchowy:

sudo reboot

Snapper zachowuje migawkę stanu systemu sprzed wycofania i tworzy nowy katalog główny do odczytu i zapisu na podstawie przetestowanej migawki. W udokumentowanym procesie rozruchu z migawki nie przekazuje się numeru starej migawki do tego polecenia. Rezultatem jest nowy domyślny katalog główny, a nie konwersja migawki tylko do odczytu z możliwością zapisu. Migawki można później usunąć za pomocą reguł czyszczenia, dlatego przed wykorzystaniem starszej migawki wycofania jako archiwum długoterminowego należy skopiować wszystkie potrzebne pliki.

Co należy sprawdzić po ponownym uruchomieniu?

Uruchom domyślny wpis i sprawdź faktyczne odzyskiwanie, a nie tylko zakończenie polecenia. Potwierdź oczekiwany stan jądra i pakietu, przejrzyj status i logi niedziałającej usługi oraz przeprowadź proste sprawdzenie na poziomie aplikacji. Następnie sprawdź nowy stan Snappera:

sudo snapper -c root list

W przypadku zwykłej aktualizacji pakietu zazwyczaj wystarcza to do potwierdzenia, że ​​komputer uruchamia się z nowego katalogu głównego. Jeśli nieudana operacja dotyczyła migracji Service Packa , należy również wykonać czynności kontrolne po wycofaniu systemu SUSE: odświeżyć i sprawdzić repozytoria, a następnie sprawdzić rejestrację:

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

Repozytoria powinny być zgodne z pakietem Service Pack, do którego został przywrócony, a zainstalowane produkty powinny być zarejestrowane. Jeśli rejestracja nie zostanie przywrócona, procedura przywracania pakietu Service Pack w systemie SUSE SLES 15 SP7 opisuje sudo SUSEConnect --rollbackkrok naprawczy. To polecenie rejestracji jest specyficzne dla odzyskiwania po migracji; nie należy go uruchamiać w celu rutynowej aktualizacji pakietów.

Jeśli ten host korzysta z transactional-updatesystemu SLE Micro (na przykład transakcyjnego), należy postępować zgodnie z procedurą tego produktu zamiast stosować klasyczną sekwencję poleceń SLES. Jego dokumentacja służy do wybierania migawki z działającego systemu oraz do oddzielnego procesu tworzenia migawki tylko do odczytu w przypadku uszkodzenia bieżącego katalogu głównego. Zobacz instrukcje dotyczące wycofywania aktualizacji transakcyjnychsudo transactional-update rollback SNAPSHOT_NUMBER w systemie SUSE .