Hoe je appgegevens, cache en back-ups van Jellyfin scheidt
Scheid de appgegevens, cache en back-ups van Jellyfin door te bepalen wat een herbouw moet overleven, wat opnieuw kan worden gegenereerd en wat beschikbaar moet blijven nadat het apparaat met de actieve status uitvalt. Deze drie rollen kunnen een fysieke SSD in een kleine server delen, maar ze mogen niet dezelfde levenscyclus of hetzelfde herstelbeleid hebben.
Duurzame applicatiestatus omvat de database, configuratie, gebruikers- en afspeelstatus en andere bestanden die nodig zijn om dezelfde server terug te brengen. Cache- en transcodeerwerk zijn wegwerpbaar zodra geen actieve taak ze meer nodig heeft. Back-ups zijn herstelkopieën en mogen niet afhankelijk zijn van dezelfde opslaggrens waarvan ze geacht worden te herstellen.
Maak persistente appgegevens de gezaghebbende statusrol
Begin met het in kaart brengen van het hostpad of volume dat de duurzame status van Jellyfin beheert. Bij een containerdeployment kan de image worden vervangen; de gekoppelde status moet opnieuw worden verbonden nadat de container opnieuw is gemaakt. Noteer het hostpad, containerpad, eigenaarschap, bestandssysteem, minimale vrije ruimte en de back-upmethode.
Een actuele Jellyfin Docker Compose-indeling scheidt persistente configuratie- en cachedirectories voordat media wordt gekoppeld. Dat onderscheid tussen paden is operationeel nuttig, zelfs wanneer beide directories aanvankelijk op dezelfde SSD staan.
Plaats de gezaghebbende database niet op een locatie die je tijdens het oplossen van problemen zonder bezwaar zou wissen. Een geslaagde cache-opruiming mag gebruikers, bibliotheken, kijkstatus of serveridentiteit nooit kunnen resetten.
Behandel cache- en transcodeerruimte als opnieuw op te bouwen werkgegevens
Cache bestaat om herhaald werk te beperken of tijdelijke verwerkingsuitvoer op te slaan. De waarde ervan ligt in prestaties en gemak, niet in identiteit. Geef de cache voldoende capaciteit voor de grootste normale pieken van achtergrondtaken en transcodering, maar zorg dat deze opnieuw kan worden aangemaakt zonder de hele server te herstellen.
Voorkom dat cache- of transcodeeractiviteiten met veel schrijfbewerkingen het back-upbeleid voor de database bepalen. Als hetzelfde snelle apparaat beide rollen vervult, gebruik dan afzonderlijke directories of datasets met aparte quota en monitoring. Zo voorkom je dat een tijdelijke piek de vrije ruimte opslokt die nodig is voor databaseschrijfbewerkingen of een toekomstig herstel.
Wanneer bladeren, metadata en statusbewerkingen traag aanvoelen terwijl sequentiële media-uitlezingen gezond blijven, biedt de ZimaSpace-analyse over interactieve mediaserverstatus op SSD houden een nuttige volgende test, zonder de omvangrijke mediabibliotheek als dezelfde opslagbelasting te behandelen.
De container is wegwerpbaar; de status en het recept voor herbouw niet
Een container kan opnieuw worden opgehaald; je mag er niet van uitgaan dat de deploymentdefinitie en persistente gegevens vanzelf terugkomen. Bewaar de Compose- of servicedefinitie, de imageversie of het tagbeleid, de koppelingskaart, de service-identiteit, verwijzingen naar vereiste geheimen en de persistente Jellyfin-status.
De praktische regel in deze back-upworkflow voor Docker-volumes is dat bruikbare herstelgegevens zich in volumes, bind mounts, appgegevens en servicedefinities bevinden, en niet in de wegwerpcontainer zelf.
Bij live databases is consistentie belangrijker dan het kopiëren van elke byte terwijl de service bezig is. Gebruik het door de applicatie ondersteunde back-uppad of een gecontroleerde stop-/snapshotmethode die geschikt is voor de deployment, in plaats van een willekeurige kopie van live bestanden als bewezen herstelpunt te behandelen.
Een back-up naast de actieve status dekt hostuitval niet
Een back-up naast de live database kan helpen bij onbedoelde wijzigingen, maar overleeft niet elke pool-, host-, ransomware-, diefstal- of stroomgebeurtenis die de productie kan verwijderen. Bewaar een herstelkopie op een ander apparaat of binnen een andere beheergrens en bescherm alle sleutels of referenties die nodig zijn om deze te lezen.
Een back-upplan voor self-hosting moet status, geheimen, herstelkopieën en herstelinstructies gezamenlijk in kaart brengen. Deze herstelcontrole voor self-hosting legt de nadruk op kopieën buiten de voor de hand liggende impactzone en op vastgelegde inputs voor herbouw, in plaats van snapshots als een compleet plan te beschouwen.
Laat de back-upbestemming niet worden opgeschoond door dezelfde cachebewaarregel of hetzelfde opruimcommando als de live app-pool. De back-up is een aparte rol, ook als deze tijdelijk op dezelfde behuizing wordt opgeslagen.
Breng de opslagrollen in kaart voordat je schijven koopt of verplaatst
| Rol | Voorbeelden | Kan opnieuw worden opgebouwd? | Primair beleid |
|---|---|---|---|
| Duurzame appstatus | Database, configuratie, gebruikers, kijkstatus, plug-ins/instellingen | Niet goedkoop | Lage latentie, vrije ruimte, consistente back-up |
| Cache / tijdelijk | Cache, tijdelijke transcodeerruimte, wegwerpbare tussenbestanden | Ja | Capaciteit, prestaties, begrensde opruiming |
| Back-up | Versiebeheerde statuskopie, deploymentrecept, herstelmetadata | Nee; dit is de herstelbron | Onafhankelijk storingsdomein, bewaarbeleid, hersteltest |
| Media | Films, series, familievideo's | Afhankelijk van de bron | Capaciteit en afzonderlijk beschermingsbeleid |
Deze kaart voorkomt een veelgemaakte fout bij herontwerp: alles naar de snelste schijf verplaatsen terwijl alleen de latentie van appstatus een probleem was, of elk tijdelijk bestand back-uppen terwijl de servicedefinitie die nodig is om de container opnieuw op te bouwen ontbreekt.
Bewijs de scheiding met een hersteltest die je kunt weggooien
Herstel de Jellyfin-status naar een nieuw pad of een geïsoleerde host, laat een gekopieerde deploymentdefinitie naar die locatie wijzen, geef niet-destructieve toegang tot representatieve media en start de service zonder de oorspronkelijke cache. De server moet terugkeren met de verwachte identiteit, bibliotheken, gebruikers en instellingen, ook al begint de cache leeg.
Het onderscheid wordt pas meetbaar wanneer een back-up wordt hersteld naar een geïsoleerd doel en gecontroleerd zonder de productiestatus te lenen. De testinstantie van Jellyfin moet starten vanuit de herstelkopie, de vereiste paden opnieuw verbinden en aantonen dat het live volume het herstel niet stiekem voltooit.
De indeling slaagt wanneer de cache kan worden verwijderd zonder identiteitsverlies, de runtime opnieuw kan worden gemaakt zonder de bibliotheek uit het geheugen opnieuw op te bouwen en ten minste één back-up de service kan herstellen nadat ervan is uitgegaan dat het apparaat met de actieve appgegevens niet beschikbaar is.
Aanbevolen producten
NAS- en serverconfiguratie
Meer om te lezen
Hoe AI-achtige analyse en automatisering de opslag- en rekenbehoeften van Jellyfin veranderen
Automatisering en aanverwante AI-analyses voegen scans, afgeleide gegevens, CPU/GPU-bewerkingen, cache, tijdelijke opslag en planning van achtergrondtaken toe bovenop normaal afspelen in Jellyfin.
Hoe je Jellyfin integreert in een netwerk van een klein appartement of een huurwoning
Bouw een huurvriendelijk Jellyfin-netwerk met stabiele lokale adressering, minimale bekabeling, stille hardware, externe toegang die rekening houdt met CGNAT en omkeerbare wijzigingen.
Hoeveel gebruikers en achtergrondtaken moet één Jellyfin-host ondersteunen?
Behandel Jellyfin-gebruikers en achtergrondtaken als één gedeeld workloadbudget; de capaciteit is bereikt zodra afspeelvertraging, wachtrijen of resourcebelasting herhaaldelijk problematisch worden.
