Czy można zachować historię oglądania podczas migracji serwera multimediów?

Tak, historię oglądania można zachować, jeśli migracja obejmuje bazę użytkowników, tożsamość multimediów oraz zgodny stan aplikacji na nowym serwerze.

Samo skopiowanie plików filmowych nie przenosi oznaczeń obejrzenia, pozycji wznowienia, ulubionych, kont użytkowników ani wyboru ścieżek. Te dane znajdują się w trwałej bazie danych serwera multimediów i są powiązane z identyfikatorami użytkowników oraz multimediów. Najbezpieczniejszym rozwiązaniem jest pełna migracja instancji na tej samej platformie, wykonana na podstawie spójnej kopii zapasowej po zatrzymaniu serwera, z użyciem zgodnych wersji i stabilnych ścieżek kontenerów oraz z odizolowanym testem przywracania, zanim serwer docelowy stanie się aktywny.

Określ, czy przenosisz instancję, czy zmieniasz platformę

Migracja tej samej aplikacji z jednego hosta na drugi zwykle pozwala zachować pełny stan serwera. Przeniesienie z Plex do Jellyfin, z Emby do Jellyfin lub z innej platformy wymaga eksportu, usługi synchronizacji, wtyczki albo translacji opartej na API, ponieważ bazy danych korzystają z różnych schematów i identyfikatorów.

Użytkownicy Jellyfin prosili o łatwiejszy eksport kont, historii oglądania i ustawień użytkowników właśnie dlatego, że danych użytkowników nie można po prostu skopiować wraz z folderem multimediów.

Przed rozpoczęciem wybierz jedną ścieżkę: pełne przywrócenie instancji tego samego serwera multimediów albo udokumentowane przeniesienie stanu oglądania przy zmianie platformy. Nie łącz obu metod, częściowo kopiując jedną bazę danych do nowo zeskanowanego miejsca docelowego.

Utwórz kopię zapasową całego trwałego stanu serwera

Zainwentaryzuj konfigurację, bazę danych, użytkowników, wtyczki, metadane, certyfikaty, ustawienia zadań zaplanowanych i środowisko kontenera. Zapisz używaną wersję aplikacji, tag obrazu, lokalizację bazy danych oraz wszystkie trwałe punkty montowania.

Stan oglądania może obejmować więcej niż wartość logiczną. W dyskusji Jellyfin wskazano takie pola jak status obejrzenia, liczba odtworzeń, pozycja odtwarzania, data ostatniego odtworzenia, ulubione oraz wybrane ścieżki w rekordach danych użytkownika.

Wykonaj kopię zapasową całego obsługiwanego zestawu danych trwałych zamiast eksportować tylko jedną tabelę, chyba że nie istnieje pełna ścieżka przywracania. Częściowe przeniesienie bazy może zachować jedno pole, a jednocześnie uszkodzić identyfikatory użytkowników, odwołania do multimediów, zgodność schematu lub historię nowszych migracji.

Zatrzymaj serwer albo użyj migawki spójnej z bazą danych

Zablokuj odtwarzanie, skanowanie, odświeżanie metadanych i zmiany użytkowników na czas tworzenia końcowej kopii zapasowej. Zatrzymaj proces serwera multimediów przed skopiowaniem plików SQLite, chyba że pamięć masowa i aplikacja obsługują spójną kopię zapasową online.

W dyskusji dotyczącej kopii zapasowych Jellyfin ostrzeżono, że kopiowanie aktywnych plików SQLite może uchwycić niespójny stan, ponieważ baza danych może być używana podczas zwykłej kopii systemu plików.

Po zatrzymaniu usługi zapisz sumy kontrolne i rozmiary plików, a następnie pozostaw serwer źródłowy bez zmian, dopóki miejsce docelowe nie przejdzie weryfikacji. Nie pozwól, aby oba serwery zapisywały dane do tej samej bazy ani do tego samego celu synchronizacji stanu oglądania podczas przełączania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kontroluj wersje aplikacji i kierunek aktualizacji

Jeśli to możliwe, najpierw przywróć dane do tej samej wersji aplikacji. Przed aktualizacją serwera docelowego sprawdź, czy wtyczki, schemat bazy danych i ścieżki kontenerów są zgodne.

Migracje baz danych mogą być jednokierunkowe, a przywrócona instancja może nie uruchomić się, gdy zarejestrowany stan migracji nie odpowiada rzeczywistemu schematowi. Aktualne zgłoszenie Jellyfin opisuje konflikt stanu migracji po przywróceniu.

Uruchom przywrócony serwer bez publicznego dostępu klientów, sprawdź dziennik migracji i wykonaj kolejną migawkę przed aktualizacją. Nigdy nie testuj nowszej wersji na jedynej kopii bazy danych, a następnie nie oczekuj, że starsza wersja serwera ponownie ją otworzy.

Zachowaj stabilne ścieżki multimediów i tożsamość elementów

Zachowaj te same ścieżki widoczne w kontenerze, nawet jeśli zmienią się dyski hosta. Na przykład zamapuj nową pulę pamięci masowej na istniejące ścieżki /media/movies i /media/tv, zamiast uczyć serwer docelowy zupełnie nowych katalogów głównych bibliotek.

Zmiana ścieżek może utworzyć nowe rekordy multimediów lub pozostawić stare wpisy obok przywróconych. Zgłoszenie Jellyfin łączy usunięte ścieżki bibliotek z trwałymi nieaktualnymi metadanymi oraz zduplikowanym zachowaniem funkcji kontynuowania oglądania.

Przed uruchomieniem pełnego skanowania zweryfikuj jeden film i jeden odcinek na podstawie ścieżki pliku oraz wewnętrznej tożsamości elementu. Jeśli miejsce docelowe wykazuje każdy plik jako nowy, zatrzymaj proces i popraw mapowanie ścieżek, zanim powiązania stanu oglądania zostaną rozproszone między zduplikowane rekordy.

Zachowaj użytkowników i ich identyfikatory

Przywróć użytkowników wraz z bazą danych, zamiast ręcznie odtwarzać konta pod tymi samymi nazwami wyświetlanymi. Widoczna nazwa użytkownika nie gwarantuje, że użytkownik w miejscu docelowym ma ten sam wewnętrzny identyfikator.

Ręczne przywracanie historii zwykle dotyczy tabeli danych użytkownika, ale rekordy zależą zarówno od odwołań do użytkowników, jak i do multimediów. Przenoszenie lokalizacji bibliotek bez utraty metadanych wymagało więc starannego zarządzania ścieżkami i bazą danych, a nie bezrefleksyjnego ponownego skanowania przeniesionych plików.

Po przywróceniu zaloguj się jako każdy reprezentatywny użytkownik i porównaj oznaczenia obejrzenia, elementy rozpoczęte, pozycje wznowienia, ulubione, wybór ścieżki dźwiękowej oraz wybór napisów. Nie oceniaj powodzenia migracji wyłącznie na podstawie konta administratora.

Przy zmianie platformy użyj synchronizacji lub eksportu

Gdy aplikacje źródłowa i docelowa są różne, wyeksportuj historię za pomocą obsługiwanej wtyczki, narzędzia API lub neutralnej usługi, takiej jak platforma śledzenia oglądania. Przed zsynchronizowaniem całej biblioteki przetestuj niewielką próbkę.

Jawnie dopasuj użytkowników i tytuły, traktując odcinki, wydania, alternatywne wersje oraz zmienione nazwy plików jako potencjalne konflikty tożsamości. Sam tytuł filmu jest zbyt mało precyzyjny, gdy kilka lat lub wersji ma tę samą nazwę.

Zachowaj eksport historii źródłowej nawet po pomyślnym pierwszym imporcie. Transfer powinien być powtarzalny lub możliwy do skontrolowania, aby brakujących użytkowników i niedopasowane tytuły można było poprawić bez ponownego rozpoczynania migracji.

Wykonaj odizolowane przywracanie i przełącz serwer dopiero po weryfikacji

Uruchom miejsce docelowe na tymczasowym porcie, wyłączając zaplanowane skanowania, webhooki i synchronizację zewnętrzną. Zweryfikuj użytkowników, liczbę elementów w bibliotekach, sumy obejrzanych materiałów, pozycje wznowienia, playlisty, kolekcje oraz kilka losowo wybranych tytułów.

Procedura migracji danych NAS w ZimaSpace zawiera ogólną zasadę: zachowaj źródło, dopóki skopiowany stan nie zostanie zweryfikowany z poziomu miejsca docelowego.

Migrację można uznać za zakończoną dopiero wtedy, gdy przywrócona instancja przetrwa ponowne uruchomienie, ścieżki pozostaną stabilne, reprezentatywni użytkownicy zachowają historię, a nowe odtworzenia będą prawidłowo aktualizować serwer docelowy. Pozostaw serwer źródłowy wyłączony, ale możliwy do odzyskania, do czasu gdy nowy serwer przejdzie kilka dni normalnego użytkowania i zostanie wykonana świeża kopia zapasowa.