Dlaczego Immich traci dostęp do danych trwałych po ponownym utworzeniu stosu?
Gdy Immich wygląda na pusty lub nie może odczytać biblioteki po ponownym utworzeniu stosu, w pierwszej kolejności załóż, że stare dane trwałe są odłączone lub nieczytelne, a nie usunięte.
Ponowne utworzenie kontenerów może zmienić tożsamość projektu Compose, źródło montowania bind, podłączenie woluminu nazwanego, moment zamontowania udziału sieciowego albo identyfikator UID/GID używany do odczytu danych. Zatrzymaj instancję wyglądającą na nową, zanim zapisze dużo nowego stanu, zlokalizuj na hoście starą bazę danych i ścieżki multimediów, a następnie porównaj odtworzony stos z ostatnim poprawnie działającym mapowaniem. Celem jest najpierw ponowne podłączenie istniejącego stanu; przywracanie z kopii zapasowej wykonuj dopiero po potwierdzeniu, że stan rzeczywiście zaginął lub został uszkodzony.
Zatrzymaj nową instancję i potwierdź, że stare dane nadal istnieją
Kreator konfiguracji, pusta oś czasu lub brak zewnętrznej biblioteki bezpośrednio po ponownym utworzeniu stosu to sygnał ostrzegawczy dotyczący trwałości danych. Zatrzymaj Immich i sprawdź na hoście lokalizacje bazy danych oraz multimediów, zanim prześlesz nowe pliki lub zaakceptujesz nową, pustą konfigurację. Nowe zapisy mogą utrudnić późniejsze porównanie ścieżek.
Sprawdź w starych katalogach oczekiwaną liczbę plików, daty modyfikacji, pliki bazy danych lub zrzuty oraz reprezentatywne oryginalne obrazy. Jeśli dane są obecne na hoście, problem dotyczy dostępu lub mapowania, a nie ich zniknięcia. Przed zmianą właściciela lub przenoszeniem katalogów utwórz migawkę tylko do odczytu albo kopię zapasową tego stanu.
Jeśli nie można znaleźć starych danych w oczekiwanych ścieżkach, przeszukaj pulę pamięci i spis woluminów Docker przed usunięciem czegokolwiek. Punkt decyzyjny jest binarny: istniejący stan został zlokalizowany i zabezpieczony albo jest rzeczywiście niedostępny, a ścieżka odzyskiwania prowadzi do sprawdzonej kopii zapasowej zamiast do naprawy montowania.
Porównaj ponownie utworzone montowania z poprzednim stosem
Sprawdź rzeczywiste montowania kontenerów serwera i bazy danych Immich po ponownym utworzeniu, a nie tylko zapamiętany tekst Compose. Względna ścieżka bind może zostać rozwiązana względem innego katalogu projektu, a zmieniona nazwa projektu Compose może podłączyć nowy nazwany wolumin, pozostawiając stary nietknięty, ale nieużywany.
Nieudane, zmienione lub brakujące montowanie może powodować wyświetlanie pustego katalogu wewnątrz kontenera, nawet gdy oczekiwane dane nadal istnieją gdzie indziej na hoście. Użyj kontroli montowania woluminów Docker, aby porównać wartości Source, Destination, typ montowania oraz tożsamość nazwanego woluminu dla każdej trwałej ścieżki Immich. Niezgodność w tym miejscu bezpośrednio wyjaśnia wygląd świeżo zainicjalizowanej instancji.
Popraw wyłącznie nieprawidłowe mapowanie montowania, a następnie utwórz lub uruchom kontener bez usuwania woluminów. Jeśli po zmianie oczekiwane pliki pojawią się pod tą samą ścieżką kontenera, pozostaw dane na miejscu. Jeśli lista montowań jest prawidłowa, ale dostęp nadal się nie udaje, zachowaj mapowanie i przejdź do sprawdzenia dostępności pamięci hosta oraz uprawnień zamiast tworzyć kolejny wolumin.
Sprawdź, czy pamięć zewnętrzna była zamontowana przed uruchomieniem Immich
Jeśli dane Immich znajdują się na puli dysków HDD, udziale NAS, warstwie merger lub innym zewnętrznym montowaniu, potwierdź, że pamięć jest rzeczywiście zamontowana na hoście przed uruchomieniem stosu Docker. Ścieżka taka jak /mnt/photos może nadal istnieć jako zwykły lokalny katalog, gdy właściwe urządzenie jest niedostępne.
Trwałe dane Docker przetrwają wymianę kontenera tylko wtedy, gdy właściwy wolumin lub bind mount zostanie ponownie prawidłowo podłączony. Podstawowy model trwałości woluminów Docker nie sprawia, że brakujący dysk hosta lub udział sieciowy pojawi się automatycznie, dlatego przed testowaniem tej samej ścieżki w Immich zweryfikuj urządzenie pamięci i znany plik na hoście.
Jeśli odkryjesz pliki awaryjne zapisane w pustym punkcie montowania podczas nieobecności właściwej pamięci, zatrzymaj Immich przed zamontowaniem urządzenia w tym miejscu. Uporządkuj te pliki osobno, dodaj zależność uruchamiania lub kontrolę stanu montowania pamięci, a dopiero potem uruchom ponownie stos. Jeśli pamięć hosta działa stabilnie, a ścieżka kontenera nadal jest nieczytelna, przejdź do gałęzi dotyczącej uprawnień.
Sprawdź UID, GID i uprawnienia katalogów bez przepisywania wszystkiego
Odtworzony stos może uruchamiać usługę z inną tożsamością numeryczną, przestrzenią nazw użytkownika lub kontekstem bezpieczeństwa niż poprzedni. Rezultat różni się od brakującego montowania: ścieżka istnieje, a pliki są widoczne na hoście, lecz dzienniki Immich pokazują błędy uprawnień lub aplikacja nie może tworzyć oczekiwanych plików.
Porównaj numerycznego właściciela i bity trybu uprawnień w dotkniętych problemem katalogach hosta z tożsamością użytkownika wewnątrz odtworzonego kontenera. Najpierw przetestuj nieszkodliwy odczyt, a następnie odwracalny zapis w tymczasowej lokalizacji pod tym samym montowaniem. Unikaj rekursywnej zmiany właściciela w całym archiwum zdjęć, dopóki nie ustalisz, która usługa potrzebuje dostępu do zapisu i które oryginalne pliki powinny pozostać nietknięte.
Napraw najmniejszą niezgodność katalogu lub tożsamości, która wyjaśnia problem, uruchom usługę ponownie i ponownie sprawdź dzienniki. Jeśli dostęp nadal się nie udaje mimo zgodnych montowań i uprawnień, przestań zmieniać system plików i sprawdź połączenie z bazą danych, podstawianie zmiennych środowiskowych lub warstwę bezpieczeństwa, które zmieniły się podczas ponownego utworzenia stosu.
Podłącz ponownie oryginalny stan i zweryfikuj kolejne odtworzenie
Po podłączeniu i udostępnieniu starej bazy danych oraz ścieżek multimediów uruchom Immich i sprawdź obecność dawnych użytkowników, albumów, osób oraz reprezentatywnych zasobów. Nie uznawaj naprawy za zakończoną tylko dlatego, że strona główna się ładuje; potwierdź, że aplikacja odczytuje oryginalny stan, a nie nowo zainicjalizowaną bazę danych znajdującą się obok niego.
Istotna granica polega na tym, że kontenery mogą być tymczasowe, natomiast stan aplikacji musi pozostać na stabilnej pamięci poza cyklem życia kontenera. Udokumentuj poprawione nazwy montowań i ścieżki hosta oraz wykorzystaj trwałe role pamięci serwera plików, aby przy kolejnym odtworzeniu stosu był on podłączony do tych samych danych.
Na koniec odtwórz stos jeszcze raz w kontrolowanych warunkach i powtórz pierwotne kontrole. Naprawa jest potwierdzona dopiero wtedy, gdy ta sama baza danych i multimedia pojawiają się po ponownym utworzeniu stosu oraz po ponownym uruchomieniu hosta. Jeśli stary stan znów zniknie lub baza danych zgłosi uszkodzenie zamiast błędów dostępu, przywróć zabezpieczoną kopię i przejdź do odzyskiwania bazy danych lub kopii zapasowej, zamiast kontynuować eksperymenty z montowaniami.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Jak zoptymalizować połączenia z bazą danych Immich dla równoczesnych kontenerów
Nie zwiększaj najpierw wartości max_connections. Zmierz sesje Immich, zsumuj zapotrzebowanie wszystkich kontenerów, zachowaj rezerwę dla administratora i dostosuj tylko faktycznie potwierdzone wąskie gardło.
Jak zapobiegać duplikowaniu zadań lub importów w Immich
Oddziel powtarzające się zadania od zduplikowanych zasobów. Użyj jednej kanonicznej ścieżki pozyskiwania danych, kontroluj ponowne próby i zmiany ścieżek, a następnie przetestuj ponowne wprowadzanie...
Jak naprawić Immich po zapełnieniu woluminu bazy danych
Nigdy nie usuwaj dziennika WAL PostgreSQL, aby zwolnić miejsce. Zatrzymaj operacje zapisu w Immich, zachowaj stan bazy danych, bezpiecznie zwiększ pojemność, odzyskaj działanie PostgreSQL,...
