Zo voorkomt u dat uw Jellyfin-configuratie tijdens upgrades verloren gaat

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 Prevent Jellyfin Configuration Loss During Upgrades - Zima Store Online

Voorkom verlies van Jellyfin-configuratie tijdens upgrades door de applicatiestatus en de vervangbare runtime als twee afzonderlijke herstelobjecten te behandelen.

Een upgrade kan op pakketniveau slagen, terwijl een gewijzigde koppeling, gebruikers-ID, apparaatkoppeling of migratie ervoor zorgt dat Jellyfin eruitziet als een nieuwe installatie. De preventieve stap is niet simpelweg “maak een back-up”, maar precies weten waar de status zich bevindt, deze consistent vastleggen, de actieve definitie registreren en bewijzen dat je kunt herstellen.

Breng de werkelijke permanente paden vóór de upgrade in kaart

Ga er niet van uit dat het pad in een container hetzelfde is als het hostpad waarvan een back-up wordt gemaakt. Controleer de bind mount of het benoemde volume dat daadwerkelijk de database-, configuratie-, metadata- en plug-instatus bevat.

Containeropslag blijft draagbaar wanneer volumedefinities en servicegrenzen expliciet zijn vastgelegd in de implementatieconfiguratie.

Noteer voor elke permanente koppeling het hostpad, containerpad, eigenaarschap en bestandssysteem. Als je de locatie van de status niet met zekerheid kunt identificeren, stel de upgrade dan uit.

Maak een consistente kopie vóór de wijziging

Het nuttigste herstelpunt is een kopie die is gemaakt voordat de nieuwe versie de database kan wijzigen. Een bestandskopie tijdens actieve schrijfbewerkingen kan minder betrouwbaar zijn dan een back-up van een gestopte service of een consistente momentopname.

Een afzonderlijke back-up van de Jellyfin-configuratie bewaart de status die moeilijk opnieuw te creëren is, terwijl bulkmedia via een eigen beschermingspad behouden blijft.

Maak de back-up, bewaar deze buiten het actieve configuratieapparaat en noteer de tijdstempel en versie. Een permanente indeling van applicatiegegevens moet het mogelijk maken om de status te back-uppen zonder de image zelf te kopiëren.

Leg de runtime-definitie net zo zorgvuldig vast als de gegevens

Een perfecte databaseback-up herstelt hardwareversnelling, poorten, DNS, apparaten of machtigingen niet als de opnieuw aangemaakte containerdefinitie deze instellingen mist. Beschouw de Compose- of platformconfiguratie als onderdeel van de herstelset.

Het uitvoeren van containers met een stabiele service-identiteit is afhankelijk van voorspelbare UID- en GID-koppelingen tijdens upgrades en op hostbestandssystemen.

Exporteer of commit de effectieve implementatiedefinitie zonder geheimen. Noteer de image-digest en apparaatkoppelingen, zodat terugrollen niet afhankelijk is van je geheugen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Test het herstelproces voordat je de oude versie verwijdert

Voer opruimwerkzaamheden pas uit nadat de nieuwe versie een herstart heeft doorstaan en de back-up kan worden gevonden en geopend. Als terugrollen nooit is geoefend, verwijder je met oude images en momentopnamen je goedkoopste herstelopties.

Een getest herstelproces verandert een back-up van een veronderstelde hersteloptie in een optie waarvan daadwerkelijk is bewezen dat deze bruikbare applicatiestatus kan herstellen.

Controleer gebruikers, bibliotheken, metadata, één afspeelsessie en één herstart. Bewaar de herstelset van vóór de upgrade totdat de nieuwe versie de verwachte migraties en normale achtergrondtaken heeft voltooid.