Jak zapobiegać duplikowaniu zadań lub importów w Immich

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 Prevent Duplicate Jobs or Imports in Immich - Zima Store Online

Zapobiegaj duplikowaniu zadań lub importów Immich, najpierw rozróżniając dwa różne objawy: ponowne uruchamianie tej samej pracy w tle oraz sytuację, w której to samo zdjęcie staje się więcej niż jednym zasobem. Następnie ustal, który klient, importer, skan biblioteki, zmiana ścieżki lub ponowienie utworzyło drugie zdarzenie, zanim cokolwiek usuniesz.

Najbezpieczniejszy projekt zapewnia każdej grupie zasobów jedną kanoniczną ścieżkę pozyskiwania. Historyczne archiwum w chmurze, biblioteka zewnętrzna i aktywna kopia zapasowa telefonu mogą być prawidłowe, ale nakładające się prawa własności tych samych plików mogą tworzyć zduplikowane rekordy lub pętle ponownego przesyłania, których żadne porządki po imporcie nie naprawią niezawodnie.

Ustal, czy masz powtarzającą się pracę, czy zduplikowane zasoby

W przypadku powtarzających się zadań zapisz nazwę kolejki, identyfikator zasobu, godzinę rozpoczęcia, stan zakończenia lub błędu oraz zdarzenie poprzedzające nowe zadanie. Prawidłowe zadanie następcze utworzone po przetwarzaniu metadanych różni się od tego samego zadania, które bez końca ponawia się po błędzie. Nie czyść wszystkich kolejek, dopóki nie ustalisz, który wzorzec występuje.

W przypadku zduplikowanych zasobów porównaj bibliotekę źródłową, oryginalną ścieżkę, zachowanie sum kontrolnych, jeśli są dostępne, stan kopii zapasowej urządzenia, czas wykonania zdjęcia i rozmiar pliku. To samo widoczne zdjęcie może istnieć jako dwa różne pliki po eksporcie z chmury, edycji metadanych, transkodowaniu lub obsłudze zewnętrznej biblioteki opartej na ścieżkach, a pliki identyczne bajt po bajcie mogą również znajdować się w różnych źródłach biblioteki Immich.

Jeśli zwykłe przesyłanie zaczyna powodować powtarzające się błędy sum kontrolnych lub ograniczeń unikalności, zachowaj bazę danych i sprawdź stan migracji oraz schematu, zanim uznasz objaw za problem ze źródłem importu. Zduplikowane zasoby w dwóch prawidłowych typach źródeł i błąd ograniczenia bazy danych to różne ścieżki, które nie powinny mieć tej samej procedury czyszczenia.

Przewodnik ZimaSpace dotyczący stanu kopii zapasowej telefonu i harmonogramowania mobilnego jest przydatny, ponieważ klient mobilny ma własny obraz tego, co nadal wymaga utworzenia kopii zapasowej. Czyszczenie po stronie serwera, które ignoruje stan klienta, może spowodować, że podczas następnej sesji telefon ponownie wyśle pliki.

Używaj jednej kanonicznej ścieżki pozyskiwania dla każdej istniejącej grupy zdjęć

Zanim włączysz ciągłą kopię zapasową telefonu, zdecyduj, jak stare zdjęcia trafią do Immich: na przykład zaimportuj archiwum historyczne raz, zweryfikuj je, a następnie pozwól telefonowi dodawać tylko nowe zdjęcia. Jeśli te same pliki historyczne są jednocześnie zamontowane jako biblioteka zewnętrzna i przesyłane przez zwykłą bibliotekę przesyłania, nie zakładaj, że globalne usuwanie duplikatów uzgodni oba źródła.

Raport o duplikatach między źródłami w Immich dokumentuje współistnienie identycznych treści pochodzących z biblioteki zewnętrznej i biblioteki przesyłania. Traktuj to jako granicę wynikającą z działania projektu: własność źródła ma znaczenie, dlatego zapobieganie jest bardziej niezawodne niż oczekiwanie, że późniejsze narzędzie do usuwania duplikatów samo ustali preferowaną kopię.

Unikaj przenoszenia plików przesłanych wewnętrznie przez Immich do biblioteki zewnętrznej bez jego wiedzy, gdy telefon nadal uznaje je za część swojego zestawu kopii zapasowej. Jeśli architektura pamięci masowej musi się zmienić, przeprowadź migrację udokumentowaną ścieżką, z kopiami zapasowymi i małą grupą testową, a następnie potwierdź zgodność aplikacji mobilnej z serwerem przed usunięciem starej kopii.

Kontroluj ponowienia i stan klienta przed zwiększeniem skali importu

W przypadku dużego importu ręcznego użyj manifestu etapowego: zapisz ścieżkę źródłową, liczbę plików, łączną liczbę bajtów oraz stabilną sumę kontrolną lub wynik importera, jeśli jest to praktyczne. Jeśli import zostanie przerwany, wznów go za pomocą tego samego narzędzia i do tego samego miejsca docelowego, zamiast uruchamiać drugi niezależny importer dla tego samego źródła, gdy stan pierwszego zadania jest niepewny.

Niedawny raport o wielokrotnym przesyłaniu w Immich pokazał klienta mobilnego, który stale ponawiał przesyłanie zasobów już obecnych na serwerze, powodując po stronie serwera błędy ograniczeń unikalności. Traktuj to jako dowód dotyczący konkretnej wersji, że właścicielem pętli może być stan kopii zapasowej klienta; nie uogólniaj tego na uniwersalne zachowanie aplikacji mobilnej. Zmiany ścieżek pozostają osobnym zagrożeniem. Podczas dużego importu utrzymuj stabilne ścieżki bibliotek zewnętrznych widoczne w kontenerze, a jeśli przeniesienie pamięci masowej jest konieczne, najpierw przeprowadź migrację małej grupy. Jeśli druga kopia pojawia się dopiero po zmianie ścieżki, postępuj zgodnie ze ścieżką dotyczącą tożsamości ścieżki, zamiast resetować stan kopii zapasowej telefonu.

-15% OFF

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

Single board computer zimaboard2

Przetestuj przerwanie, ponowienie i rzeczywiście nowy zasób

Utwórz małą reprezentatywną grupę obejmującą zwykłe zdjęcia, filmy, edytowany obraz oraz co najmniej jeden plik, który już istnieje w docelowej ścieżce. Zaimportuj ją raz, zapisz liczbę zasobów i ich identyfikatory, a następnie przerwij drugą kontrolowaną próbę lub ponownie przeskanuj dane zgodnie z procedurą planowaną do użycia w środowisku produkcyjnym.

Test kończy się pomyślnie, gdy nie pojawia się niewyjaśniony drugi zasób dla tego samego zamierzonego obiektu źródłowego, ponowienia stabilizują się bez stale rosnącej kolejki, a rzeczywiście nowe zdjęcie nadal importuje się poprawnie. Po teście ponownie otwórz również klienta mobilnego, aby jego stan kopii zapasowej nie różnił się po cichu od stanu serwera.

Jeśli duplikaty wracają wyłącznie między źródłami biblioteki przesyłania i biblioteki zewnętrznej, przeprojektuj granicę własności zamiast wielokrotnie je scalać. Jeśli ten sam identyfikator zasobu otrzymuje bez końca zadanie zakończone błędem, odizoluj to zadanie i plik. Zgłaszając problem, podaj typ źródła, ścieżki, hasze, jeśli są istotne, wersje, stan kopii zapasowej klienta oraz najmniejszą możliwą do odtworzenia grupę.