Jakie dane Immich muszą być zachowane i dlaczego role pamięci masowej mają znaczenie?

Niezawodność Immich zależy od utrzymywania trwałości oryginałów będących źródłem danych oraz stanu aplikacji, przy jednoczesnym traktowaniu odtwarzalnych pochodnych i danych tymczasowych jako odrębnych ról pamięci masowej.

Umieszczenie każdego katalogu na jednym woluminie może działać, ale utrudnia rozróżnienie danych, które muszą przetrwać odbudowę, danych, które można odtworzyć, oraz danych, które powinny pozostać niezależne jako kopia zapasowa. To rozróżnienie ma większy wpływ na czas odzyskiwania, rozmieszczenie danych i bezpieczeństwo operacji czyszczenia niż same nazwy katalogów.

Oryginalne multimedia to niezastępowalna rola treści

Przesłane zdjęcia i filmy to rodzinne wspomnienia, które aplikacja ma chronić. Ich ścieżka przechowywania może się różnić w zależności od wdrożenia i wyboru szablonu pamięci masowej, ale ich rola pozostaje taka sama: są zasobami źródłowymi, a nie pamięcią podręczną, a ich utraty nie da się naprawić przez ponowne wygenerowanie miniatur ani indeksów wyszukiwania.

Aktualny przewodnik dotyczący hostingu własnego, który rozdziela lokalizację multimediów i bazy danych, jest przydatny, ponieważ przedstawia pamięć masową jako element projektu niezawodności, a nie pojedynczą wartość pojemności. Traktuj zalecenia sprzętowe jako przykłady, zachowując jednak ogólne rozróżnienie między dużymi zbiorami oryginałów a aktywnym stanem aplikacji.

Nie klasyfikuj katalogu na podstawie tego, jak łatwo można odtworzyć kontener. Kontenery i obrazy aplikacji można zastąpić, ale zamontowane multimedia, do których się odwołują, mogą być niezastępowalne. Przed jakimkolwiek czyszczeniem lub przenoszeniem zidentyfikuj kanoniczną lokalizację oryginałów i sprawdź, czy istnieje niezależna kopia.

PostgreSQL to autorytatywna rola relacji

Baza danych zachowuje wiedzę aplikacji o użytkownikach, zasobach, ścieżkach, albumach, udostępnianiu, metadanych, ustawieniach i stanie związanym z wyszukiwaniem. Sam katalog ze zdjęciami nie jest więc równoważny odtworzonej instancji Immich: system plików i baza danych opisują różne części tej samej biblioteki.

Architektura usług uwidacznia tę zależność, oddzielając PostgreSQL od pamięci multimediów i przetwarzania w tle. To wyjaśnia, dlaczego opóźnienia bazy danych mogą wpływać na interakcję oraz dlaczego kopia zapasowa obejmująca wyłącznie multimedia nie zachowa wszystkich relacji aplikacji.

Granica awarii ma znaczenie: sam zrzut bazy danych również nie jest kopią zapasową zdjęć. Może odtworzyć metadane i relacje tylko wtedy, gdy odpowiednie pliki multimedialne są dostępne w oczekiwanym stanie logicznym. Chroń obie strony i testuj je razem.

Wygenerowane multimedia wymieniają przestrzeń na szybsze działanie

Miniatury, podglądy i wersje filmów w zgodnym formacie umożliwiają praktyczne przeglądanie i odtwarzanie bez wielokrotnego przetwarzania pełnych oryginałów. Mogą zajmować dużo miejsca, ale ich wartość podczas odzyskiwania jest inna, ponieważ wiele z nich można wygenerować ponownie, jeśli przetrwają oryginały i wymagany stan aplikacji.

Przykład z domowego laboratorium z oddzielnymi rolami pamięci masowej pokazuje, dlaczego administratorzy często umieszczają aktywne operacje bazy danych i duże zbiory zdjęć na różnych nośnikach. Nie chodzi o to, że każdy dom potrzebuje takich samych dysków, lecz o to, że generowane dane o dużej częstotliwości zmian mogą wymagać innej polityki wydajności i tworzenia kopii zapasowych niż oryginały.

Odtwarzalne nie znaczy darmowe. Odbudowa pochodnych dla dużej rodzinnej biblioteki może zająć wiele godzin lub dni, zużywając czas procesora, operacje wejścia-wyjścia pamięci masowej i czas kolejkowania. Wykluczenie ich z kopii zapasowej jest decyzją dotyczącą czasu odzyskiwania, a nie dowodem na to, że są pozbawione wartości operacyjnej.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kolejki i pamięci podręczne nie są trwałym źródłem prawdy

Stan kolejek i pamięci podręczne pomagają działającemu systemowi koordynować pracę i ją przyspieszać, ale nie powinny stać się jedynym miejscem przechowywania niezastępowalnej informacji. Jeśli tymczasowa kolejka zniknie po ponownym uruchomieniu, trwały stan bazy danych i systemu plików powinien nadal pozwolić aplikacji ustalić, co należy zrobić dalej.

Artykuł ZimaSpace o ścieżce danych Immich pomaga oddzielić stan trwały od usług, które przenoszą żądania przez system. Kolejka opisuje pracę w toku; nie należy mylić jej z rodzinnym archiwum.

Ten model przestaje być bezpieczny, jeśli niestandardowa integracja przechowuje unikatowy stan wyłącznie w ścieżce tymczasowej, nieobjętej kopią warstwie kontenera lub nieudokumentowanej lokalizacji dodatkowej usługi. Przed założeniem, że domyślne kategorie trwałości obejmują całe wdrożenie, zinwentaryzuj niestandardowe punkty montowania i nadpisania konfiguracji.

Zbuduj macierz odzyskiwania przed przeniesieniem pamięci masowej

Wymień każdą rolę — oryginały, profile, bazę danych, wygenerowane miniatury, zakodowane filmy, pamięć podręczną modeli, kopie zapasowe, konfigurację i wszelkie zewnętrzne biblioteki. Dla każdej zapisz ścieżkę na hoście, informację, czy jest autorytatywna, czy można ją odtworzyć, maksymalną akceptowalną utratę danych oraz oczekiwany czas przywracania.

Przewodnik ZimaSpace dotyczący kopii zapasowych rodzinnych zdjęć wyznacza właściwą granicę operacyjną: użyteczna usługa rodzinna wymaga chronionych multimediów oraz stanu aplikacji potrzebnego do zachowania spójności tych multimediów po awarii.

Zaakceptuj projekt trwałości dopiero wtedy, gdy nowy host będzie mógł odtworzyć reprezentatywne oryginały, konta i relacje, a następnie ponownie wygenerować celowo wykluczone pochodne. Jeśli odzyskiwanie zależy od pamiętania o nieudokumentowanym woluminie lub odzyskania zapisywalnej warstwy kontenera, role pamięci masowej nie są jeszcze bezpiecznie zdefiniowane.