Czy podczas tworzenia kopii zapasowej Jellyfin należy zatrzymać usługę?

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.

Should You Back Up Jellyfin Live or Stop the Service First? - Zima Store Online

Zatrzymaj Jellyfin na czas pełnej kopii zapasowej, chyba że używana metoda migawek potrafi spójnie przechwycić stan aplikacji podczas zapisu przez usługę.

Kompromis dotyczy przestoju i spójności. Archiwum utworzone po zatrzymaniu usługi łatwo ocenić, ponieważ baza danych, konfiguracja i metadane nie zmieniają się podczas kopiowania. Kopia na żywo może być prawidłowa, gdy mechanizm tworzenia kopii bazy danych lub migawka systemu plików zapewnia spójny punkt w czasie, ale zwykłe rekurencyjne kopiowanie podczas aktywnych zapisów jest trudniejsze do zaufania.

Kopie po zatrzymaniu usługi to prosty i bezpieczny punkt wyjścia

Krótkie zatrzymanie Jellyfin zapobiega nowym zapisom w bazie danych i metadanych, gdy narzędzie do tworzenia kopii przechodzi przez drzewo konfiguracji. Eliminuje to wiele kwestii związanych ze spójnością w przypadku małych serwerów domowych.

Kopiowanie plików na żywo może pominąć transakcje oparte na WAL; kopie zapasowe SQLite uwzględniające transakcje pozwalają uniknąć kopiowania otwartej bazy danych tak, jakby była zwykłym statycznym plikiem.

Zaplanuj przerwę w spokojnym czasie, potwierdź zatrzymanie procesu, skopiuj trwały stan i ponownie uruchom usługę. Zmierz czas przestoju, aby znać jego rzeczywisty koszt operacyjny.

Kopie na żywo wymagają mechanizmu tworzenia spójnych migawek

Migawka systemu plików może zamrozić widok wielu plików w jednej chwili, nawet gdy działająca usługa nadal będzie później działać. Różni się to od powolnego kopiowania zmieniających się plików jeden po drugim.

Aktywne zbiory danych zmieniają się podczas tworzenia kopii, dlatego znaczenie ma intensywność zmian, gdy przechwytywanie trwa dłużej.

Jeśli używasz ZFS, Btrfs lub kopii zapasowej uwzględniającej bazę danych, udokumentuj zapewnianą gwarancję spójności. Nie uznawaj zwykłego kopiowania plików na żywo za równoważne bez przeprowadzenia testów.

Integralność bazy danych jest ważniejsza niż pomyślne zakończenie kopii

Zadanie tworzenia kopii zapasowej może zakończyć się sukcesem, nawet jeśli przechwycona baza danych nie stanowi użytecznego punktu odzyskiwania. Weryfikacja musi sprawdzać bazę danych i stan aplikacji razem.

Wiarygodny zestaw do odzyskiwania powinien unikać niekontrolowanego kopiowania bazy danych podczas aktywnych zapisów; spójność SQLite zależy od zachowania spójnego stanu bazy danych.

Przywróć kopię zapasową do tymczasowej lokalizacji i uruchom kontrolę integralności, zanim zaczniesz na niej polegać. Układ trwałych danych aplikacji ułatwia ten test, ponieważ stan jest oddzielony od wymienialnego kontenera.

-15% OFF

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

Single board computer zimaboard2

Wybierz metodę zgodnie z celem odzyskiwania

Gospodarstwo domowe, które może zaakceptować dwuminutowe okno konserwacyjne, może niewiele zyskać dzięki złożonym mechanizmom tworzenia kopii na żywo. Serwer o rygorystycznych wymaganiach dotyczących dostępności może uzasadniać stosowanie migawek, ale tylko wtedy, gdy przywracanie pozostaje przewidywalne.

Prawidłowy test odzyskiwania po awarii mierzy, czy wybrana kopia zapasowa faktycznie przywraca usługę do użytecznego stanu.

Porównaj czas przestoju podczas tworzenia kopii, czas przywracania i złożoność usuwania awarii. Użyj najprostszej metody, która spełnia wymagania gospodarstwa domowego dotyczące odzyskiwania i sprawdza się podczas rzeczywistej próby przywracania.