Checklist pre-aggiornamento per i container e le dipendenze di Jellyfin

Prima di aggiornare un container Jellyfin, proteggi entrambi gli aspetti della distribuzione: lo stato persistente di Jellyfin e la definizione esatta del container che sa come raggiungerlo. Scaricare una nuova immagine è semplice; recuperare un database migrato, un mount modificato o una mappatura di dispositivo dimenticata non lo è.

Usa la checklist nell'ordine delle dipendenze. Prima assicurati di poter recuperare i dati, poi registra l'immagine corrente e le impostazioni di runtime, quindi leggi il percorso di rilascio e solo dopo sostituisci l'immagine. In seguito, testa le stesse librerie, gli utenti, le modalità di riproduzione, le attività pianificate e il comportamento al riavvio prima di eliminare la copia di rollback.

Registra l'ultima immagine funzionante e la definizione del container

Salva il tag dell'immagine Jellyfin corrente e, quando possibile, anche il relativo digest. Esporta o copia il file Compose o la definizione dell'app che contiene porte, reti, mount, valori dell'ambiente, policy di riavvio, mappatura degli utenti, gruppi supplementari, dispositivi GPU ed eventuali relazioni con un reverse proxy.

La documentazione ufficiale del container Jellyfin distingue i tag mobili come latest dai tag espliciti di versione principale, secondaria e patch. Comportamento dei tag delle immagini Jellyfin Un rollback è più semplice quando conosci l'esatta versione funzionante, invece di ricordare soltanto che «ieri latest funzionava».

Non fare il prune della vecchia immagine e non eliminare la definizione salvata finché la nuova versione non supera l'intero periodo di convalida. Se l'aggiornamento non riesce prima di modificare i dati persistenti, l'immagine e la definizione conservate offrono il percorso di ripristino meno invasivo.

Crea un backup ripristinabile dello stato di Jellyfin

Proteggi le directory dei dati e della configurazione di Jellyfin prima di modificare l'immagine. Il backup deve trovarsi al di fuori del percorso dell'applicazione attiva e deve poter essere letto in modo indipendente; una seconda copia o uno snapshot sullo stesso dataset è utile solo se sai da quale guasto ti protegge.

La documentazione di Jellyfin sul backup avverte che gli aggiornamenti possono richiedere il ripristino dei dati, perché dopo l'applicazione delle migrazioni non esiste un meccanismo generale di downgrade. Documenta inoltre i backup integrati e il requisito di arresto completo per le copie manuali dei file. Indicazioni di Jellyfin su backup e ripristino

In un flusso di lavoro con container, lo stesso principio è illustrato dal flusso di lavoro di ZimaSpace per creare un punto di rollback prima dell'aggiornamento. Fermati qui se non riesci a identificare i percorsi persistenti o a verificare il contenuto del backup.

Acquisisci mount, UID/GID e dipendenze hardware

Elenca ogni bind mount e volume denominato e annota se è di sola lettura o scrivibile. Registra UID/GID di runtime, appartenenze ai gruppi e proprietario delle directory dei dati di Jellyfin. Acquisisci anche le mappature della GPU o dei dispositivi di rendering se l'accelerazione hardware è abilitata.

La guida di Jellyfin per i container mostra che media, configurazione e cache sono montati separatamente e che il container può essere eseguito con un UID/GID specificato. percorsi persistenti e mappatura degli utenti Questi valori sono dipendenze, non dettagli estetici: un container ricreato può avviarsi correttamente pur vedendo una directory di configurazione vuota o perdendo i permessi per accedere a un dispositivo.

Confronta la definizione salvata con il container effettivamente in esecuzione, non solo con un modello che pensi sia aggiornato. Se il runtime contiene modifiche manuali assenti in Compose o nella definizione dell'app sul NAS, correggi questa divergenza prima dell'aggiornamento, così da rendere riproducibile la vecchia distribuzione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controlla il percorso di aggiornamento supportato e i rischi dei plugin

Leggi le note di rilascio per ogni passaggio tra versioni principali compreso tra la versione corrente e quella di destinazione. Cerca versioni intermedie obbligatorie, migrazioni del database, modifiche alla configurazione, compatibilità dei plugin, requisiti di FFmpeg o operazioni di avvio prolungate.

La documentazione di Jellyfin sugli aggiornamenti sottolinea ripetutamente l'importanza dei backup e spiega perché le modifiche allo schema possono rendere impossibile un semplice downgrade. limiti degli aggiornamenti e dei downgrade Le note delle versioni principali possono aggiungere prerequisiti specifici della versione, quindi non dedurre che il salto sia sicuro solo perché l'immagine del container esiste.

Se un plugin è essenziale, verifica che sia disponibile una versione compatibile prima di aggiornare il server. Se un plugin è opzionale e in passato ha impedito l'avvio, annota la versione corrente e preparati a disabilitare solo quel plugin se i log del nuovo server lo identificano come origine del problema.

Esegui l'aggiornamento senza modificare il confine dello stato

Arresta Jellyfin correttamente, scarica l'immagine desiderata e ricrea solo il servizio Jellyfin con gli stessi percorsi persistenti e le stesse dipendenze di runtime già verificate. Non combinare l'aggiornamento con una migrazione dello storage, una riprogettazione di UID/GID, una riscrittura del reverse proxy e una riconfigurazione della GPU, a meno che tali modifiche non siano lo scopo effettivo della manutenzione.

Osserva il log del primo avvio. Una migrazione può richiedere legittimamente del tempo con una libreria di grandi dimensioni, mentre messaggi immediati come «permission denied», database vuoto, percorso mancante o schema incompatibile indicano un ramo diverso. Non riavviare ripetutamente una migrazione solo perché l'interfaccia non è subito disponibile.

Se il container si apre come un server nuovo, fermalo prima di configurare qualsiasi cosa. Questo sintomo di solito significa che il nuovo servizio punta allo stato persistente sbagliato. Correggi prima la mappatura dei mount; configurare una nuova istanza vuota può creare file nuovi che rendono più difficile il ripristino.

Convalida la nuova versione prima di rimuovere gli elementi di rollback

Verifica l'identità del server originale, gli utenti, le librerie, i metadati e le impostazioni importanti. Riproduci un contenuto in Direct Play e una transcodifica rappresentativa, quindi esegui o osserva un'attività pianificata importante per la tua configurazione. Controlla nei log la presenza di errori ricorrenti relativi a migrazione, database, permessi e FFmpeg.

Riavvia il container una volta dopo la prima sessione completata correttamente. La nuova versione non è completamente convalidata finché non riesce a riaprire gli stessi dati e dispositivi dopo una ricreazione o un riavvio pulito. Questo rileva eventuali dipendenze accidentali da un mount temporaneo o dallo stato del runtime.

Conserva il backup precedente all'aggiornamento, il riferimento alla vecchia immagine e la definizione salvata finché il server non avrà superato il normale periodo di utilizzo. Se è necessario eseguire il rollback dopo una migrazione del database, segui il limite di ripristino documentato da Jellyfin invece di puntare un'immagine più vecchia a uno stato già migrato.