Dane źródłowe nie zostały wyraźnie utracone. Po zresetowaniu ZimaOS macierz RAID6 nadal istniała, a katalogi takie jak upload, pgdata, thumbs, profile, a także encoded-video nadal istniały. Problem polegał na tym, że ponownie zainstalowany stos Immich nie był połączony ze starym stanem bazy danych/biblioteki w sposób, który przywróciłby poprzedni katalog zdjęć.
Najbezpieczniejsza rada ze źródła brzmiała: na razie nie usuwaj ani nie przenoś starych folderów upload i pgdata. Immich nie odbudowuje pełnego katalogu tylko dlatego, że widzi pliki obrazów na dysku. Baza danych zawiera ścieżki plików, użytkowników, albumy, metadane i stan aplikacji. Aktualna dokumentacja Immich v3 wyraźnie opisuje tę zależność i zaleca tworzenie kopii zapasowych zarówno plików zasobów, jak i bazy danych.
Najpierw potwierdź rzeczywistą ścieżkę montowania macierzy RAID
Źródło użyło:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)i znaleziono:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadPotwierdzało to, że stare foldery Immich nadal istniały na macierzy RAID.
/media/ZimaOS-HD → /DATA nie dowodziło, że Immich używa dysku systemowego
Użytkownika zaniepokoiło:
/media/ZimaOS-HD -> /DATAale społeczność słusznie wyjaśniła, że jest to relacja montowania/dowiązania symbolicznego w ZimaOS. Jej obecność nie informuje, których ścieżek hosta faktycznie używają kontenery Immich.
Sprawdź efektywne punkty montowania Dockera
W wątku zalecono sprawdzenie:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'Jest to bardziej niezawodne niż zakładanie, że zrzut ekranu lub dawna pamięć odzwierciedla konfigurację uruchomionego kontenera.
Stare pgdata jest równie ważne jak stare pliki zdjęć
Jeśli podczas ponownej instalacji zainicjowano zupełnie nową bazę danych zamiast starej, pliki nadal mogą istnieć, a Immich może wyglądać na pusty.
Bieżąca wersja Immich używa UPLOAD_LOCATION i DB_DATA_LOCATION
Bieżący plik Compose Immich v3 oddziela lokalizację zasobów na hoście od lokalizacji Postgresa za pomocą UPLOAD_LOCATION oraz DB_DATA_LOCATION. W nadrzędnej dokumentacji wyraźnie zaznaczono, że udziały sieciowe nie są obsługiwane jako ścieżka bazy danych.
Użyj bieżącego modelu przechowywania Immich.
Kopia zapasowa bazy danych jest bezpieczniejsza niż ponowne podłączanie aktywnego starego katalogu pgdata między wersjami
Źródło korzystało z Immich w wersji v2.7.2. Obecna wersja Immich to v3. Przy odzyskiwaniu danych między wersjami bezpieczniejszy jest nadrzędny proces tworzenia kopii zapasowej i przywracania bazy danych niż założenie, że stary katalog danych Postgresa można po prostu podłączyć do nowszego obrazu bazy danych.
Zobacz bieżący proces tworzenia kopii zapasowej i przywracania Immich.
Nie porządkuj ręcznie wewnętrznych folderów zasobów Immich
Aktualna dokumentacja Immich ostrzega, że foldery takie jak library, upload, thumbs, profile, a także encoded-video są zarządzane przez aplikację. Przenoszenie lub usuwanie pojedynczych plików z pominięciem Immich może spowodować brakujące lub nieśledzone zasoby.
Użytkownik źródłowy nie potwierdził pomyślnego odzyskania danych
Członkowie społeczności zaproponowali kilka sposobów mapowania, w tym pojedyncze nadrzędne mapowanie montowania, ale jerlo ostatecznie odłożył sprawę i zaczął od nowa na innym systemie. Dlatego forum nie potwierdza żadnego konkretnego mapowania ścieżki jako ostatecznego rozwiązania.
Obecnie Immich preferuje zarządzany katalog główny przesyłania zamiast ręcznego mapowania każdego podfolderu
Źródłowe zrzuty ekranu przedstawiały ręczne mapowanie upload, thumbs, profile, library, encoded-video, a także kopie zapasowe, pojedynczo. Obecny upstreamowy plik Compose koncentruje się natomiast na UPLOAD_LOCATION, a Immich będzie zarządzać wewnętrznymi podkatalogami w obrębie tego katalogu głównego.
Podczas odtwarzania instalacji na nowszym wydaniu Immich użyj aktualnego układu Compose/pamięci masowej zamiast odtwarzać historyczny zestaw mapowań podkatalogów, chyba że pakiet wyraźnie ich wymaga.
Ścieżkę danych PostgreSQL trzymaj na obsługiwanej pamięci lokalnej
Aktualna dokumentacja Immich wyraźnie informuje, że udziały sieciowe nie są obsługiwane dla DB_DATA_LOCATION. Lokalnie podłączony system plików macierzy RAID/pamięci masowej może być odpowiedni, ale katalog bazy danych zamontowany przez SMB/NFS nie jest obsługiwaną ścieżką bazy danych.
Kompletne odzyskanie Immich wymaga zarówno zasobów, jak i bazy danych
Aktualna dokumentacja kopii zapasowych Immich mówi, że kopie bazy danych zawierają metadane i informacje o użytkownikach, ale nie zawierają zasobów zdjęć ani filmów. Drzewo zasobów należy zabezpieczyć osobno i przywrócić wraz ze zgodną kopią zapasową bazy danych.
To wyjaśnia, dlaczego stwierdzenie „pliki przesłane do serwera nadal tam są” było uspokajające, ale niewystarczające w opisanym przypadku źródłowym.
Nie podłączaj pochopnie starego aktywnego katalogu pgdata do innej wersji PostgreSQL/obrazu
Surowy katalog danych PostgreSQL zależy od wersji. Jeśli stara instalacja i nowy pakiet używają różnych wersji PostgreSQL lub Immich, preferuj obsługiwany zrzut i przywrócenie bazy danych albo udokumentowaną ścieżkę migracji. Utwórz kopię zapasową starego pgdata przed rozpoczęciem eksperymentów.
FAQ dotyczące odzyskiwania Immich
Czy reset ZimaOS wymazał foldery zdjęć na źródłowej macierzy RAID6?
Nie. Użytkownik powiedział, że macierz RAID i istniejące katalogi/pliki pozostały nienaruszone.
Czy samo zmapowanie starych plików zdjęć przywróci bibliotekę Immich?
Niekoniecznie. Immich potrzebuje również odpowiadającego jej stanu bazy danych/katalogu.
Co należy zabezpieczyć przed rozpoczęciem eksperymentów?
Kompletny magazyn zasobów oraz baza danych lub zweryfikowana kopia zapasowa bazy danych.
