Jellyfin-appgegevens, cache en back-ups scheiden
Scheid Jellyfin-appgegevens, cache en back-ups door te bepalen wat een heropbouw moet overleven, wat opnieuw kan worden gegenereerd en wat beschikbaar moet blijven nadat het apparaat met de actieve status defect raakt. In een kleine server kunnen deze drie functies dezelfde fysieke SSD delen, maar ze mogen niet dezelfde levenscyclus of hetzelfde herstelbeleid hebben.
Permanente appstatus omvat de database, configuratie, gebruikers- en afspeelstatus en andere bestanden die nodig zijn om dezelfde server terug te krijgen. Cache- en transcodeerbestanden 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 het systeem moeten helpen herstellen.
Maak permanente appgegevens tot de gezaghebbende status
Begin met het vaststellen van het hostpad of volume waarin de permanente status van Jellyfin staat. Bij een containerimplementatie kan de image worden vervangen; de gekoppelde status moet behouden blijven wanneer de container opnieuw wordt aangemaakt. Noteer het hostpad, het containerpad, de eigendomsrechten, het bestandssysteem, de minimale vrije ruimte en de back-upmethode.
Een actuele Jellyfin Docker Compose-indeling scheidt permanente configuratie- en cachemappen voordat media wordt gekoppeld. Dat onderscheid tussen paden is operationeel nuttig, ook als beide mappen aanvankelijk op dezelfde SSD staan.
Sla de gezaghebbende database niet op een locatie op die je bij het oplossen van problemen wilt kunnen wissen. Een geslaagde cache-opruiming mag nooit gebruikers, bibliotheken, kijkstatus of de serveridentiteit kunnen resetten.
Behandel cache- en transcodeerruimte als opnieuw op te bouwen werkgegevens
Een cache is bedoeld om herhaald werk te beperken of tijdelijke verwerkingsresultaten op te slaan. De waarde ervan zit in prestaties en gebruiksgemak, niet in het bewaren van gegevens. Zorg voor genoeg capaciteit voor de grootste normale pieken op de achtergrond en bij het transcoderen, maar houd er rekening mee dat de cache opnieuw kan worden aangemaakt zonder de hele server te herstellen.
Laat activiteiten met veel cache- of transcodewisselingen niet bepalend zijn voor het back-upbeleid van de database. Als hetzelfde snelle apparaat beide functies vervult, gebruik dan aparte mappen of datasets met afzonderlijke quota's en monitoring. Zo voorkom je dat een tijdelijke piek de vrije ruimte opslokt die nodig is voor databasebewerkingen of een toekomstige herstelactie.
Wanneer bladeren, metagegevens en statusbewerkingen traag aanvoelen terwijl sequentiële media-uitlezingen goed blijven werken, biedt de ZimaSpace-analyse van interactieve mediaserverstatus op een SSD bewaren een nuttige volgende test, zonder de grote mediabibliotheek als dezelfde opslagbelasting te behandelen.
De container is vervangbaar; de status en instructies voor opnieuw opbouwen niet
Een container kan opnieuw worden opgehaald; je kunt er niet van uitgaan dat de implementatie-instructies en persistente gegevens weer beschikbaar komen. Bewaar de Compose- of servicedefinitie, de imageversie of het tagbeleid, de mounttoewijzing, 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 in volumes, bind mounts, appgegevens en servicedefinities staan, en niet in de container zelf, die kan worden verwijderd.
Bij actieve databases is consistentie belangrijker dan elke byte kopiëren terwijl de service druk bezig is. Gebruik het ondersteunde back-upproces van de applicatie of een gecontroleerde stop-/snapshotmethode die geschikt is voor de implementatie, in plaats van een willekeurige kopie van een actief bestand te beschouwen als een bewezen herstelpunt.
Een back-up naast de actieve status dekt geen hoststoringen
Een back-up naast de actieve database kan helpen bij onbedoelde wijzigingen, maar overleeft niet elke storing van een opslagpool of host, ransomware-aanval, diefstal of stroomuitval waardoor de productieomgeving kan wegvallen. Bewaar een herstelkopie op een ander apparaat of binnen een andere beheergrens en bescherm alle sleutels of inloggegevens die nodig zijn om deze te lezen.
Een back-upplan voor zelfhosting moet status, geheimen, herstelkopieën en herstelinstructies samen in kaart brengen. Deze herstelcontrole voor zelfhosting benadrukt kopieën buiten de voor de hand liggende impactzone en schriftelijke informatie voor het opnieuw opbouwen, in plaats van momentopnamen als een compleet plan te beschouwen.
Zorg ervoor dat de back-upbestemming niet wordt opgeslokt door dezelfde regel voor cachebehoud of dezelfde opruimopdracht als de live app-opslagpool. De back-up heeft een aparte functie, ook als die tijdelijk in hetzelfde chassis wordt opgeslagen.
Breng de opslagrollen in kaart voordat je schijven koopt of verplaatst
| Rol | Voorbeelden | Opnieuw op te bouwen? | Primair beleid |
|---|---|---|---|
| Duurzame app-status | Database, configuratie, gebruikers, kijkstatus, plug-ins/instellingen | Niet eenvoudig | Lage latentie, vrije ruimte, consistente back-up |
| Cache / tijdelijk | Cache, tijdelijke ruimte voor transcodering, wegwerpbestanden | Ja | Capaciteit, prestaties, begrensde opruiming |
| Back-up | Versiebeheerde kopie van de status, implementatierecept, herstelmetadata | Nee; dit is de herstelbron | Onafhankelijk foutdomein, bewaartermijn, hersteltest |
| Media | Films, series, familievideo's | Afhankelijk van de bron | Capaciteit en afzonderlijk beschermingsbeleid |
Deze kaart voorkomt een veelgemaakte ontwerpfout: alles naar de snelste schijf verplaatsen terwijl alleen de latentie van de app-status een probleem was, of een back-up maken van elk tijdelijk bestand terwijl de serviceconfiguratie die nodig is om de container opnieuw op te bouwen ontbreekt.
Bewijs de scheiding met een herstel naar een wegwerpomgeving
Herstel de status van Jellyfin naar een nieuw pad of een geïsoleerde host, laat een gekopieerde implementatiedefinitie naar die locatie verwijzen, geef niet-destructieve toegang tot representatieve media en start de service zonder de oorspronkelijke cache. De server moet terugkomen met de verwachte identiteit, bibliotheken, gebruikers en instellingen, ook al is de cache aanvankelijk leeg.
Het verschil wordt pas meetbaar wanneer een back-up wordt hersteld naar een geïsoleerde omgeving en geverifieerd zonder gebruik te maken van de productiestatus. De testinstantie van Jellyfin moet starten vanuit de herstelkopie, opnieuw verbinding maken met de vereiste paden en aantonen dat het live volume het herstel niet stiekem aanvult.
De indeling voldoet wanneer de cache kan worden verwijderd zonder de identiteit te verliezen, de runtime opnieuw kan worden aangemaakt 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 live apparaat met appgegevens niet beschikbaar is.
Aanbevolen producten
NAS- en serverconfiguratie
Meer om te lezen
Kan een server in een studentenkamer stil genoeg werken om te slapen, studeren en videogesprekken te voeren?
Ja, een server in een studentenkamer kan onopvallend blijven als de hardware energiezuinig is, trillingen van de opslag worden beperkt, zware taken worden ingepland...
Een studentenhomelab dat meeverhuist van de studentenkamer naar het eerste appartement
Houd een studentenhomelab draagbaar door services los te koppelen van de netwerkinfrastructuur in specifieke kamers, de hardware tot een minimum te beperken, een back-up...
Eén homeserver delen met huisgenoten zonder accounts of privébestanden te delen
Geef elke huisgenoot een eigen account, privéopslag en alleen de gedeelde rollen die nodig zijn; houd beheer, back-ups en het intrekken van toegang gescheiden.
