Zachowuj stan Plexa definiujący serwer i bibliotekę; tymczasową pamięć podręczną oraz dane transkodowania traktuj jako możliwe do odtworzenia, chyba że projekt odzyskiwania wymaga innego podejścia.
Kluczowa jest możliwość odzyskania danych, a nie rozmiar folderu. Konfigurację, bazy danych, metadane, grafiki, informacje o obejrzanych materiałach oraz tożsamość serwera trudno lub żmudnie odtworzyć w spójny sposób, podczas gdy tymczasowe pliki transkodowania i wiele elementów pamięci podręcznej można wygenerować ponownie. Przed podjęciem decyzji, gdzie umieścić daną ścieżkę, określ, co stanie się po jej usunięciu.
Stan serwera to coś więcej niż plik ustawień
Wdrożenie Plexa jest definiowane przez grupę trwałych plików, a nie tylko przez widoczne preferencje w interfejsie WWW. Baza danych biblioteki i katalogi metadanych przechowują powiązania oraz stan serwera, dzięki którym odtworzona instancja wygląda jak poprzednia.
Przechowywanie metadanych Plexa obejmuje bazy danych, grafiki, indeksy oraz inne pliki stanu serwera.
Wymień wszystkie zamontowane ścieżki Plexa i zaznacz te, które byłyby potrzebne do odtworzenia tych samych bibliotek i metadanych na czystym hoście. Jeśli ścieżka zawiera bazę danych serwera lub stan metadanych, uwzględnij ją w zestawie trwałej kopii zapasowej. Przechowywanie trwałych danych kontenera poza wymiennym środowiskiem uruchomieniowym pomaga oddzielić warstwy możliwe do odtworzenia od stanu, który musi przetrwać wymianę kontenera.
Pamięć podręczna jest cenna, ale zwykle można ją odtworzyć
Pamięć podręczna może zmniejszyć opóźnienia, ale nie jest kanoniczną kopią biblioteki. Utrata rozgrzanej pamięci podręcznej może sprawić, że serwer przez pewien czas będzie działał wolniej, jednak nie należy traktować jej tak samo jak utraty bazy danych.
Buforowanie stron w Linuksie może ograniczyć wielokrotny dostęp do pamięci masowej, gdy dane zostaną rozgrzane w pamięci.
Uruchom ponownie instancję testową po usunięciu wyłącznie znanej, jednorazowej pamięci podręcznej i porównaj zachowanie podczas rozgrzewania z nienaruszonym serwerem. Jeśli serwer utraci tożsamość biblioteki lub ustawienia, usunięta ścieżka nie była jedynie jednorazową pamięcią podręczną.
Spójność bazy danych zmienia priorytet kopii zapasowej
Trwałe dane są przydatne tylko wtedy, gdy przechwycona baza danych jest wewnętrznie spójna. Kopia bazy utworzona podczas zapisu może być trudniejsza do zaufania niż kopia wykonana w kontrolowanym, spokojnym stanie.
Bezpieczny zapis w SQLite sprzyja kontrolowanym operacjom zapisu, dlatego aktywnej bazy Plexa nie należy używać jako testu uprawnień.
Jeśli to możliwe, zaplanuj okno tworzenia kopii zapasowej, w którym proces zapisujący zostanie wstrzymany lub zatrzymany, a następnie sprawdź, czy skopiowaną bazę danych można otworzyć. Jeśli test odtwarzania nie powiedzie się mimo pomyślnego skopiowania plików, najpierw napraw spójność kopii zapasowej, a dopiero potem zwiększ okres przechowywania.
Tymczasowe miejsce na transkodowanie należy do innej kategorii odzyskiwania
Wynik transkodowania to dane robocze utworzone na potrzeby odtwarzania, a nie autorytatywna biblioteka. Można umieścić je z myślą o szybkości i pojemności, bez narzucania takiej samej polityki trwałości jak w przypadku bazy Plexa.
Gdy wymagane jest transkodowanie Plexa, zgodność z klientem przenosi dekodowanie i kodowanie na serwer.
W pliku wdrożenia udokumentuj osobno miejsca montowania transkodowania i pamięci podręcznej oraz miejsce montowania trwałych danych Plexa. Jeśli tymczasowa ścieżka jest jedynym miejscem, w którym znajduje się unikalne ustawienie lub plik bazy danych, zaklasyfikuj ją ponownie przed kolejną migracją.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

