Så säkerhetskopierar du Plex utan att fånga en inkonsekvent databas
För en fullständig säkerhetskopiering av Plex appdata ska du stoppa Plex innan filsystemskopian eller ögonblicksbilden skapas. För enbart kärndatabasen är Plex schemalagda säkerhetskopiering den applikationsmedvetna metoden.
Plex skriver databaser, metadata, inställningar och cache medan servern körs, så ett generiskt säkerhetskopieringsjobb kan fånga filer vid olika tidpunkter. Det betyder inte att alla säkerhetskopieringar i drift är korrupta, men det innebär att en rå kopia är svårare att lita på om inte applikationen eller lagringslagret samordnar konsistensen. Bestäm först om du behöver Plex kärndatabas eller hela serverns tillstånd, välj sedan en metod som motsvarar den omfattningen och verifiera en återställningsväg innan du betraktar säkerhetskopieringen som slutförd.
Skilj mellan säkerhetskopiering av kärndatabasen och full säkerhetskopiering av serverdata
Plex schemalagda uppgifter kan säkerhetskopiera kärndatabaserna som innehåller information om visningsstatus och matchningar. Det är användbart vid databasåterställning, men Plex säger uttryckligen att det inte ersätter en säkerhetskopiering av hela datakatalogen för Plex Media Server. Behandla dessa två säkerhetskopior som olika återställningsverktyg i stället för att anta att en fil täcker allt.
Plex dokumentation om säkerhetskopiering rekommenderar att du säkerhetskopierar serverns huvudsakliga datakatalog och påpekar att cache kan uteslutas på vissa plattformar. Definiera säkerhetskopieringen medvetet så att tillfällig cache inte gör arkivet onödigt stort, samtidigt som kritiska databas- och metadatatillstånd skyddas.
Om målet är att ”återställa servern exakt som den var” ska du inkludera det beständiga appdataträdet och alla plattformsspecifika inställningar som Plex kräver. Om målet bara är att ”återställa visningsstatus och den centrala biblioteksdatabasen” kan den schemalagda databassäkerhetskopieringen vara en mindre och mer fokuserad reservlösning.
Pausa Plex innan en rå filsystemskopia
För en enkel säkerhetskopiering på filnivå ska du stoppa Plex-containern och bekräfta att den har avslutats innan du kopierar eller skapar en ögonblicksbild av den beständiga datasökvägen. Håll avbrottet kort: stoppa, fånga den konsistenta punkten, starta om och låt sedan den långsammare kopieringen till en extern plats fortsätta från ögonblicksbilden om filsystemet stöder det arbetsflödet.
SQLite:s dokumentation för säkerhetskopierings-API:t visar varför kopiering av en aktiv databas är ett samordningsproblem och inte bara en fråga om filstorlek. En applikationsmedveten säkerhetskopiering eller en pausad ögonblicksbild ger dig ett definierat databastillstånd. Att blint kopiera databaser, WAL-filer och metadatafiler som ändras ger mindre säkerhet kring återställningspunkten.
Stoppa inte Plex i flera timmar medan en stor säkerhetskopiering går igenom långsam lagring om din NAS kan skapa en ögonblicksbild direkt. Det säkrare mönstret är en kort skrivpaus för att fastställa konsistensen, följd av ett ögonblicksbilds- eller arkiveringsarbetsflöde som låter tjänsten återgå i drift medan säkerhetskopian flyttas någon annanstans.
Hantera loggar, cache och beständigt tillstånd enligt olika återställningsregler
Cache och detaljerade loggar kan ändras snabbt och behöver vanligtvis inte samma lagringstid som Plex databas och metadata. Genom att separera dessa sökvägar blir säkerhetskopiorna mindre och återställningsgränsen tydligare. Det hindrar också ett omfattande logg- eller cacheträd från att ta upp utrymmet som reserverats för applikationens tillstånd.
ZimaSpace-guiden om att separera containerloggar från appdata förklarar varför applikationstillstånd, loggar och cache har olika livscykler och återställningskrav. Plex drar nytta av samma policy även om alla tre börjar i samma containerkonfiguration.
Om du ändrar säkerhetskopieringens omfattning ska du genomföra ett återställningstest mot en tillfällig kopia eller en isolerad container. En säkerhetskopieringspolicy valideras inte bara genom en lyckad uppladdning. Den valideras när Plex kan öppna den återställda databasen och metadatan med det förväntade servertillståndet.
Verifiera säkerhetskopian genom att återställa ett känt tillstånd
Välj en liten uppsättning fakta som du kan verifiera efter en återställning: servernamn, ett bibliotek, ett visat objekt, ett delvis visat objekt och en inställning som du känner till. Ett återställningstest ska återställa dessa fakta utan att be Plex skapa en ny server eller bygga om biblioteket från mediefilerna.
Plex beskriver en procedur för databasåterställning som börjar med att servern stoppas och den aktiva databasen ersätts med en säkerhetskopia. Även om din fullständiga säkerhetskopieringsmetod skiljer sig åt är gränsen att stoppa servern före databasbytet en användbar återställningsregel.
Om återställningstestet misslyckas ska du åtgärda säkerhetskopieringsmetoden innan du ökar lagringstiden eller automatiserar fler kopior. Ta till databasreparation först när en känd fungerande säkerhetskopia inte kan återställas. Skriv inte över den senast återställningsbara kopian medan du experimenterar med en skadad aktiv databas.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
