Jak przywrócić Immich po nieudanej aktualizacji kontenera

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 Restore Immich After a Failed Container Update - Zima Store Online

Przywróć Immich po nieudanej aktualizacji kontenera, zamrażając bieżący stan dowodowy, przypinając każdą usługę Immich do ostatniej sprawdzonej wersji i przywracając dane tylko wtedy, gdy skoordynowane wycofanie zmian nie pozwoli uruchomić całego stosu.

Aktualizacja może jednocześnie zmienić kod aplikacji, oczekiwania dotyczące schematu bazy danych, zmienne środowiskowe oraz wersje usług towarzyszących. Wielokrotne pobieranie wersji latest lub mieszanie starych i nowych kontenerów utrudnia określenie granicy odzyskiwania. Przed rozpoczęciem zapisz plik Compose, środowisko, logi, bazę danych i ścieżki przesyłania, a następnie wybierz między wycofaniem obrazu a pełnym przywróceniem bazy danych i biblioteki.

Zamroź nieudany stan i określ granicę aktualizacji

Wyłącz automatyczne ponowne uruchamianie i zapisz dokładne obrazy lub skróty dla usług serwera, uczenia maszynowego, bazy danych i pamięci podręcznej. Zapisz logi uruchamiania oraz pliki wdrożeniowe przed kolejnym pobraniem. Sukces oznacza możliwość wskazania, co się zmieniło; w przypadku niepowodzenia odzyskiwanie należy wstrzymać do czasu zidentyfikowania starych wersji na podstawie historii wdrożeń lub lokalnych obrazów.

Sprawdź, czy serwer kończy działanie przed połączeniem z bazą danych, podczas migracji czy dopiero po uzyskaniu gotowości. Błąd połączenia z zależnością wskazuje na konieczność naprawy sieci, danych uwierzytelniających lub stanu usługi; błąd migracji zwiększa ryzyko przywracania wyłącznie obrazu aplikacji, ponieważ baza danych mogła już ulec zmianie.

Przewodnik dotyczący wersjonowanych aktualizacji Immich pokazuje, dlaczego granica wydania i pliki wdrożeniowe mają znaczenie. Użyj go do zinwentaryzowania przejścia, ale za podstawę wycofania zmian uznaj własne logi i kopie zapasowe.

Najpierw spróbuj pełnego wycofania do ostatnich sprawdzonych obrazów

Przypnij wszystkie obrazy aplikacji Immich do dokładnie tej wcześniej działającej wersji, zamiast zmieniać tylko jedną usługę. Odtwórz objęte problemem kontenery, pozostawiając trwałe wolumeny bez zmian. Jeśli stos odzyska poprawny stan, a logi nie wykażą niezgodności schematu, takie wycofanie zmian zakończyło się powodzeniem.

Jeśli stary serwer odrzuca bieżący schemat bazy danych, zatrzymaj się. Nie przełączaj naprzemiennie wersji na tej samej bazie danych i nie edytuj ręcznie tabel migracji. Taka awaria oznacza, że aktualizacja przekroczyła granicę danych, a odzyskiwanie musi użyć kopii zapasowej bazy danych z sygnaturą czasową odpowiadającą wybranej wersji aplikacji.

Raport dotyczący Immich v1.135.3 opisuje konkretną awarię uruchamiania podczas migracji bazy danych po aktualizacji. Jego przykład ograniczonej migracji uzasadnia uważne odczytanie pierwszego błędu krytycznego; nie oznacza jednak, że można kopiować polecenia z tego przypadku do innej wersji.

Przywracaj bazę danych i multimedia tylko wtedy, gdy wycofanie zmian nie wystarczy

Przed rozpoczęciem przywracania utwórz kopię bezpieczeństwa lub migawkę pamięci masowej nieudanego stanu. Przygotuj czyste środowisko odzyskiwania, przywróć kopię bazy danych, a następnie udostępnij odpowiadającą jej bibliotekę przesłanych plików oraz wymagane pliki wdrożeniowe. Nie zastępuj jedynej bieżącej biblioteki starszą kopią tylko po to, by dopasować sygnatury czasowe.

Rekordy bazy danych i pliki zasobów muszą opisywać tę samą kolekcję. Jeśli kopia zapasowa nie obejmuje najnowszych przesłanych plików, zachowaj je oddzielnie do późniejszego uzgodnienia. Przywracanie kończy się powodzeniem, gdy migracje zostaną ukończone, pojawią się oczekiwani użytkownicy i zasoby, a przykładowe oryginały otworzą się bez powszechnych błędów brakujących plików.

Przewodnik migracji Immich firmy ZimaSpace zawiera przydatną listę elementów do zinwentaryzowania podczas przenoszenia trwałych komponentów, bez utożsamiania obrazu kontenera z samą biblioteką zdjęć.

-15% OFF

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

Single board computer zimaboard2

Zweryfikuj odzyskiwanie przed ponowną próbą aktualizacji

Przetestuj logowanie, przeglądanie osi czasu, pobieranie oryginałów, generowanie miniatur, Smart Search, przetwarzanie twarzy, jedno nowe przesłanie i jedną kopię zapasową bazy danych. Raz uruchom ponownie kontenery i hosta. Sukces wymaga, aby po ponownym uruchomieniu były dostępne te same zasoby i funkcje, bez powtarzających się błędów migracji lub uprawnień.

Do zakończenia weryfikacji przechowuj nieudany i odzyskany stan pod oddzielnymi oznaczeniami. Jeśli odzyskiwanie zależy od starszej wersji, wyłącz niekontrolowane pobieranie obrazów i udokumentuj przypiętą wersję. Ponów próbę aktualizacji dopiero po przeanalizowaniu wszystkich pośrednich wydań i wykonaniu nowej skoordynowanej kopii zapasowej.

Wróć do zachowanego środowiska odzyskiwania, jeśli nowe przesłane pliki znikają, oryginałów nie można otworzyć lub zadania wielokrotnie kończą się awarią. Eskalując problem, podaj wersje źródłową i docelową, skróty obrazów, pierwszy błąd krytyczny w logach, sygnaturę czasową kopii bazy danych oraz mapowanie pamięci masowej; nigdy nie usuwaj ostatniej sprawdzonej kopii, dopóki zgodność aktualizacji nie zostanie rozwiązana.