Inbyggda Jellyfin-säkerhetskopior eller säkerhetskopiering på filnivå: Vilken bör du använda?
Inbyggda Jellyfin-säkerhetskopior och säkerhetskopior på filnivå skyddar överlappande men olika återställningsomfattningar. Det inbyggda systemet förstår Jellyfin-applikationsdata och kan skapa ett arkiv medan servern fortfarande är online. En manuell säkerhetskopiering på filnivå kan fånga ett bredare drifttillstånd, men Jellyfin måste stoppas innan dess aktiva applikationsdata kopieras på ett säkert sätt.
Den bästa planen är ofta inte antingen eller. Använd den inbyggda metoden för frekventa återställningspunkter på applikationsnivå och en filsystems- eller filnivåmetod med stoppad server när du behöver återskapa värdsökvägar, konfiguration, containerdefinitioner eller ett bredare servertillstånd.
Inbyggda säkerhetskopior är bäst för vanliga återställningspunkter online
Det aktuella säkerhetskopieringssystemet i Jellyfin kan skydda databasen och även inkludera metadata, undertexter och trickplay-data medan servern körs. Det gör det praktiskt att skapa schemalagda återställningspunkter utan att avsiktligt avbryta normal uppspelning.
Jellyfins dokumentation om säkerhetskopiering anger att inbyggda säkerhetskopior kan köras online, medan manuella säkerhetskopior av datakatalogen kräver att servern stoppas. Även online-metoden bör helst köras under perioder med lägre aktivitet och utan att en biblioteksskanning pågår samtidigt.
Detta är det bästa standardvalet när återställningsmålet är att ”återställa den här Jellyfin-instansen till ett känt applikationstillstånd”.
Säkerhetskopior på filnivå är bäst när återställningen även omfattar värdens struktur
En kopiering på filnivå kan inkludera beständiga applikationsmappar, Compose-filer, miljöfiler, konfiguration för omvänd proxy, tjänsteenheter, skript, certifikat och andra driftresurser som ett arkiv som endast gäller Jellyfin inte automatiskt känner till.
Den bredare omfattningen är användbar vid ett havererat systemdisk eller en migrering till en ersättningsvärd. Nackdelen är konsekvensen: vanliga filkopieringsverktyg förstår inte en SQLite-databas som förändras, så stoppa Jellyfin korrekt innan du kopierar dess aktiva beständiga tillstånd.
ZimaSpace-guiden om lagringslayouter i Jellyfin som innebär återställningsrisk lyfter fram samma problem: en säkerhetskopia är ofullständig när ingen kan återskapa de sökvägar, monteringar, behörigheter och externa beroenden som den återställda servern behöver.
Databasmedveten säkerhetskopiering skiljer sig från att kopiera en aktiv SQLite-fil
SQLite stöder konsekvent säkerhetskopiering online via databasmedvetna gränssnitt, men en generell kopierare som läser filer medan Jellyfin ändrar dem får inte automatiskt samma garanti.
SQLite:s säkerhetskopierings-API är utformat för att kopiera en aktiv databas till ett konsekvent mål genom samordnade databasoperationer. Därför räcker det inte som bevis för en fungerande manuell Jellyfin-säkerhetskopiering att ”filerna kopierades utan fel”.
Om din manuella metod endast består av rsync, SMB-kopiering, zip eller en generell filsystemskopiering ska du stoppa Jellyfin först, såvida inte lagringsögonblicksbilden samordnas med applikationens skrivningar.
Jämför omfattning innan du jämför bekvämlighet
| Dimension | Inbyggd säkerhetskopiering | Säkerhetskopiering på filnivå |
|---|---|---|
| Servern kan vara online | Ja, helst vid låg aktivitet | Stoppa Jellyfin vid vanlig kopiering |
| Jellyfin-databas | Ingår | Ingår om beständiga sökvägar kopieras korrekt |
| Metadata/undertexter/trickplay | Stöds selektivt | Ingår när de kopierade sökvägarna innehåller dem |
| Compose-/värdskript/proxykonfiguration | Inte automatiskt | Kan inkluderas |
| Arbetsflöde för byte av värd | Bra för Jellyfin-tillstånd | Bättre för ett bredare drifttillstånd |
| Konsekvensrisk | Applikationsmedveten | Beror på om skrivningar har stoppats eller på metoden för ögonblicksbilder |
Förvara säkerhetskopian utanför Jellyfins aktiva felområde
Ingen av metoderna skyddar mot förlust av lagringspoolen om alla säkerhetskopior ligger under samma havererade filsystem. Kopiera verifierade säkerhetskopieringsarkiv eller återställningsuppsättningar från en stoppad server till en annan disk, NAS eller extern plats.
Behåll minst en återställningspunkt före uppgraderingen, eftersom Jellyfin genomför datamigreringar när en nyare version startar och inte erbjuder någon generell väg för nedgradering på plats.
Testa båda återställningsmetoderna om båda ingår i återställningsplanen. Ett inbyggt arkiv bevisar att applikationen kan återställas; en övning med säkerhetskopiering på filnivå bevisar att miljön kan återskapa de beständiga sökvägarna och behörigheterna runt den.
Vanliga frågor
Bör jag stoppa Jellyfin innan jag använder den inbyggda säkerhetskopieringen?
Nej. Den inbyggda metoden är utformad för att fungera medan Jellyfin körs, även om låg aktivitet och ingen aktiv biblioteksskanning rekommenderas. Stoppa servern vid en vanlig manuell kopiering av aktiva Jellyfin-data.
Kan den inbyggda säkerhetskopieringen ersätta min värdsäkerhetskopiering?
Inte alltid. Den skyddar Jellyfins applikationstillstånd, men en fullständig återställning av värden kan också bero på Compose-filer, proxyinställningar, certifikat, monteringar, behörigheter, skript och annan extern konfiguration.
Rekommenderade produkter
Produktjämförelser
Mer att läsa
ZFS vs Btrfs vs ext4 för en Jellyfin-medievolym: Vilket passar bäst?
Välj ett Jellyfin-mediefilsystem utifrån återställningsmodell: ZFS för poolintegritet, Btrfs för Linux-inbyggd CoW eller ext4 för lägre driftskomplexitet.
Jellyfin med Kodi jämfört med fristående Jellyfin-klienter: Vilket passar bäst?
Välj Kodi för ett anpassningsbart TV-fokuserat arbetsflöde med mer klienttillstånd; välj fristående Jellyfin-klienter för enklare användning på flera enheter, styrd av servern.
Fler CPU-kärnor för Jellyfin: När gör de faktiskt det snabbare?
Fler kärnor påverkar Jellyfin först när en kontrollerad kandidat med färre kärnor blir CPU-begränsad och samma arbetsbelastning skalas upp på den större processorn.
