Jak bezpiecznie przywrócić wcześniejszą wersję Immich po wydaniu niekompatybilnej aktualizacji

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Roll Back Immich Safely After an Incompatible Release - Zima Store Online

Wycofaj Immich dopiero po zachowaniu bieżącego stanu i ustaleniu, czy nowsze wydanie zmieniło bazę danych lub konfigurację w sposób, którego starszy obraz nie potrafi odczytać.

Obraz kontenera można zastąpić, ale jego stan trwały mógł już zostać zmigrowany. Jeśli aktualizacja rozpocznie się niepomyślnie, zatrzymaj automatyczne aktualizacje i nowe zapisy, zanotuj obie wersje, zabezpiecz bieżącą bazę danych i multimedia, a następnie wybierz między prostym wycofaniem obrazu a przywróceniem punktu odzyskiwania sprzed aktualizacji.

Zamroź nieudaną aktualizację, zanim zmieni więcej danych

Wyłącz automatyczne aktualizacje obrazów i zatrzymaj dodawanie nowych zdjęć przez klientów na czas zbierania dowodów. Zapisz dokładne wersje lub skróty obrazów Immich — starą i nową — wersję PostgreSQL, pliki Compose i środowiska, ścieżki montowania oraz pierwszy błąd uruchamiania lub migracji.

Przewodnik ZimaSpace dotyczący granic wycofywania kontenerów wskazuje kluczową różnicę: woluminy trwałe przetrwają zastąpienie obrazu, ale jest to bezpieczne tylko wtedy, gdy starsza aplikacja pozostaje zgodna ze znajdującym się w nich stanem.

Jeśli bazę danych można odczytać, wykonaj natywną dla niej kopię zapasową bieżącego, nieudanego stanu i przechowuj ją oddzielnie od kopii sprzed aktualizacji. Nie nadpisuj żadnej z nich podczas kolejnych eksperymentów. Bieżąca kopia może być później potrzebna do dalszej aktualizacji, nawet jeśli bezpośrednim celem jest powrót do starszej wersji.

Ustal, czy wydanie przekroczyło granicę migracji bazy danych

Przeanalizuj pierwszy błąd po aktualizacji i ustal, czy występuje przed migracją bazy danych lub w jej trakcie, po migracji podczas uruchamiania aplikacji, czy dopiero w określonym przepływie użytkownika. Moment wystąpienia błędu zmienia plan wycofania, ponieważ starszy obraz może nie rozumieć schematu już zmienionego przez nowsze wydanie.

Niedawny raport Immich, w którym usługa nie uruchomiła się po ścieżce aktualizacji, pokazuje, dlaczego nieobsługiwane lub pominięte ścieżki migracji mogą sprawić, że zwykła zamiana wersji będzie zawodna. Potraktuj ten wątek jako studium przypadku i zweryfikuj dokładną sekwencję migracji dla używanych wersji.

Jeśli nowsza aplikacja nie dotknęła bazy danych, a problem ogranicza się do zgodności obrazu lub środowiska uruchomieniowego, wystarczyć może wycofanie do przypiętego obrazu. Jeśli migracje zostały ukończone, uznaj kopię zapasową bazy danych sprzed aktualizacji za bezpieczniejszego partnera dla starszego obrazu, chyba że masz wyraźne dowody zgodności.

Przywróć zgodną bazę danych i środowisko uruchomieniowe zamiast mieszać epoki

Zbuduj docelową konfigurację wycofania z ostatniej sprawdzonej wersji aplikacji, zgodnej z nią konfiguracji wdrożenia oraz punktu odzyskiwania bazy danych sprzed niezgodnej zmiany. Pozostaw drzewo multimediów bez zmian, chyba że wydanie zmieniło pliki multimedialne w udokumentowany sposób; nie kopiuj ponownie terabajtów danych tylko dlatego, że zmienił się obraz aplikacji.

Omówienie wycofywania zgodnego z bazą danych wyjaśnia ogólne zagrożenie związane z wdrażaniem starszego kodu względem schematu, którego ten kod już nie rozumie. Ta zasada jest ważniejsza niż to, czy sam kontener uruchamia się poprawnie.

Uruchom instancję wycofania w izolacji, aby klienci mobilni i zadania zaplanowane nie mogły zapisywać danych do czasu zakończenia walidacji. Jeśli starsza wersja natychmiast zgłosi błędy schematu, zatrzymaj ją. Nie próbuj ręcznie cofać migracji na jedynej kopii bazy danych, chyba że masz przetestowaną procedurę odzyskiwania właściwą dla danej wersji.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Przypnij dokładny, sprawdzony obraz i odtwórz jego konfigurację

Użyj konkretnej wersji lub niezmiennego odwołania do obrazu zamiast ruchomego tagu. Odtwórz zgodne środowisko, zależności usług, mapowania urządzeń, sieci, porty i cel odwrotnego proxy z ostatniego sprawdzonego wdrożenia. Wycofanie, które po cichu zmienia kilka warstw infrastruktury, tworzy drugi incydent.

Zachowaj nieudaną nowszą wersję obrazu i konfigurację razem z notatkami dotyczącymi wycofania. Umożliwi to kontrolowany powrót do nowszej wersji po zrozumieniu problemu ze zgodnością. Natychmiastowe usunięcie wszystkich nowych artefaktów może utrudnić porównanie stanów nieudanego i działającego lub odtworzenie aktualizacji w środowisku testowym.

Jeśli starsza usługa uruchomi się ze stanem po przywróceniu, przejrzyj logi przed włączeniem klientów. Potwierdź, że nie występuje nieoczekiwana próba migracji, inicjalizacja nowej instalacji, brakujący punkt montowania pamięci ani ponowna zmiana uprawnień. Sam ekran logowania nie dowodzi, że wycofanie korzysta z zamierzonych danych.

Zweryfikuj starszą wersję w warunkach pierwotnego wyzwalacza i zachowaj drogę powrotu

Przetestuj reprezentatywnych użytkowników, starsze i nowsze zasoby, albumy, udostępnianie, wyszukiwanie, jeden nowy kontrolowany przesył, zadania w tle, tworzenie kopii zapasowej bazy danych oraz trasę odwrotnego proxy. Uruchom stos ponownie i potwierdź, że te same punkty montowania oraz baza danych wracają bez ręcznej interwencji.

Wstrzymaj nowe przesyłanie do czasu pomyślnego zakończenia tych kontroli, a następnie ponownie otwórz dostęp i obserwuj normalne okno obciążenia. Zachowaj zarówno kopię sprzed aktualizacji, jak i kopię zapasową nieudanego nowszego stanu, aby później ponowić aktualizację w odizolowanej kopii po zrozumieniu problemu ze zgodnością.

Wycofanie zakończyło się niepowodzeniem, jeśli starsza wersja zgłasza niezgodność schematu, brakuje znanych danych lub zapisy trafiają do nieoczekiwanej ścieżki. Zatrzymaj się i ponownie przywróć zachowany punkt odzyskiwania, zamiast nakładać kolejne poprawki. Eskalując problem, przekaż dokładne wersje, logi migracji, znaczniki czasu kopii bazy danych, różnice w Compose oraz pierwszy krok weryfikacji, który kończy się niepowodzeniem.