Kan du bevara visningshistoriken vid en migrering av medieservern?
Ja, visningshistoriken kan bevaras när migreringen inkluderar användardatabasen, medieidentiteten och kompatibelt applikationstillstånd på den nya servern.
Att bara kopiera filmfiler flyttar inte spelade-markeringar, återupptagningspositioner, favoriter, användarkonton eller val per spår. Dessa uppgifter finns i mediaserverns beständiga databas och är kopplade till användar- och medieidentifierare. Den säkraste metoden är en fullständig migrering av en instans på samma plattform, med en konsekvent säkerhetskopia medan servern är stoppad, matchande versioner, stabila sökvägar i containrar och ett isolerat återställningstest innan destinationen blir den aktiva servern.
Fastställ om du flyttar en instans eller byter plattform
En migrering av samma applikation från en värd till en annan kan vanligtvis bevara hela serverns tillstånd. En flytt från Plex till Jellyfin, Emby till Jellyfin eller en annan plattform kräver en export, synkroniseringstjänst, ett insticksprogram eller en API-baserad översättning, eftersom databaserna använder olika scheman och identifierare.
Jellyfin-användare har efterfrågat en enklare export av konton, visningshistorik och användarinställningar just eftersom användardata inte är en enkel kopia av mediemappen.
Välj en metod innan du börjar: fullständig återställning av instansen för samma mediaserver, eller en dokumenterad överföring av visningsstatus vid plattformsbyte. Kombinera inte båda genom att delvis kopiera en databas till en nyskannad destination.
Säkerhetskopiera hela den beständiga serverstatusen
Inventera konfigurationen, databasen, användarna, insticksprogrammen, metadata, certifikaten, inställningarna för schemalagda uppgifter och containermiljön. Notera den körande applikationsversionen, avbildningstaggen, databasens plats och alla beständiga monteringar.
Visningsstatus kan omfatta mer än en boolesk flagga. En Jellyfin-diskussion identifierar fält som spelad status, antal uppspelningar, uppspelningsposition, datum för senaste uppspelning, favoriter och valda strömmar i användardataposterna.
Säkerhetskopiera hela den stödda uppsättningen beständiga data i stället för att bara exportera en tabell, om det inte finns någon fullständig återställningsväg. En partiell databasflytt kan bevara ett fält men bryta användar-ID:n, mediereferenser, schemakrav eller nyare migreringshistorik.
Stoppa servern eller använd en databaskonsistent ögonblicksbild
Förhindra uppspelning, skanningar, metadatauppdateringar och användarändringar medan den slutliga säkerhetskopian skapas. Stoppa mediaserverprocessen innan du kopierar SQLite-filer, såvida inte lagringen och applikationen stöder en konsistent metod för säkerhetskopiering online.
En Jellyfin-diskussion varnar för att kopiering av aktiva SQLite-filer kan fånga ett inkonsistent tillstånd, eftersom databasen kan vara i bruk under en vanlig säkerhetskopiering av filsystemet.
Registrera kontrollsummor och filstorlekar efter att tjänsten har stoppats och låt sedan källservern förbli oförändrad tills destinationen har verifierats. Låt aldrig båda servrarna skriva till samma databas eller mål för synkronisering av visningsstatus under övergången.
Håll applikationsversioner och uppgraderingsriktning under kontroll
Återställ till samma applikationsversion först när det är möjligt. Kontrollera att insticksprogram, databasschema och sökvägar i containrar stämmer innan destinationen uppgraderas.
Databasmigreringar kan vara enkelriktade, och en återställd instans kan sluta fungera när dess registrerade migreringsstatus inte stämmer överens med det faktiska schemat. Ett aktuellt Jellyfin-ärende dokumenterar en konflikt i den återställda migreringsstatusen.
Starta den återställda servern utan åtkomst för externa klienter, läs migreringsloggen och ta ytterligare en ögonblicksbild innan någon uppgradering görs. Testa aldrig en nyare version mot den enda kopian av databasen och förvänta dig sedan att den gamla serverversionen ska kunna öppna den.
Bevara stabila mediesökvägar och objektidentitet
Behåll samma sökvägar som är synliga i containern även om värddiskarna byts ut. Mappa till exempel om en ny lagringspool till de befintliga sökvägarna /media/movies och /media/tv i stället för att lära destinationen helt nya biblioteksrötter.
Ändrade sökvägar kan skapa nya medieposter eller lämna gamla poster bredvid de återställda. Ett Jellyfin-ärende kopplar borttagna bibliotekssökvägar till beständig gammal metadata och dubbla poster i fortsätt titta.
Verifiera en film och ett avsnitt utifrån filsökväg och intern objektidentitet innan du startar en fullständig skanning. Om destinationen ser varje fil som ny ska du stoppa och korrigera sökvägsmappningen innan kopplingarna till visningsstatus splittras mellan dubblettposter.
Håll användare och deras identifierare konsekventa
Återställ användarna med databasen i stället för att skapa om konton manuellt med samma visningsnamn. Ett synligt användarnamn bevisar inte att destinationsanvändaren har samma interna identifierare.
Manuell återställning av historik riktar sig ofta mot användardatatabellen, men posterna är beroende av både användar- och mediereferenser. Att flytta biblioteksplatser utan att förlora metadata har därför krävt noggrann hantering av sökvägar och databaser i stället för en blind omskanning av flyttade filer.
Efter återställningen ska du logga in som varje representativ användare och jämföra spelade-markeringar, pågående titlar, återupptagningspositioner, favoriter, ljudval och undertextval. Bedöm inte resultatet enbart utifrån administratörskontot.
Använd en synkroniserings- eller exportmetod vid plattformsbyte
När källans och destinationens applikationer skiljer sig åt ska du exportera historiken via ett stödd insticksprogram, ett API-verktyg eller en neutral tjänst, exempelvis en plattform för spårning av visning. Testa ett litet urval innan du synkroniserar hela biblioteket.
Matcha användare och titlar uttryckligen och behandla avsnitt, utgåvor, alternativa klipp och omdöpta filer som möjliga identitetskonflikter. En filmtitel ensam är för svag när flera årtal eller versioner har samma namn.
Behåll en export av källans historik även efter att den första importen har lyckats. Överföringen bör kunna upprepas eller granskas, så att saknade användare och felmatchade titlar kan korrigeras utan att migreringen behöver startas om.
Gör en isolerad återställning och genomför övergången först efter verifiering
Starta destinationen på en tillfällig port med schemalagda skanningar, webhooks och extern synkronisering inaktiverade. Verifiera användare, biblioteksantal, totalt antal spelade titlar, återupptagningspositioner, spellistor, samlingar och flera slumpmässigt utvalda titlar.
ZimaSpaces arbetsflöde för NAS-datamigrering ger den övergripande regeln: behåll källan tills det kopierade tillståndet har verifierats från destinationen.
Migreringen är klar först när den återställda instansen överlever en omstart, sökvägarna förblir stabila, representativa användare behåller sin historik och nya uppspelningar uppdaterar destinationen korrekt. Håll källan offline men återställningsbar tills den nya servern har klarat flera dagars normal användning och en ny säkerhetskopia.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
