Een checklist voor Jellyfin-containers en afhankelijkheden vóór de upgrade

Bewaar vóór het upgraden van een Jellyfin-container beide kanten van de implementatie: de persistente Jellyfin-status en de exacte containerdefinitie die weet hoe deze te bereiken. Een nieuwe image ophalen is eenvoudig; een gemigreerde database, gewijzigde mount of vergeten apparaatkoppeling herstellen niet.

Volg de checklist in de volgorde van de afhankelijkheden. Controleer eerst of je de gegevens kunt herstellen, leg daarna de huidige image en runtime-instellingen vast, lees vervolgens het updatepad en vervang pas daarna de image. Test daarna dezelfde bibliotheken, gebruikers, afspeelmodi, geplande taken en het herstartgedrag voordat je de terugvalkopie verwijdert.

Leg de laatst werkende image en containerdefinitie vast

Sla de huidige Jellyfin-imagetag op en, indien praktisch, ook de digest. Exporteer of kopieer het Compose-bestand of de appdefinitie met poorten, netwerken, mounts, omgevingswaarden, herstartbeleid, gebruikerskoppeling, aanvullende groepen, GPU-apparaten en eventuele verbinding met een reverse proxy.

In de officiële documentatie voor Jellyfin-containers wordt onderscheid gemaakt tussen veranderlijke tags zoals latest en expliciete tags voor hoofd-, sub- en patchversies. Gedrag van Jellyfin-imagetags Terugdraaien is eenvoudiger als je de exacte werkende versie weet, in plaats van alleen te weten dat “latest gisteren nog werkte”.

Verwijder de oude image niet en wis de opgeslagen definitie niet voordat de nieuwe versie de volledige validatieperiode heeft doorstaan. Als de upgrade mislukt voordat persistente gegevens zijn gewijzigd, bieden de bewaarde image en definitie de minst ingrijpende hersteloptie.

Maak een herstelbare back-up van de status van Jellyfin

Bescherm de gegevens- en configuratiemappen van Jellyfin voordat de image wordt gewijzigd. De back-up moet buiten het actieve applicatiepad staan en onafhankelijk toegankelijk zijn. Een tweede kopie of snapshot op dezelfde dataset is alleen nuttig als je weet tegen welk type storing die bescherming biedt.

In de back-updocumentatie van Jellyfin staat dat je na toegepaste migraties mogelijk gegevens moet herstellen, omdat er geen algemene manier is om te downgraden. De documentatie beschrijft ook ingebouwde back-ups en de vereiste om de applicatie netjes af te sluiten voordat je handmatig bestanden kopieert. Richtlijnen voor back-up en herstel van Jellyfin

Voor een containerworkflow wordt hetzelfde principe behandeld in de workflow van ZimaSpace voor het maken van een herstelpunt vóór updates. Ga niet verder als je de persistente paden niet kunt vaststellen of de inhoud van de back-up niet kunt controleren.

Leg koppelingen, UID/GID en hardwareafhankelijkheden vast

Noteer elke bind mount en elk benoemd volume en vermeld of die alleen-lezen of beschrijfbaar zijn. Leg de runtime-UID/GID, groepslidmaatschappen en het eigendom van de gegevensmappen van Jellyfin vast. Noteer ook GPU- of renderapparaatkoppelingen als hardwareversnelling is ingeschakeld.

In de containergids van Jellyfin wordt getoond dat media, configuratie en cache afzonderlijk worden gekoppeld en dat de container kan draaien met een opgegeven UID/GID. persistente paden en gebruikerskoppeling Dit zijn afhankelijkheden, geen versiering: een opnieuw aangemaakte container kan succesvol starten, maar een lege configuratiemap zien of geen toegang meer hebben tot een apparaat.

Vergelijk de opgeslagen definitie met de daadwerkelijk draaiende container, niet alleen met een sjabloon waarvan je denkt dat die actueel is. Als er handmatige wijzigingen in de runtime zijn die ontbreken in Compose of de NAS-appdefinitie, verhelp die afwijkingen dan voordat je upgradet, zodat je de oude implementatie kunt reproduceren.

Featured

ZimaCube 2 persoonlijke cloud-home-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer het ondersteunde upgradepad en de risico's van plug-ins

Lees de releaseopmerkingen voor elke grote grens tussen de huidige en de doelversie. Let op vereiste tussenversies, databasemigraties, gewijzigde configuratie, compatibiliteit van plug-ins, FFmpeg-vereisten of langdurige opstarttaken.

In de upgradedocumentatie van Jellyfin worden back-ups herhaaldelijk benadrukt. Er wordt uitgelegd waarom een schemawijziging een eenvoudige downgrade onmogelijk kan maken. upgrade- en downgradegrenzen In de releaseopmerkingen van grote releases kunnen versiegebonden vereisten staan. Leid dus niet af dat een veilige upgradesprong mogelijk is alleen omdat de containerimage bestaat.

Als een plug-in essentieel is, controleer dan vóór de serverupgrade of er een compatibele versie beschikbaar is. Is een plug-in optioneel en is die eerder de oorzaak geweest van problemen bij het opstarten, noteer dan de huidige versie en wees erop voorbereid om alleen die plug-in uit te schakelen als de logs van de nieuwe server deze als oorzaak aanwijzen.

Voer de upgrade uit zonder de statusgrens te wijzigen

Stop Jellyfin op de juiste manier, haal de bedoelde image op en maak alleen de Jellyfin-service opnieuw aan met dezelfde geverifieerde permanente paden en runtime-afhankelijkheden. Combineer de upgrade niet met een opslagmigratie, een herontwerp van UID/GID, een aanpassing van de reverse proxy en een nieuwe GPU-configuratie, tenzij dat precies het doel van het onderhoud is.

Houd het logboek van de eerste keer opstarten in de gaten. Een migratie kan bij een grote bibliotheek terecht lang duren, terwijl een directe melding als ‘permission denied’, een lege database, een ontbrekend pad of een incompatibel schema op een andere oorzaak wijst. Start een migratie niet herhaaldelijk opnieuw alleen omdat de gebruikersinterface niet meteen beschikbaar is.

Als de container als een nieuwe server opstart, stop deze dan voordat je iets configureert. Dit wijst er meestal op dat de nieuwe service naar de verkeerde permanente gegevens verwijst. Corrigeer eerst de koppeling van de volumes; het configureren van een nieuwe, lege instantie kan bestanden aanmaken die het herstel bemoeilijken.

Valideer de nieuwe versie voordat je rollbackbestanden verwijdert

Controleer de oorspronkelijke serveridentiteit, gebruikers, bibliotheken, metadata en belangrijke instellingen. Speel één item af met Direct Play en één representatieve transcodering af, en voer vervolgens een geplande taak uit die belangrijk is voor jouw configuratie, of houd die in de gaten. Controleer de logs op terugkerende fouten met migraties, databases, machtigingen en FFmpeg.

Start de container na de eerste geslaagde sessie één keer opnieuw. De nieuwe versie is pas volledig gevalideerd als deze dezelfde gegevens en apparaten opnieuw kan openen na een schone heraanmaak of herstart. Zo ontdek je of er per ongeluk wordt vertrouwd op een tijdelijke koppeling of runtime-status.

Bewaar de back-up van vóór de upgrade, de verwijzing naar de vorige image en de opgeslagen definitie totdat de server de gebruikelijke periode met normale belasting heeft doorstaan. Als na een databasemigratie een rollback nodig is, volg dan de gedocumenteerde herstelgrens van Jellyfin in plaats van een oudere image te koppelen aan een status die al is gemigreerd.