Czy podczas tworzenia kopii zapasowej Plex Live 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 Plex Live or Stop the Service First? - Zima Store Online

W przypadku zwykłej kopii zapasowej danych aplikacji Plex na poziomie plików najpierw zatrzymaj Plex lub wstrzymaj jego działanie. Kopia wykonywana podczas pracy serwera jest odpowiednia tylko wtedy, gdy metoda tworzenia kopii została zaprojektowana do przechwytywania spójnej działającej bazy danych, a pozostały stan Plexa jest chroniony zgodnie z kompatybilnymi zasadami.

Wybór nie sprowadza się tak naprawdę do „przestoju lub jego braku”. Chodzi o wybór między „prostą spójną kopią” a metodą działającą na żywo, która rozumie aktywne zapisy do bazy danych. Jeśli nie potrafisz wyjaśnić, w jaki sposób metoda działająca na żywo zachowuje prawidłową bazę Plex w konkretnym momencie, zaplanuj krótkie zatrzymanie i zweryfikuj kopię zapasową, zamiast zakładać, że kopiowanie otwartych plików jest bezpieczne.

Wybierz metodę tworzenia kopii przed ustaleniem czasu przestoju

Zacznij od określenia mechanizmu tworzenia kopii. Archiwum tar, rsync, kopia SMB, klient synchronizacji z chmurą lub ogólny migawkowy obraz aktywnych plików działają inaczej niż polecenie tworzenia kopii uwzględniające bazę danych. Bezpieczny stan operacyjny zależy od tego, co narzędzie może zagwarantować, a nie od tego, czy polecenie kopiowania zakończy się pomyślnie.

Dane aplikacji Plex zawierają bazy danych, a także metadane i konfigurację, które mogą zmieniać się podczas pracy serwera. Ogólny przewodnik tworzenia kopii zapasowej Plex wskazuje, że katalog danych Plex zawiera metadane i bazy danych, dlatego ochrona serwera obejmuje więcej niż samo zapisanie plików multimedialnych.

Na potrzeby tej decyzji traktuj zwykłą kopię systemu plików jako wariant zachowawczy, a kopię bazy danych uwzględniającą aplikację jako odrębną technikę. Nie uznawaj kopii wykonywanej podczas pracy serwera za bezpieczną tylko dlatego, że miejsce docelowe otrzymało pliki o oczekiwanych nazwach i rozmiarach.

Zatrzymaj Plex przed zwykłą kopią danych aplikacji na poziomie plików

Jeśli zadanie kopii zapasowej po prostu kopiuje katalog danych aplikacji Plex, najbezpieczniejszym ustawieniem domyślnym jest zatrzymanie usługi lub kontenera Plex na czas kopiowania. Eliminuje to równoczesne zapisy aplikacji podczas przechwytywania bazy danych i powiązanego stanu.

W dyskusji społeczności Plex wieloletni współtwórca techniczny ostrzega, że zwykła kopia plików wykonywana podczas pracy serwera może przechwycić niespójną bazę danych, i odróżnia statyczne pliki metadanych od otwartej bazy danych. To mocny argument za wstrzymaniem działania Plexa, gdy narzędzie do tworzenia kopii nie ma mechanizmu zapewniającego spójność bazy danych.

Przerwa powinna być możliwie krótka: upewnij się, że nie trwa krytyczne skanowanie ani nagrywanie, zatrzymaj Plex, uruchom przygotowane kopiowanie, sprawdź, czy zadanie zostało ukończone, a następnie ponownie uruchom Plex. Nie trać czasu przestoju na sprawdzanie uprawnień miejsca docelowego ani wolnego miejsca, które można było zweryfikować wcześniej.

Używaj kopii wykonywanej na żywo tylko wtedy, gdy metoda obsługi bazy danych na to pozwala

Zatrzymywanie Plexa nie wynika z samej natury SQLite. Kopia wykonywana na żywo może być prawidłowa, gdy metoda korzysta z mechanizmów uwzględniających SQLite, które tworzą spójną migawkę bazy danych, podczas gdy zwykły dostęp aplikacji nadal trwa.

Przegląd strategii tworzenia kopii zapasowych SQLite w środowisku produkcyjnym wyjaśnia, że API kopii zapasowej SQLite może kopiować działającą bazę danych, podczas gdy inne połączenia nadal wykonują zapisy; kopia przedstawia określony stan bazy danych, a nie bezmyślną kopię zmieniających się plików.

Ten wyjątek obejmuje tylko to, co faktycznie chroni metoda uwzględniająca aplikację. Jeśli w ramach procesu używasz kopii działającej na żywo dla bazy SQLite, ale metadane i preferencje kopiujesz osobno, udokumentuj, jak te elementy są zsynchronizowane w czasie, i przetestuj przywracanie. Wysoka dostępność nie ma znaczenia, jeśli połączony artefakt nie może odtworzyć oczekiwanego stanu serwera.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Twórz kopie zapasowe nie tylko pliku bazy danych

Kopia samej bazy danych może zachować ważne informacje o bibliotece, ale pełne odtworzenie Plexa może również zależeć od metadanych, preferencji, danych wtyczek, certyfikatów i ustawień specyficznych dla platformy. Zdecyduj, których elementów potrzebowałbyś, gdyby oryginalny host przestał istnieć, zamiast tworzyć kopię wyłącznie najłatwiejszego do zapisania pliku.

Ochronę plików multimedialnych traktuj jako osobną decyzję dotyczącą pojemności. Konfiguracja Plex może zajmować gigabajty, podczas gdy biblioteka multimediów może mieć rozmiar terabajtów, a te zbiory danych często wymagają różnych harmonogramów i miejsc docelowych kopii zapasowych. Jedno małe archiwum danych aplikacji nie powinno stwarzać iluzji, że same filmy lub rodzinne multimedia są chronione.

Przewodnik ZimaSpace dotyczący spójnych kopii zapasowych kontenerów baz danych jest przydatnym uzupełnieniem, gdy potrzebujesz skoordynować dane aplikacji, stan bazy danych, woluminy trwałe i test przywracania w działającym stosie domowego serwera.

Zweryfikuj kopię zapasową, zanim zaufasz którejkolwiek metodzie

Niezależnie od wybranej metody sprawdź kopię poza aktywnym katalogiem Plex. Potwierdź obecność oczekiwanych plików, zapisz znacznik czasu i rozmiar oraz zweryfikuj bazę danych lub archiwum za pomocą narzędzia odpowiedniego dla danego formatu kopii, zanim usuniesz poprzednią sprawdzoną kopię.

Następnie, gdy jest to możliwe, wykonaj próbę przywracania do odizolowanej ścieżki lub instancji testowej. Celem jest potwierdzenie, że kopia otwiera się jako spójny stan serwera, a nie tylko tego, że oprogramowanie zgłosiło pomyślne zakończenie. Zachowaj co najmniej jeden starszy punkt przywracania, dopóki najnowszy nie przejdzie tego testu.

Metoda tworzenia kopii nie spełnia wymagań operacyjnych, jeśli przywracanie wymaga nieudokumentowanego zgadywania ścieżek, właścicieli, danych uwierzytelniających lub tego, która kopia bazy danych pasuje do którego drzewa metadanych. Uporządkuj procedurę, gdy produkcyjny Plex działa prawidłowo, zamiast odkrywać te zależności po awarii.

Wybierz procedurę o najniższym ryzyku odpowiednią do wymagań dostępności

W przypadku większości domowych serwerów Plex krótki zaplanowany przestój jest najprostszą niezawodną procedurą pełnego kopiowania danych aplikacji na poziomie plików. Zaplanuj go w okresie małego obciążenia, przygotuj wcześniej miejsce docelowe oraz zautomatyzuj ponowne uruchomienie i weryfikację, aby czas niedostępności był przewidywalny.

Wybierz procedurę działającą na żywo tylko wtedy, gdy dostępność uzasadnia dodatkową złożoność, a metoda wyraźnie zapewnia semantykę spójności bazy danych dla chronionego stanu działającego serwera. Zachowaj udokumentowaną procedurę awaryjną polegającą na zatrzymaniu i skopiowaniu danych na wypadek zmiany narzędzia do tworzenia kopii na żywo lub nieudanego testu przywracania.

Praktyczna zasada jest prosta: jeśli kopia jest zwykłym kopiowaniem aktywnych plików Plex, najpierw zatrzymaj usługę; jeśli jest to uwzględniająca aplikację metoda tworzenia kopii bazy danych na żywo, potwierdź jej spójność i zakres testem przywracania. Lepsza jest kopia, którą można wielokrotnie przywracać, a nie ta, która raportuje zerowy czas przestoju.