Hoe je vanaf dag één back-ups, herstel en uitbreiding voor Jellyfin ontwerpt

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Design Jellyfin Backup, Restore, and Expansion From Day One - Zima Store Online

Ontwerp Jellyfin als zes afzonderlijke rollen: opstarten, applicatiestatus, media, cache, back-up en herstel, en breid alleen de rol uit die haar limiet nadert.

Een kleine installatie kan meerdere rollen op één machine plaatsen, maar mag hun levenscycli niet vervagen. Houd veranderlijke status eenvoudig te snapshotten, plaats media achter stabiele logische paden, maak de cache wegwerpbaar en houd ten minste één herstelkopie buiten het actieve storingsdomein. Bewijs het ontwerp door het op een schoon doel te herstellen voordat je bewaarbeleid automatiseert of schijven toevoegt.

Breng de zes gegevensrollen in kaart voordat je schijven kiest

Begin met resultaten, niet met schijfposities. Opstart- en runtimebestanden moeten reproduceerbaar zijn; de database, instellingen, gebruikers, kijkgeschiedenis en samengestelde metagegevens van Jellyfin vormen de persistente status; media zijn omvangrijke gebruikersgegevens; transcoderingen en afbeeldingscaches kunnen opnieuw worden opgebouwd; back-ups zijn invoer voor herstel; en het herstelsysteem is de plek waar die invoer wordt bewezen.

Deze scheiding voorkomt twee kostbare fouten: terabytes aan wegwerpbare cache net zo vaak back-uppen als een veranderende database, of de database beschermen terwijl onvervangbare thuisvideo's geen tweede kopie hebben. De onafhankelijke handleiding voor herstel met Ubuntu en Docker maakt eveneens onderscheid tussen persistente configuratie en opnieuw op te bouwen cache.

Rol	Typische inhoud	Ontwerpregel
Opstarten/systeem	Besturingssysteem, pakketten, runtime-definitie	Documenteer het of maak er een afbeelding van; ga ervan uit dat opnieuw opbouwen mogelijk is
Applicatiestatus	Database, gebruikers, instellingen, metagegevens	Snelle lokale opslag plus samenhangende back-ups
Gebruikersmedia	Films, muziek, gezinsbestanden	Stabiele paden en afzonderlijk beschermingsbeleid
Cache	Transcoderingen, verkleinde afbeeldingen, tijdelijk werk	Plaats voor doorvoer; opnieuw opbouwen toegestaan
Back-up	Herstelkopieën met versiebeheer	Houd het buiten het actieve storingsdomein
Herstel	Schone testhost of geïsoleerde naamruimte	Gebruik het om herstel te bewijzen, niet om productiegegevens op te slaan

Stop hier als een plug-in, certificaat, ondertitel of aangepast item nog geen eigenaar heeft. Een niet-geclassificeerd persistent pad wordt pas ontdekt nadat de oorspronkelijke server verdwenen is.

Houd de status lokaal en mediapaden stabiel

Plaats de applicatiestatus op betrouwbare lokale SSD-opslag met gemonitorde vrije ruimte. Koppel media afzonderlijk aan logische paden die een wijziging van schijf, behuizing of pool kunnen doorstaan. De Jellyfin-service moet vóór en na uitbreiding hetzelfde pad zien, zelfs als de onderliggende opslaglaag verandert.

Behandel de cache als een verbruiker van doorvoer, niet als een afhankelijkheid voor herstel. De cache kan een systeem-SSD delen bij een lichte werklast of naar een speciaal toegewezen snelle schijf worden verplaatst wanneer schrijfbewerkingen, capaciteit of slijtage meetbare problemen veroorzaken. Verplaats de database en cache niet samen alleen omdat ze allebei klein zijn.

Vereis vóór elke opstart dat media- en statuskoppelingen aanwezig zijn en beschrijfbaar zijn voor de runtime-identiteit. Een ontbrekende netwerkkoppeling die stilletjes verandert in een lege lokale map, kan scans of schrijfbewerkingen naar het verkeerde pad veroorzaken. De bijbehorende handleiding voor herstel van machtigingen en identiteit behandelt de eigendomsgrens na padwijzigingen.

Bouw back-ups rond herstelobjecten

Maak van de applicatiestatus één samenhangend herstelobject voor back-up. Stop Jellyfin bij de eenvoudigste installatie tijdens het korte kopieervenster; opslagsnapshots zijn alleen aanvaardbaar als ze elk statusonderdeel op één herstelbaar moment vastleggen. Noteer de Jellyfin-versie naast elk herstelpunt, omdat een databasemigratie een onveilige terugzetting naar een oudere image kan veroorzaken.

Bescherm media volgens een ander schema. Aangekochte media kunnen mogelijk opnieuw uit de bron worden verkregen; familieopnamen misschien niet. Classificeer deze subsets voordat je replicatie, offlinekopieën of opslag op een externe locatie kiest. De handleiding voor retentie en herstelvensters is de volgende stap om te bepalen hoeveel statusgeneraties je moet bewaren.

Ten minste één bruikbare kopie moet het verlies of de beschadiging van de actieve host en de aangesloten opslag overleven. Een gespiegelde pool verbetert de beschikbaarheid na een apparaatstoring, maar een gesynchroniseerde verwijdering of databasebeschadiging kan elke spiegel bereiken; redundantie en back-up beschermen tegen verschillende storingen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Oefen een schoon herstel voordat je automatiseert

Herstel naar een geïsoleerde machine, VM of container met dezelfde Jellyfin-versie waarmee het herstelpunt is gemaakt. Reproduceer de runtime-identiteit en logische koppelingen, start zonder de nieuwe server beschikbaar te maken voor productieclients en controleer vervolgens een beheerderslogin, gebruikersgeschiedenis, bibliotheekaantallen, artwork, één Direct Play-item en één representatieve transcodering.

Het punt is niet dat het dashboard wordt geladen. Een recente TrueNAS-migratiecase laat zien hoe de applicatiestatus, chart-generaties en een nieuwe containerroute elkaar kunnen doorkruisen; een schone oefening brengt die afhankelijkheden aan het licht terwijl de oude instantie nog bestaat.

Leg de bronversie, runtime-identiteit, koppeloverzicht en back-upchecksum vast.
Herstel de status naar een schoon, geïsoleerd doel.
Controleer gebruikers, bibliotheken, metadata en representatief afspelen.
Start eenmaal opnieuw op en herhaal de kerncontroles.
Meet de procedure en werk het draaiboek bij met elke handmatige afhankelijkheid.

Laat de oefening mislukken als er een niet-gedocumenteerd geheim, een herschrijving van paden of een live productiebestand voor nodig is. Automatisering komt pas nadat deze handmatige reeks twee keer succesvol is uitgevoerd, niet eerder.

Breid capaciteit uit zonder bibliotheken een nieuwe naam te geven

Kies vroeg genoeg een uitbreidingsdrempel om gegevens zonder nooddruk te kunnen kopiëren en valideren. Een aanhoudend gebruik van ongeveer drie kwart van de bruikbare pool is een planningssignaal, geen universele regel; gebruik je opnamesnelheid, herbouwtijd, back-upduur en geschiedenis van waarschuwingen voor vrije ruimte om de daadwerkelijke trigger in te stellen.

Breid waar mogelijk uit achter het bestaande logische mediapad. Bereid het nieuwe apparaat of de nieuwe pool voor, valideer de gezondheid en het schrijfg gedrag, kopieer de eerste representatieve set in plaats van deze te verplaatsen, vergelijk aantallen of hashes en test een bibliothe scan en het afspelen voordat je de nieuwe capaciteit beschikbaar maakt voor normale schrijfbewerkingen.

Als uitbreiding ook een nieuw bestandssysteem, host, deelprotocol of koppelpad vereist, splits dit dan op in afzonderlijke wijzigingen. De topologie voor rekenkracht, opslag en back-ups helpt bepalen wanneer capaciteitsgroei het scheiden van rollen rechtvaardigt in plaats van één behuizing uit te breiden.

Valideer de volledige topologie en de limieten ervan

Voer het ontwerp als één systeem uit: start koud op na een gecontroleerde uitschakeling, start met één niet-beschikbare afhankelijkheid, vul een testvolume tot aan de waarschuwingsdrempel, herstel een statuscontrolepunt en lees media vanaf het uitgebreide pad. Leg vast wat veilig wordt afgesloten, wat minder goed functioneert en waarvoor actie van de beheerder nodig is.

Houd meerdere rollen op één host zolang hun gecombineerde belasting, bekabeling, stroomverbruik en hersteltijd binnen je doelstellingen blijven. Splits mediaopslag, back-ups of herstel alleen wanneer een gemeten capaciteits-, onderhouds- of foutdomeinlimiet wordt bereikt; extra machines brengen hun eigen netwerk- en levenscyclusafhankelijkheden met zich mee.

De slotregel is eenvoudig: behoud stabiele logische paden, bescherm niet-reconstrueerbare status onafhankelijk en bewijs herstel na elke topologiewijziging. Capaciteit die niet kan worden hersteld, is geen voltooide capaciteit.