Jak oddzielić dane aplikacji Jellyfin, pamięć podręczną i kopie zapasowe

Rozdziel dane aplikacji Jellyfin, pamięć podręczną i kopie zapasowe, zastanawiając się, co musi przetrwać przebudowę, co można wygenerować ponownie, a co musi pozostać dostępne po awarii urządzenia z aktywnym stanem. Te trzy role mogą współdzielić fizyczny dysk SSD w małym serwerze, ale nie powinny podlegać tym samym cyklom życia ani zasadom odzyskiwania.

Trwały stan aplikacji obejmuje bazę danych, konfigurację, dane użytkowników i odtwarzania oraz inne pliki wymagane do przywrócenia tego samego serwera. Pamięć podręczna i zadania transkodowania można usunąć, gdy nie są już potrzebne żadnemu aktywnemu zadaniu. Kopie zapasowe są kopiami odzyskiwania i nie powinny zależeć od tej samej granicy pamięci masowej, którą mają pomóc odzyskać.

Uczyń trwałe dane aplikacji nadrzędnym źródłem stanu

Zacznij od określenia ścieżki hosta lub woluminu, w którym znajduje się trwały stan Jellyfin. W przypadku wdrożenia kontenerowego obraz można zastąpić; to zamontowany stan musi zostać ponownie podłączony po odtworzeniu kontenera. Zapisz ścieżkę hosta, ścieżkę kontenera, właściciela, system plików, minimalny wymagany poziom wolnego miejsca oraz metodę tworzenia kopii zapasowych.

Aktualny układ Jellyfin Docker Compose rozdziela trwałe katalogi konfiguracji i pamięci podręcznej przed zamontowaniem multimediów. To rozróżnienie ścieżek jest praktyczne nawet wtedy, gdy oba katalogi początkowo znajdują się na tym samym dysku SSD.

Nie umieszczaj nadrzędnej bazy danych w lokalizacji, którą można bez obaw wyczyścić podczas rozwiązywania problemów. Pomyślne wyczyszczenie pamięci podręcznej nigdy nie powinno umożliwiać zresetowania użytkowników, bibliotek, stanu oglądania ani tożsamości serwera.

Traktuj pamięć podręczną i przestrzeń na transkodowanie jako dane robocze możliwe do odtworzenia

Pamięć podręczna służy do ograniczania powtarzalnej pracy lub przechowywania tymczasowych wyników przetwarzania. Jej wartość polega na wydajności i wygodzie, a nie na zachowaniu tożsamości. Zapewnij jej pojemność wystarczającą dla największych typowych obciążeń w tle i szczytów transkodowania, ale pozwól na jej odtworzenie bez przywracania całego serwera.

Nie pozwól, aby intensywna aktywność związana z pamięcią podręczną lub transkodowaniem dyktowała zasady tworzenia kopii zapasowych bazy danych. Jeśli oba role znajdują się na tym samym szybkim urządzeniu, użyj osobnych katalogów lub zbiorów danych z niezależnymi limitami i monitoringiem. Zapobiega to sytuacji, w której tymczasowy skok zużycia zajmuje wolne miejsce potrzebne do zapisu bazy danych lub przyszłego przywracania.

Gdy przeglądanie, metadane i operacje na stanie działają wolno, a sekwencyjne odczyty multimediów pozostają sprawne, analiza ZimaSpace dotycząca przechowywania interaktywnego stanu serwera multimediów na SSD stanowi dobry kolejny krok, bez traktowania całej biblioteki multimediów jako tego samego obciążenia pamięci masowej.

Kontener można usunąć; stan i procedura odtworzenia pozostają niezbędne

Kontener można pobrać ponownie, ale nie można zakładać, że jego procedura wdrożenia i dane trwałe pojawią się ponownie. Zachowaj definicję Compose lub usługi, wersję obrazu albo zasady dotyczące tagów, mapę montowań, tożsamość usługi, odwołania do wymaganych sekretów oraz trwały stan Jellyfin.

Praktyczna zasada przedstawiona w tym procesie tworzenia kopii zapasowych woluminów Docker mówi, że użyteczne dane odzyskiwania znajdują się w woluminach, montowaniach wiązanych, danych aplikacji i definicjach usług, a nie w samym nietrwałym kontenerze.

W przypadku aktywnych baz danych spójność jest ważniejsza niż kopiowanie każdego bajtu podczas pracy usługi. Zamiast traktować dowolną kopię plików wykonywaną na żywo jako sprawdzony punkt odzyskiwania, użyj obsługiwanej przez aplikację ścieżki tworzenia kopii zapasowej albo kontrolowanej metody zatrzymania usługi lub wykonania migawki, odpowiedniej dla danego wdrożenia.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kopia zapasowa obok aktywnego stanu nie chroni przed awarią hosta

Kopia zapasowa znajdująca się obok aktywnej bazy danych może pomóc w przypadku przypadkowych zmian, ale nie przetrwa każdej awarii puli, hosta, ataku ransomware, kradzieży ani problemu z zasilaniem, które mogą usunąć środowisko produkcyjne. Przechowuj kopię odzyskiwania na innym urządzeniu lub w innej granicy administracyjnej i zabezpiecz wszystkie klucze lub dane uwierzytelniające potrzebne do jej odczytu.

Plan tworzenia kopii zapasowych w środowisku samodzielnie hostowanym powinien obejmować stan, sekrety, kopie odzyskiwania i instrukcje przywracania. Ten audyt odzyskiwania środowiska samodzielnie hostowanego podkreśla znaczenie kopii znajdujących się poza oczywistym obszarem skutków awarii oraz spisanych danych wejściowych do odbudowy, zamiast uznawania migawek za kompletny plan.

Nie pozwól, aby miejsce docelowe kopii zapasowej było zarządzane przez tę samą regułę przechowywania pamięci podręcznej lub to samo polecenie czyszczenia co aktywna pula aplikacji. Kopia zapasowa pełni odrębną rolę, nawet jeśli tymczasowo jest przechowywana w tej samej obudowie.

Określ role pamięci masowej przed zakupem lub przeniesieniem dysków

Ta mapa zapobiega częstemu błędowi podczas przeprojektowywania: przenoszeniu wszystkiego na najszybszy dysk, gdy problemem były tylko opóźnienia stanu aplikacji, albo tworzeniu kopii zapasowych każdego pliku tymczasowego przy jednoczesnym pominięciu definicji usługi potrzebnej do odbudowy kontenera.

Potwierdź rozdzielenie za pomocą odtwarzania testowego

Przywróć stan Jellyfin do nowej ścieżki lub odizolowanego hosta, wskaż skopiowaną definicję wdrożenia na tę lokalizację, zapewnij nietrwale dostęp do reprezentatywnych multimediów i uruchom usługę bez oryginalnej pamięci podręcznej. Serwer powinien powrócić z oczekiwaną tożsamością, bibliotekami, użytkownikami i ustawieniami, mimo że pamięć podręczna zacznie działanie od zera.

Różnica staje się mierzalna dopiero wtedy, gdy kopia zapasowa zostanie przywrócona do odizolowanego celu i zweryfikowana bez korzystania ze stanu produkcyjnego. Testowa instancja Jellyfin powinna uruchomić się z kopii odzyskiwania, ponownie podłączyć wymagane ścieżki i potwierdzić, że aktywny wolumin nie dokańcza potajemnie procesu przywracania.

Układ spełnia założenia, gdy pamięć podręczną można usunąć bez utraty tożsamości, środowisko uruchomieniowe można odtworzyć bez ponownego budowania biblioteki z pamięci, a co najmniej jedna kopia zapasowa pozwala przywrócić usługę po założeniu, że urządzenie z aktywnymi danymi aplikacji jest niedostępne.