Lista kontrolna migracji eksportu z chmury Immich dotycząca plików towarzyszących i duplikatów

Nie zmieniaj surowego eksportu z chmury, dopóki Immich nie zachowa plików sidecar, dat, relacji i potrzebnych wersji, które możesz rzeczywiście zweryfikować.

Eksport z Google Photos lub podobnej usługi może zawierać pliki JSON, powtarzające się odwołania do albumów, zmienione nazwy duplikatów, edycje oraz pliki pokrywające się z kolejną kopią zapasową z tego samego telefonu. Najpierw utwórz manifest, zaimportuj mały zestaw testowy obejmujący każdą klasę kolizji i nie spłaszczaj folderów ani nie usuwaj kopii w chmurze, dopóki którykolwiek plik sidecar pozostaje niejednoznaczny. Migracja kończy się dopiero wtedy, gdy oryginalne skróty, daty na osi czasu, albumy i pierwszy test pokrywania się z kopią mobilną są zgodne.

Zachowaj surowy eksport i utwórz manifest migracji

Wypakuj każde archiwum do drzewa przejściowego tylko do odczytu i zachowaj pobrane archiwa do czasu zaakceptowania migracji. Dla każdego potencjalnego zasobu zapisz partię eksportu, ścieżkę względną, nazwę pliku, rozmiar w bajtach, skrót, typ multimediów, dane dotyczące wykonania, ścieżkę pliku sidecar i katalog albumu. Ten manifest jest punktem odniesienia przy wycofywaniu zmian, gdy dwa pliki mają tę samą nazwę, ale inną zawartość.

Migracja uwzględniająca pliki sidecar ma znaczenie, ponieważ eksport z chmury może przechowywać czas wykonania, opis, lokalizację i relacje albumów poza plikiem multimedialnym. Procedura importera uwzględniającego eksport pokazuje, dlaczego użycie takiego importera i zweryfikowanie miejsca docelowego przed usunięciem kopii w chmurze pozwala zachować więcej niż ślepe kopiowanie plików.

Przerwij, jeśli archiwów nie można wypakować, brakuje oczekiwanych lat, liczba plików sidecar jest niewyjaśniona lub na woluminie przejściowym brakuje miejsca na kopię roboczą. Nie zmieniaj nazw, nie spłaszczaj folderów, nie usuwaj duplikatów ani nie przepisuj metadanych w jedynym eksporcie, ponieważ takie zmiany niszczą dowody potrzebne do późniejszego dopasowania plików sidecar.

Dopasuj pliki sidecar przed normalizacją nazw i folderów

Pogrupuj pliki multimedialne i JSON zgodnie z regułami nazewnictwa eksportera, w tym z przyrostkami dodawanymi do duplikatów, edycji i długich nazw plików. Dla dziesięciu reprezentatywnych elementów porównaj osadzony czas wykonania z czasem zdjęcia w pliku sidecar, czasem modyfikacji systemu plików, strefą czasową, opisem, lokalizacją i przynależnością do albumu. Zapisz, które pole będzie nadrzędne dla każdej klasy konfliktu.

Do każdego scalania metadanych używaj kopii roboczej i zachowaj obok niej oryginalny plik sidecar. Procedura ZimaSpace dotycząca zapobiegania zmianie dat wykonania przez pliki sidecar przedstawia powiązaną ścieżkę zachowania dat; ta lista kontrolna dodaje manifest i bramki dotyczące duplikatów, wymagane przed pełnym importem do Immich.

Etap kończy się powodzeniem tylko wtedy, gdy każdy testowy plik sidecar jest przypisany do jednego zamierzonego pliku multimedialnego lub jawnie sklasyfikowany jako niepasujący. Jeśli zmieniona nazwa pliku może pasować do więcej niż jednego pliku sidecar, pozostaw ją nierozstrzygniętą i sprawdź kolejność eksportera oraz skróty zamiast wybierać wyłącznie na podstawie nazwy pliku.

Oddziel prawdziwe duplikaty od powiązanych wersji

Klasyfikuj kolizje jako kopie identyczne bajt po bajcie, kopie zmniejszone przez chmurę, wersje edytowane, odwołania do albumów, pary Live Photo lub rzeczywiście różne obrazy o tej samej nazwie. Zachowaj wersje edytowane i oryginalne, chyba że rodzina ustaliła udokumentowaną regułę; podobieństwo wizualne nie jest wystarczającym dowodem do usunięcia pliku.

Rozwiązany przypadek społeczności dotyczący historii w chmurze i ponownej kopii z telefonu pokazuje, jak historia w chmurze i ponowna kopia z telefonu mogą tworzyć duplikaty o różnych skrótach. Wykorzystaj ten konkretny scenariusz awarii do przetestowania pokrywania się zestawu Takeout z rolką aparatu każdego telefonu, zanim włączysz automatyczne przesyłanie.

Zaimportuj mały zestaw testowy zawierający każdą klasę duplikatów. Porównaj liczbę elementów źródłowych i docelowych, skróty, daty, lokalizacje, przynależność do albumów oraz sposób obsługi powiązanych filmów. Wycofaj import zestawu testowego, jeśli importer scala potrzebne wersje lub tworzy niewyjaśnione drugie zasoby; nie próbuj później naprawiać tego masowym usuwaniem.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wykonaj pełny import i potwierdź nowe źródło prawdy

Wstrzymaj przepisywanie metadanych i mobilne kopie zapasowe podczas importowania partii wskazanych w manifeście. Zapisuj dzienniki importera i listy odrzuconych plików, a następnie uzgadniaj liczby według klas, zamiast oczekiwać, że jedna surowa liczba będzie równa innej, gdy odwołania do albumów i identyczne duplikaty są celowo scalane.

Po imporcie sprawdź próbki ze starych i niedawnych lat, zdjęcia edytowane, długie filmy, Live Photos, elementy udostępnionych albumów oraz zasoby z plikami sidecar. Pobierz wybrane oryginały i porównaj ich skróty z kopią przejściową; potwierdź daty na osi czasu, wyszukiwanie, przynależność do albumów i lokalizację w klientach webowych oraz mobilnych.

Włącz kopię zapasową tylko jednego telefonu dopiero wtedy, gdy zaimportowana historia przejdzie weryfikację. Powtórz test pokrywania się, uruchom ponownie Immich i sprawdź, czy nie pojawiają się drugie kopie. Zachowaj surowy eksport i bibliotekę w chmurze do czasu pomyślnego zakończenia dwóch cykli kopii zapasowej oraz testu przywracania; nierozpoznane pliki sidecar lub niedeterministyczną obsługę duplikatów zgłaszaj, zachowując manifest i dzienniki zestawu testowego.