När bör du bygga om i stället för att reparera en Plex-installation?
Bygg om Plex först när det gamla applikationstillståndet inte längre är en tillförlitlig återställningskälla. Om serveridentiteten, konfigurationen, databasen och lagringssökvägarna fortfarande är kända, reparerar du först det minsta felaktiga lagret. Om reparationen misslyckas men det finns en verifierad säkerhetskopia, återställer du den innan du börjar om.
En ”ominstallation” innebär inte automatiskt en ombyggnad. När Plex-paketet eller containern ersätts kan den beständiga databasen och konfigurationen lämnas orörda, medan en verklig ombyggnad medvetet överger eller återställer detta tillstånd. Fatta beslutet utifrån det beständiga datats skick, inte utifrån hur frustrerande det aktuella symptomet känns.
Definiera reparation, återställning och ombyggnad innan du väljer
Använd tre olika ord för tre olika åtgärder. Reparation ändrar den minsta skadade komponenten samtidigt som det aktuella Plex-tillståndet bevaras. Återställning ersätter ett skadat tillstånd med en känd fungerande säkerhetskopia. Ombyggnad skapar ett nytt Plex-tillstånd och innebär att vissa bibliotek, metadata, inställningar, visningshistorik eller serveridentitet kan behöva återskapas eller migreras.
Den skillnaden är viktig eftersom en ominstallation av programfilerna kan lämna Plex-tillståndet på plats. Western Digital anger att den dokumenterade avinstallationen på My Cloud lämnar Plex-biblioteken och databasen orörda. En återställning kräver ett separat steg för att radera tillståndet.
Innan du väljer en ombyggnad ska du identifiera vilket lager som faktiskt är trasigt: paketet eller containern, körningsdefinitionen, lagringsmonteringen, behörigheterna, inställningarna eller biblioteksdatabasen. En nyinstallation åtgärdar bara vissa av dessa lager, så om du använder den som första åtgärd kan det verkliga felet döljas utan att försvinna.
Reparera först när det ursprungliga Plex-tillståndet fortfarande är tillförlitligt
Reparera först när Plex fortfarande öppnar den förväntade servern, sökvägen till applikationsdata är ifylld, databasen finns och felet är tillräckligt avgränsat för att kunna återskapas. Exempel är en skadad databas som fortfarande har en läsbar återställningsväg, ett trasigt index eller ett konfigurationsfel som kan återställas.
En aktuell praktisk guide visar ett arbetsflöde för databasreparation där Plex stoppas, reparationsverktyget körs och servern startas igen i stället för att hela installationen kasseras. Den användbara principen är att bevara det befintliga tillståndet samtidigt som du testar om det skadade lagret kan göras giltigt igen.
Godkänn reparationen först när samma serveridentitet återkommer, representativa bibliotek öppnas, sökningar och visningshistorik fungerar normalt och en kontrollerad omstart inte återskapar felet. Om reparationsverktyget rapporterar ett fel eller databasen fortfarande är ogiltig ska du sluta upprepa samma ändring och gå vidare till återställningsgrenen.
Gå över till återställning när reparationen inte kan ge en giltig databas
En misslyckad reparation innebär inte automatiskt en ombyggnad. Om du har en verifierad säkerhetskopia från tiden före korruptionen ska du återställa den kopian till en isolerad eller tydligt reversibel plats och testa den innan du raderar det aktuella tillståndet.
En praktisk artikel om återställning av Plex-databaser behandlar återställning av en säkerhetskopia av databasen som nästa återställningsgren efter att reparationen misslyckats. Det bevarar mer av den ursprungliga servern än en ren ombyggnad när själva säkerhetskopian är felfri.
Återställningsgrenen är godkänd när Plex kan öppna det återställda tillståndet, känna igen de förväntade biblioteken och mediesökvägarna och klara ytterligare en omstart utan att databasfelet återkommer. Om alla tillgängliga säkerhetskopior är oläsbara, ofullständiga eller redan innehåller samma korruption är tröskeln för en ombyggnad betydligt närmare.
Bygg om när tillståndskällan saknas eller inte längre är tillförlitlig
Bygg om när den beständiga källa som du annars skulle reparera eller återställa inte går att lita på. Det kan innebära att katalogen med applikationsdata saknas, att det inte finns någon användbar säkerhetskopia, att databasen inte kan repareras eller återställas eller att upprepade tester visar att det återställda tillståndet omedelbart återgår till samma oåterställbara fel.
En ombyggnad kan också vara ett medvetet val när den gamla installationen innehåller flera år av osäkra migreringar och du föredrar en ny serveridentitet framför att fortsätta bära på okänt tillstånd. Avvägningen är verklig: ett rent tillstånd tar bort den skadade historiken, men det innebär också att du inte längre kan räkna med att gamla metadata, inställningar och relationer överlever automatiskt.
Använd inte upprepad korruption som bevis för att en ren Plex-databas är det enda problemet. Om ett nybyggt tillstånd blir skadat igen ska du undersöka filsystemet, lagringsenheten, plötsliga strömavbrott, minnesstabiliteten och andra underliggande orsaker. En ombyggnad av applikationen kan inte göra ett opålitligt lager för lagring av tillstånd tillförlitligt.
Bygg inte om på grund av fel i container, montering eller behörigheter
En container som inte startar, en tom mediamontering, ett behörighetsfel eller ett saknat nätverksalias kan få Plex att verka helt trasigt trots att det beständiga tillståndet fortfarande är friskt. Det är fel i körningen eller beroendena, inte bevis för att biblioteksdatabasen ska kasseras.
ZimaSpaces arbetsflöde för återställning av en enskild container behåller volymer och friska beroenden på plats samtidigt som endast det felaktiga tjänstelagret ersätts. Det är den säkrare modellen när Plex-tillståndet är intakt men körningsmiljön runt det har ändrats.
Om anslutning av rätt montering, identitet, nätverk eller containerdefinition återställer den ursprungliga servern ska du stanna där. En ombyggnad skulle skapa mer migreringsarbete utan att åtgärda ett bekräftat problem med det beständiga tillståndet. Gå vidare till återställning eller ombyggnad först när felet följer själva applikationstillståndet.
Bevara bevis och en återställningspunkt innan du börjar om
Innan en verklig ombyggnad ska du bevara det gamla trädet med applikationsdata, databassäkerhetskopior, inställningar, distributionsdefinitionen, loggar och det exakta fel som fick dig att sluta reparera. Även ett skadat tillstånd kan innehålla visningshistorik, metadata eller konfigurationsdetaljer som är användbara vid migrering eller efteranalys.
Bygg den nya servern bredvid den bevarade återställningspunkten i stället för att skriva över den på plats, när lagringsutrymmet tillåter det. Lägg till ett representativt bibliotek, verifiera den nya databasen och migrera sedan endast det tillstånd du medvetet litar på. På så sätt förblir ”börja om” reversibelt tills du har bevisat att den nya servern faktiskt löser det ursprungliga felet.
Det slutliga beslutet är enkelt: reparera så länge det aktuella tillståndet är tillförlitligt, återställ när en känd fungerande kopia kan ersätta det skadade tillståndet och bygg om först när ingen av dessa vägar ger en giltig server som fungerar upprepade gånger. Behåll tidigare bevis tills den rena installationen har klarat normal användning, en omstart och en ny säkerhetskopiering.
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.
