È possibile preservare la cronologia dei contenuti guardati durante la migrazione di un server multimediale?
Sì, la cronologia delle visualizzazioni può essere preservata quando la migrazione trasferisce nel nuovo server il database degli utenti, l’identità dei contenuti multimediali e lo stato compatibile dell’applicazione.
La semplice copia dei file dei film non trasferisce i contrassegni di riproduzione, le posizioni di ripresa, i preferiti, gli account utente o le preferenze per singola traccia. Questi dati risiedono nel database persistente del server multimediale e sono collegati agli identificativi degli utenti e dei contenuti. La procedura più sicura è una migrazione completa dell’istanza sulla stessa piattaforma, con un backup coerente eseguito a server arrestato, versioni corrispondenti, percorsi stabili dei container e un test di ripristino isolato prima che la destinazione diventi il server attivo.
Definisci se stai trasferendo un’istanza o cambiando piattaforma
Una migrazione della stessa applicazione da un host a un altro può generalmente preservare lo stato completo del server. Il passaggio da Plex a Jellyfin, da Emby a Jellyfin o da un’altra piattaforma richiede un’esportazione, un servizio di sincronizzazione, un plugin o una traduzione basata su API, perché i database utilizzano schemi e identificativi diversi.
Gli utenti di Jellyfin hanno richiesto un’esportazione più semplice di account, cronologia delle visualizzazioni e impostazioni utente proprio perché i dati utente non consistono nella semplice copia di una cartella multimediale.
Scegli una sola procedura prima di iniziare: ripristino dell’istanza completa per lo stesso server multimediale oppure trasferimento documentato dello stato di visualizzazione per il cambio di piattaforma. Non combinarle copiando parzialmente un database in una destinazione appena sottoposta a scansione.
Esegui il backup dell’intero stato persistente del server
Fai l’inventario della configurazione, del database, degli utenti, dei plugin, dei metadati, dei certificati, delle impostazioni delle attività pianificate e dell’ambiente dei container. Annota la versione dell’applicazione in esecuzione, il tag dell’immagine, la posizione del database e tutti i mount persistenti.
Lo stato di visualizzazione può includere più di un valore booleano. Una discussione su Jellyfin identifica campi come stato di riproduzione, numero di riproduzioni, posizione di riproduzione, data dell’ultima riproduzione, preferiti e flussi selezionati nei record dei dati utente.
Esegui il backup dell’intero insieme di dati persistenti supportato invece di esportare una sola tabella, a meno che non esista alcun percorso di ripristino completo. Un trapianto parziale del database può preservare un campo danneggiando gli ID utente, i riferimenti ai contenuti, le aspettative dello schema o la cronologia delle migrazioni più recenti.
Arresta il server o usa uno snapshot coerente del database
Impedisci la riproduzione, le scansioni, gli aggiornamenti dei metadati e le modifiche degli utenti durante la creazione del backup finale. Arresta il processo del server multimediale prima di copiare i file SQLite, a meno che lo spazio di archiviazione e l’applicazione non supportino un metodo coerente di backup online.
Una discussione sui backup di Jellyfin avverte che la copia di file SQLite attivi può acquisire uno stato incoerente, perché il database potrebbe essere in uso durante un normale backup del file system.
Registra checksum e dimensioni dei file dopo l’arresto del servizio, quindi mantieni invariato il server di origine finché la destinazione non supera la verifica. Non consentire a entrambi i server di scrivere nello stesso database o nella stessa destinazione di sincronizzazione dello stato di visualizzazione durante il passaggio.
Mantieni sotto controllo le versioni dell’applicazione e la direzione degli aggiornamenti
Quando possibile, esegui inizialmente il ripristino nella stessa versione dell’applicazione. Verifica che plugin, schema del database e percorsi dei container corrispondano prima di aggiornare la destinazione.
Le migrazioni del database possono essere a senso unico e un’istanza ripristinata potrebbe non avviarsi quando lo stato di migrazione registrato non corrisponde allo schema effettivo. Un problema attuale di Jellyfin documenta un conflitto dello stato di migrazione ripristinato.
Avvia il server ripristinato senza accesso pubblico ai client, leggi il registro delle migrazioni ed esegui un altro snapshot prima di qualsiasi aggiornamento. Non testare mai una versione più recente sull’unica copia del database aspettandoti poi che la versione precedente possa riaprirla.
Preserva i percorsi multimediali stabili e l’identità degli elementi
Mantieni gli stessi percorsi visibili ai container anche se cambiano i dischi dell’host. Ad esempio, rimappa un nuovo pool di archiviazione sui percorsi esistenti /media/movies e /media/tv invece di assegnare alla destinazione radici di libreria completamente nuove.
La modifica dei percorsi può creare nuovi record multimediali o lasciare voci obsolete accanto a quelle ripristinate. Un problema di Jellyfin collega i percorsi delle librerie rimossi a metadati obsoleti persistenti e a comportamenti duplicati nella sezione dei contenuti da continuare a guardare.
Verifica un film e un episodio usando il percorso del file e l’identità interna dell’elemento prima di avviare una scansione completa. Se la destinazione considera ogni file come nuovo, interrompi la procedura e correggi la mappatura dei percorsi prima che lo stato di visualizzazione venga distribuito tra record duplicati.
Mantieni coerenti gli utenti e i relativi identificativi
Ripristina gli utenti insieme al database invece di ricreare manualmente gli account usando gli stessi nomi visualizzati. Un nome utente visibile non dimostra che l’utente della destinazione abbia lo stesso identificativo interno.
Il ripristino manuale della cronologia normalmente interessa la tabella dei dati utente, ma i record dipendono sia dai riferimenti agli utenti sia da quelli ai contenuti. Per questo, lo spostamento delle librerie senza perdere i metadati ha richiesto una gestione attenta dei percorsi e del database, non una scansione cieca dei file spostati.
Dopo il ripristino, accedi con ciascun utente rappresentativo e confronta i contrassegni di riproduzione, gli elementi in corso, le posizioni di ripresa, i preferiti, le preferenze audio e quelle dei sottotitoli. Non valutare il successo usando soltanto l’account amministratore.
Usa una procedura di sincronizzazione o esportazione per i passaggi tra piattaforme
Quando le applicazioni di origine e destinazione sono diverse, esporta la cronologia tramite un plugin supportato, uno strumento API o un servizio indipendente come una piattaforma di monitoraggio delle visualizzazioni. Prova un campione ridotto prima di sincronizzare l’intera libreria.
Abbina esplicitamente utenti e titoli e considera episodi, edizioni, versioni alternative e file rinominati come potenziali conflitti di identità. Il solo titolo di un film è un criterio troppo debole quando più anni o versioni condividono lo stesso nome.
Conserva un’esportazione della cronologia di origine anche dopo che la prima importazione è riuscita. Il trasferimento dovrebbe essere ripetibile o verificabile, così da poter correggere utenti mancanti e titoli non corrispondenti senza ricominciare la migrazione.
Esegui un ripristino isolato e completa il passaggio solo dopo la verifica
Avvia la destinazione su una porta temporanea con scansioni pianificate, webhook e sincronizzazioni esterne disabilitati. Verifica utenti, quantità delle librerie, totali delle visualizzazioni, posizioni di ripresa, playlist, raccolte e diversi titoli selezionati casualmente.
Il flusso di migrazione dei dati NAS di ZimaSpace fornisce la regola generale: conserva l’origine finché lo stato copiato non è stato verificato dalla destinazione.
La migrazione è completa solo quando l’istanza ripristinata supera un riavvio, i percorsi rimangono stabili, gli utenti rappresentativi conservano la propria cronologia e una nuova riproduzione aggiorna correttamente la destinazione. Mantieni il server di origine offline ma recuperabile finché il nuovo server non ha superato diversi giorni di utilizzo normale e non è stato eseguito un nuovo backup.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
