Una checklist pre-aggiornamento per i container Jellyfin e le dipendenze

Prima di aggiornare un container Jellyfin, conserva entrambi gli elementi del deployment: lo stato persistente di Jellyfin e la definizione esatta del container, che specifica come raggiungerlo. Scaricare una nuova immagine è facile; recuperare un database migrato, un mount modificato o una mappatura di dispositivo dimenticata non lo è.

Segui la checklist rispettando l’ordine delle dipendenze. Prima verifica di poter recuperare i dati, poi registra l’immagine attuale e le impostazioni di esecuzione, quindi leggi il percorso di rilascio e solo dopo sostituisci l’immagine. In seguito, testa le stesse librerie, gli stessi 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 attualmente in uso e, se possibile, anche il relativo digest. Esporta o copia il file Compose o la definizione dell’app che contiene porte, reti, mount, valori dell’ambiente, criteri di riavvio, mappatura dell’utente, gruppi supplementari, dispositivi GPU e ogni relazione con un reverse proxy.

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

Non eliminare la vecchia immagine né cancellare 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, conservare l’immagine e la definizione offre 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 in uso ed essere leggibile in modo indipendente; una seconda copia o uno snapshot sullo stesso dataset è utile solo se sai da quali tipi di guasto ti protegge.

La documentazione di Jellyfin su backup e ripristino avverte che gli aggiornamenti possono richiedere il ripristino dei dati, poiché dopo l’applicazione delle migrazioni non esiste un metodo generale per effettuare il downgrade. Documenta inoltre i backup integrati e il requisito di arrestare correttamente il servizio prima di copiare manualmente i file. Indicazioni di Jellyfin su backup e ripristino

Per un flusso di lavoro basato su container, lo stesso principio è illustrato nella procedura di ZimaSpace per creare un punto di ripristino prima dell’aggiornamento. Fermati qui se non riesci a identificare i percorsi persistenti o a verificare i contenuti del backup.

Acquisisci mount, UID/GID e dipendenze hardware

Elenca ogni mount di bind e volume nominato, specificando se è in sola lettura o scrivibile. Registra l’UID/GID di runtime, i gruppi di appartenenza e la proprietà delle directory dei dati gestite da Jellyfin. Inoltre, acquisisci le mappature della GPU o dei dispositivi di rendering, se è abilitata l’accelerazione hardware.

La guida di Jellyfin sui container mostra che i percorsi per i media, la configurazione e la cache vengono 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 decorazioni: un container ricreato può avviarsi correttamente ma trovare vuota la directory di configurazione o perdere l’accesso a un dispositivo.

Confronta la definizione salvata con il container effettivamente in esecuzione, non con un modello che presumi sia aggiornato. Se il runtime presenta modifiche manuali non riportate in Compose o nella definizione dell’app NAS, correggi queste discrepanze prima dell’aggiornamento, così da poter riprodurre la distribuzione precedente.

Featured

Cloud personale NAS domestico ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica il percorso di aggiornamento supportato e i rischi per i plugin

Leggi le note di rilascio per ogni passaggio tra versioni principali, da quella attuale a quella di destinazione. Verifica la presenza di versioni intermedie obbligatorie, migrazioni del database, modifiche alla configurazione, compatibilità dei plugin, requisiti di FFmpeg o operazioni di avvio di lunga durata.

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

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

Esegui l’aggiornamento senza modificare il confine dello stato

Arresta Jellyfin correttamente, scarica l’immagine prevista e ricrea solo il servizio Jellyfin mantenendo gli stessi percorsi persistenti verificati e le dipendenze di runtime. Non abbinare l’aggiornamento a 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.

Controlla il log del primo avvio. Una migrazione può richiedere legittimamente tempo con una libreria di grandi dimensioni, mentre un messaggio immediato come “permission denied”, “empty database”, “missing path” o “incompatible schema” indica un problema diverso. Non riavviare ripetutamente una migrazione solo perché l’interfaccia non è subito disponibile.

Se il container si avvia come un server nuovo, fermalo prima di configurare qualsiasi cosa. Questo sintomo di solito indica che il nuovo servizio punta a uno stato persistente errato. Correggi prima la mappatura dei mount: configurare una nuova istanza vuota può creare file che rendono meno chiaro il percorso di ripristino.

Convalida la nuova versione prima di rimuovere gli elementi necessari al rollback

Verifica l’identità del server originale, gli utenti, le librerie, i metadati e le impostazioni importanti. Riproduci un contenuto in Direct Play e un transcodificato rappresentativo, poi esegui o verifica un’attività pianificata importante per la tua configurazione. Controlla i log per individuare errori ricorrenti relativi a migrazione, database, autorizzazioni e FFmpeg.

Riavvia il container una volta dopo la prima sessione completata con successo. La nuova versione non è del tutto convalidata finché non riesce a riaprire gli stessi dati e dispositivi dopo una ricreazione o un riavvio puliti. In questo modo si individuano eventuali dipendenze accidentali da un mount temporaneo o dallo stato di runtime.

Conserva il backup precedente all’aggiornamento, il riferimento all’immagine precedente e la definizione salvata finché il server non ha superato il normale periodo di carico. Se dopo una migrazione del database è necessario eseguire il rollback, segui la procedura di ripristino documentata da Jellyfin invece di puntare un’immagine meno recente a uno stato già migrato.