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

Rozdziel dane aplikacji Jellyfin, pamięć podręczną i kopie zapasowe, zadając sobie pytania: co musi przetrwać odbudowę, co można wygenerować ponownie i co musi pozostać dostępne po awarii urządzenia przechowującego bieżący stan. W małym serwerze te trzy role mogą współdzielić fizyczny dysk SSD, ale nie powinny podlegać tym samym zasadom cyklu życia ani odzyskiwania danych.

Trwały stan aplikacji obejmuje bazę danych, konfigurację, dane użytkowników i odtwarzania oraz inne pliki potrzebne do przywrócenia tego samego serwera. Dane pamięci podręcznej i transkodowania są zbędne, gdy nie są już potrzebne aktywnym zadaniom. Kopie zapasowe służą do odzyskiwania danych i nie powinny zależeć od tej samej granicy magazynu, którą mają pomóc odtworzyć.

Uczyń trwałe dane aplikacji autorytatywnym źródłem stanu

Zacznij od ustalenia ścieżki hosta lub woluminu, w którym przechowywany jest trwały stan Jellyfin. We wdrożeniu kontenerowym obraz można zastąpić; podmontowany stan musi zostać ponownie podłączony po odtworzeniu kontenera. Zapisz ścieżkę hosta, ścieżkę kontenera, właściciela, system plików, minimalny zapas wolnego miejsca i metodę tworzenia kopii zapasowych.

Aktualny układ Docker Compose dla Jellyfin oddziela katalogi trwałej konfiguracji i pamięci podręcznej, zanim zostaną podmontowane pliki multimedialne. To rozróżnienie ścieżek jest przydatne z punktu widzenia administracji, nawet jeśli oba katalogi początkowo znajdują się na tym samym dysku SSD.

Nie umieszczaj autorytatywnej bazy danych w lokalizacji, którą można wyczyścić podczas rozwiązywania problemów. Skuteczne czyszczenie pamięci podręcznej nigdy nie powinno być w stanie zresetować użytkowników, bibliotek, stanu odtwarzania ani tożsamości serwera.

Traktuj pamięć podręczną i miejsce na transkodowanie jako dane robocze, które można odtworzyć

Pamięć podręczna służy do ograniczania powtarzanych operacji lub przechowywania tymczasowych wyników przetwarzania. Jej wartością jest wydajność i wygoda, a nie trwałość. Zapewnij jej pojemność wystarczającą na największe typowe skoki obciążenia w tle i transkodowania, ale zadbaj, by można ją było odtworzyć bez przywracania całego serwera.

Nie pozwól, by intensywne zapisy do pamięci podręcznej ani transkodowanie dyktowały zasady tworzenia kopii zapasowych bazy danych. Jeśli to samo szybkie urządzenie pełni obie funkcje, użyj osobnych katalogów lub zbiorów danych z oddzielnymi limitami i monitoringiem. Dzięki temu chwilowy wzrost obciążenia nie zajmie wolnego miejsca potrzebnego do zapisu w bazie ani przyszłego przywracania danych.

Jeśli przeglądanie, metadane i operacje na stanie działają wolno, choć sekwencyjny odczyt multimediów pozostaje sprawny, analiza ZimaSpace dotycząca przechowywania interaktywnego stanu serwera multimediów na dysku SSD wskazuje przydatny kolejny test, nie traktując przy tym głównej biblioteki multimediów jako tego samego rodzaju obciążenia pamięci masowej.

Kontener można odtworzyć; stan i przepis na jego odbudowę są niezbędne

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

Praktyczna zasada opisana w tym procesie tworzenia kopii zapasowej woluminów Docker jest taka, że przydatne dane do odzyskiwania znajdują się w woluminach, montowaniach bind, danych aplikacji i definicjach usług, a nie w samym kontenerze, który można odtworzyć.

W przypadku działających baz danych spójność jest ważniejsza niż kopiowanie każdego bajtu podczas pracy usługi. Korzystaj z obsługiwanej przez aplikację metody tworzenia kopii zapasowych albo kontrolowanego zatrzymania lub migawki, odpowiednio do wdrożenia, zamiast traktować dowolne kopiowanie plików na żywo jako sprawdzony punkt odzyskiwania.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kopia zapasowa obok działającego systemu nie chroni przed awarią hosta

Kopia zapasowa obok działającej bazy danych może pomóc w razie przypadkowych zmian, ale nie przetrwa każdej awarii puli, hosta, ataku ransomware, kradzieży ani przerwy w zasilaniu, które mogą unieruchomić środowisko produkcyjne. Przechowuj kopię odzyskiwania na innym urządzeniu lub w innej domenie administracyjnej i zabezpiecz klucze oraz dane logowania potrzebne do jej odczytania.

Plan tworzenia kopii zapasowych w środowisku self-hosting powinien uwzględniać stan, poufne dane, kopie odzyskiwania i instrukcje przywracania. Ten audyt odzyskiwania w środowisku self-hosting kładzie nacisk na kopie przechowywane poza oczywistym obszarem awarii oraz spisane dane potrzebne do odbudowy, zamiast uznawać migawki za kompletny plan.

Nie pozwól, by miejsce docelowe kopii zapasowej było czyszczone zgodnie z tymi samymi zasadami przechowywania pamięci podręcznej lub poleceniami czyszczenia co aktywna pula aplikacji. Kopia zapasowa pełni osobną rolę, nawet jeśli tymczasowo znajduje się w tej samej obudowie.

Określ role pamięci masowej, zanim kupisz lub przeniesiesz dyski

Ta mapa pozwala uniknąć częstego błędu przy przeprojektowywaniu: przeniesienia wszystkiego na najszybszy dysk, choć problem dotyczył tylko opóźnień stanu aplikacji, albo tworzenia kopii zapasowych wszystkich plików tymczasowych z pominięciem definicji usługi potrzebnej do odbudowania kontenera.

Potwierdź separację, wykonując próbę przywracania w środowisku tymczasowym

Przywróć stan Jellyfin do nowej ścieżki lub na odizolowanym hoście, wskaż tę lokalizację w kopii definicji wdrożenia, zapewnij nieniszczący dostęp do reprezentatywnych plików multimedialnych i uruchom usługę bez oryginalnej pamięci podręcznej. Serwer powinien wrócić do działania z oczekiwaną tożsamością, bibliotekami, użytkownikami i ustawieniami, mimo że pamięć podręczna jest początkowo pusta.

Różnicę można zmierzyć dopiero wtedy, gdy kopia zapasowa zostanie przywrócona w odizolowanym środowisku docelowym i zweryfikowana bez korzystania ze stanu środowiska produkcyjnego. Testowa instancja Jellyfin powinna uruchomić się z kopii odzyskiwania, ponownie podłączyć wymagane ścieżki i wykazać, że aktywny wolumin nie uczestniczy ukradkiem w przywracaniu.

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