Ripristina Jellyfin dopo un aggiornamento del container non riuscito proteggendo lo stato persistente prima di sostituire, ripristinare o ricreare il runtime.
Un aggiornamento non riuscito può dipendere da un problema dell’immagine, da una variabile d’ambiente modificata, da una mappatura dei dispositivi persa, da un errore nel volume o da un problema di migrazione dell’applicazione. Acquisisci lo stato del problema e identifica quale livello è cambiato. Il recupero è più sicuro quando la directory di configurazione rimane intatta finché non sai se il problema riguarda davvero il runtime o i dati.
Blocca lo stato del problema prima di un altro pull
Disabilita gli aggiornamenti automatici e i riavvii ripetuti, così ogni nuovo tentativo non modifica i log, i tag dell’immagine o lo stato dell’applicazione. Salva la definizione effettiva del container e il primo errore fatale.
Un aggiornamento non riuscito è molto più facile da annullare quando esiste già un backup di Jellyfin precedente alla modifica; senza di esso, un errore del runtime può trasformarsi in un problema di recupero dello stato.
Registra il digest dell’immagine, i mount, i dispositivi, l’ambiente, la modalità di rete e i log recenti. Non eseguire comandi di pulizia o prune mentre stai ancora identificando gli elementi necessari per il recupero.
Proteggi configurazione e database prima di ricreare qualsiasi elemento
L’immagine sostituibile deve essere separata dal database, dalla configurazione, dai metadati e dai plugin persistenti di Jellyfin. Crea una copia di sola lettura o uno snapshot prima che un binario precedente o successivo apra di nuovo quello stato.
I backup della configurazione di Jellyfin proteggono gli account utente, le impostazioni delle librerie, la cronologia di visione e i metadati separatamente dalla libreria multimediale stessa.
Copia il percorso persistente in una seconda posizione e conserva la proprietà dei file. Il confine di persistenza del container è corretto solo se un runtime pulito riesce a riconnettersi senza generare un server vuoto.
Ripristina il livello minimo responsabile del problema
Se l’immagine precedente funziona con lo stesso stato e gli stessi mount, il problema riguarda il percorso di aggiornamento e non la libreria. Se entrambe le versioni non funzionano, interrompi il ciclo tra le immagini e analizza separatamente dati e autorizzazioni.
Un errore di avvio di Jellyfin specifico della versione deve essere distinto dalle modifiche generali a spazio di archiviazione e rete.
Testa un singolo ripristino o un’immagine funzionante nota utilizzando una copia dello stato. Evita di forzare migrazioni ripetute sull’unica copia del database.
Verifica identità, librerie e una riproduzione prima di riattivare l’automazione
Un container che raggiunge lo stato «in esecuzione» non è completamente ripristinato finché non tornano gli utenti previsti, le librerie, lo stato di visione, i percorsi e il comportamento di riproduzione. Le scansioni e l’automazione associata possono creare nuove scritture, quindi mantienile in pausa durante la verifica.
Un test di ripristino corretto verifica il comportamento dell’applicazione dopo il recupero, invece di considerare la semplice estrazione riuscita dei file una prova sufficiente.
Conferma l’identità del server, la consultazione di una libreria, una riproduzione Direct Play, una transcodifica se utilizzata e un riavvio. Solo dopo riattiva le scansioni pianificate e gli aggiornamenti automatici.
Supporto e consigli
Altro da leggere

È meglio eseguire il backup di Jellyfin mentre è in funzione o arrestare prima il servizio?
Per semplicità, preferisci i backup con il servizio arrestato; usa gli snapshot a caldo solo quando lo stato dell’applicazione viene acquisito in modo coerente...

Perché Jellyfin funziona a temperature elevate o è rumoroso quando nessuno sta guardando contenuti in streaming?
Il calore in stato di inattività di solito indica attività in background o un carico di lavoro su un host condiviso, quindi identifica il...

Quando dovresti ricostruire Jellyfin invece di ripararlo?
Scegli la ricostruzione invece della riparazione quando il problema è la deriva dell’ambiente di esecuzione e lo stato persistente è stato sottoposto a backup;...

