Så reparerar du Jellyfin när dess databasvolym blir full
När Jellyfins databasvolym blir full ska du stoppa nya skrivningar, bevara databas- och WAL-filerna, frigöra utrymme på ett säkert sätt och validera databasen innan du startar vanliga jobb igen.
Misslyckas Jellyfin med att starta, rapporterar SQLite-fel eller öppnas utan användare efter att volymen nått noll ledigt utrymme? Ta inte omedelbart bort databasfiler eller kör rensningsjobb. Notera först volymen, antalet lediga byte, databasfilnamnen, containerns tillstånd och den senaste fungerande säkerhetskopian.
Förhindra att felet utvecklas till en skrivstorm
Stoppa Jellyfin och alla importörer, skannrar eller sidoprocesser som skriver till samma volym. Bekräfta vilken monteringspunkt som är full, inklusive inoder, och bevara huvuddatabasen samt eventuella tillhörande `-wal`- eller `-shm`-filer. En full disk kan lämna konfigurationsfiler tomma eller delvis skrivna; ett versionsspecifikt incidentfall visar att det kanske inte räcker att bara frigöra utrymme för att återställa starten (fall av återställning efter full volym).
Frigör utrymme från temporära loggar, slutförda transkodningsfiler eller cache som du vet kan byggas om, men först efter att du har kopierat det beständiga tillståndet. Ta aldrig bort databasen som första åtgärd.
Notera databasens storlek, WAL-filer, loggar, cache och återstående lediga utrymme före rensningen. Det visar om volymen fylldes av databasens tillväxt, transkodningsutdata, loggar eller en annan container.
Kontrollera databasens integritet innan du försöker reparera den
Arbeta med en kopia av databasen medan Jellyfin förblir stoppat. Kör en integritetskontroll med de SQLite-verktyg som finns tillgängliga i din miljö och granska loggarna efter fel som ”disk full”, felaktig bild eller att filen inte kan öppnas. Om kontrollen godkänns återställer du ledigt utrymme, startar om en gång och verifierar användare, bibliotek och uppspelning.
Om databasen är felaktigt formaterad återställer du först den senaste fungerande säkerhetskopian. Ett kontrollerat återställningsförfarande kan använda SQLite-verktyg för återställning på en kopia, men det ersätter inte en validerad säkerhetskopia och får inte utföras mot en aktiv databas (kopiabaserad återställningsprocedur).
När du endast har frigjort data som kan byggas om kontrollerar du att databasfilerna fortfarande finns tillsammans och går att läsa. En omstart innan denna kontroll kan omvandla en ofullständig skrivning till ett andra fel.
Förhindra att volymen når samma gräns igen
Flytta cache och transkodningsutdata till en övervakad sökväg, ställ in aviseringar ovanför miniminivån för ledigt utrymme och se över loggarnas lagringstid och skanningsscheman. Håll applikationens tillstånd åtskilt från stora mediefiler så att ett växande bibliotek inte kan förbruka databasvolymen.
Starta om två gånger, kör den ursprungliga skanningen eller uppspelningen och bekräfta att nästa säkerhetskopiering slutförs. Eskalera när integritetskontroller misslyckas, databasen inte kan återställas eller volymen fylls igen utan en synlig skrivande process.
Om integritetskontrollen godkänns startar du om en gång och kör den ursprungliga användar- och biblioteksbelastningen. Om den misslyckas arbetar du från en kopia eller återställer databasen i stället för att upprepade gånger öppna den skadade databasen.
Bevisa återställningen och förhindra en ny full volym
Gör en kall omstart, kör en skanning, en uppspelningssession och en säkerhetskopiering efter reparationen. Bekräfta att databasvolymen har en övervakad marginal av ledigt utrymme medan belastningen är aktiv.
Behåll reparationen när användare, bibliotek, schemalagda uppgifter och uppspelning fungerar igen. Lägg till aviseringar för utrymme och inoder, och flytta cache eller loggar till en roll som inte kan förbruka databasvolymen.
Eskalera när volymen fylls igen utan en synlig skrivande process, integritetskontroller misslyckas eller den återställda databasen saknar användare eller tillstånd.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Jellyfin-databasanslutningar för samtidiga containrar
Börja med en enda databasägare och mät SQLite:s låsbeteende; lägg till en annan backend först när samtidighet och återställning motiverar komplexiteten.
Så förhindrar du dubbla jobb eller importer i Jellyfin
Dubblet arbete beror vanligtvis på överlappande schemaläggare eller mer än en skrivande komponent; utse en ansvarig, en väg och en kontroll av att arbetet...
Varför återskapar Jellyfin saknade filer med fel ägare?
Felaktigt ägarskap beror vanligtvis på en identitetskonflikt eller en annan importsökväg; verifiera den aktiva containeranvändaren innan du ändrar behörigheter.
