Stoppa Jellyfin för en enkel fullständig säkerhetskopiering, såvida inte din ögonblicksbildsmetod kan fånga applikationstillståndet konsekvent medan tjänsten skriver.
Avvägningen står mellan driftstopp och konsekvens. Ett arkiv från en stoppad tjänst är enkelt att förstå, eftersom databas, konfiguration och metadata slutar ändras under kopieringen. En säkerhetskopiering medan tjänsten körs kan vara giltig när databasens säkerhetskopieringsmekanism eller filsystemets ögonblicksbild skapar en sammanhängande tidpunkt, men en vanlig rekursiv kopiering under aktiva skrivningar är svårare att lita på.
Kopior från en stoppad tjänst är den enkla, säkra utgångspunkten
Om du stoppar Jellyfin tillfälligt förhindras nya databas- och metadatastr skrivningar medan säkerhetskopieringsverktyget går igenom konfigurationsträdet. Det tar bort många frågor om konsekvens för små hemmaservrar.
En filkopiering medan tjänsten körs kan missa WAL-baserade transaktioner; transaktionsmedvetna SQLite-säkerhetskopior undviker att kopiera en öppen databas som om den vore en vanlig statisk fil.
Planera pausen under en lugn period, bekräfta att processen har stoppats, kopiera det beständiga tillståndet och starta sedan tjänsten igen. Mät avbrottet så att du känner till den verkliga driftskostnaden.
Säkerhetskopiering medan tjänsten körs kräver en konsekvent ögonblicksbildsmekanism
En filsystemsögonblicksbild kan frysa vyn av många filer vid samma tidpunkt, även medan den aktiva tjänsten fortsätter efteråt. Det skiljer sig från att långsamt kopiera filer som ändras, en i taget.
Aktiva datamängder ändras under säkerhetskopieringen, så förändringstakten spelar roll när en avbildning sträcker sig över tid.
Om du använder ZFS, Btrfs eller en databasmedveten säkerhetskopiering bör du dokumentera vilken konsekvensgaranti den ger. Kalla inte en vanlig filkopiering medan tjänsten körs likvärdig utan att testa den.
Databasens integritet är viktigare än att säkerhetskopieringen slutförs
Ett säkerhetskopieringsjobb kan returnera lyckat resultat trots att den fångade databasen inte utgör en användbar återställningspunkt. Verifieringen måste granska databasen och applikationstillståndet tillsammans.
Ett tillförlitligt återställningsunderlag bör undvika okontrollerade databas kopior under aktiva skrivningar; SQLite-konsekvens beror på att ett sammanhängande databastillstånd bevaras.
Återställ säkerhetskopian till en tillfällig sökväg och kör en integritetskontroll innan du förlitar dig på den. Den beständiga layouten för appdata gör testet enklare, eftersom tillståndet är separerat från den utbytbara containern.
Välj metod utifrån ditt återställningsmål
Ett hushåll som kan acceptera ett två minuter långt underhållsfönster har kanske liten nytta av komplexa lösningar för säkerhetskopiering medan tjänsten körs. En server med strikta krav på drifttid kan motivera ögonblicksbilder, men bara om återställningar förblir förutsägbara.
Ett ordentligt katastrofåterställningstest mäter om den valda säkerhetskopian faktiskt återställer tjänsten till ett användbart tillstånd.
Jämför driftstopp för säkerhetskopiering, återställningstid och felkomplexitet. Använd den enklaste metoden som uppfyller hushållets återställningsmål och klarar en riktig återställningsövning.
Support och tips
Mer att läsa

NAS-delning visar gamla filer efter lagringsbyte: kontroller och lösningar
Jämför den lokala lagringen med den aktiva delningen och en ren klient. Reparera endast det lager som bevisligen är inaktuellt och verifiera sedan att...

Underhållsguide för kylning av mini-PC: fläktar, ventilationsöppningar och termiska baslinjer
Använd upprepningsbara mätningar vid tomgång och belastning. Rengör det externa luftflödet först, bekräfta fläktens funktion och öppna endast chassit när problemet kvarstår efter ett...

Checklista för uppdatering av fast programvara för hemmaserver för BIOS, startordning och enheter
Dokumentera först versioner, UEFI-poster samt status för lagring och passthrough. Uppdatera ett lager i taget och behåll åtkomst till konsol och återställning tills valideringen...

