Backup integrati di Jellyfin o backup a livello di file: quali dovresti usare?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Built-In Jellyfin Backups vs File-Level Backups: Which Should You Use?

I backup integrati di Jellyfin e i backup a livello di file proteggono ambiti di ripristino sovrapposti ma diversi. Il sistema integrato comprende i dati dell'applicazione Jellyfin e può creare un archivio mentre il server rimane online. Un backup manuale a livello di file può acquisire uno stato di distribuzione più ampio, ma Jellyfin deve essere arrestato prima di copiare in sicurezza i dati dell'applicazione in uso.

Spesso la soluzione migliore non è scegliere tra l'uno o l'altro. Usa il metodo integrato per creare punti di ripristino frequenti dell'applicazione e un metodo a livello di file o di filesystem con il server arrestato quando devi riprodurre i percorsi dell'host, la configurazione, le definizioni dei container o uno stato più ampio del server.

I backup integrati sono la scelta migliore per i normali punti di ripristino online

L'attuale sistema di backup di Jellyfin può proteggere il database e includere facoltativamente metadati, sottotitoli e dati trickplay mentre il server è in esecuzione. Questo lo rende pratico per i punti di ripristino pianificati senza interrompere intenzionalmente la riproduzione normale.

La documentazione sui backup di Jellyfin afferma che i backup integrati possono essere eseguiti online, mentre i backup manuali della directory dei dati richiedono l'arresto del server. Anche il metodo online è preferibile durante i periodi di minore attività, senza una scansione della libreria attiva nella stessa finestra.

Questa è la scelta predefinita più solida quando l'obiettivo del ripristino è “riportare questa istanza di Jellyfin a uno stato applicativo noto”.

I backup a livello di file sono la scelta migliore quando l'ambito del ripristino include la struttura dell'host

Una copia a livello di file può includere cartelle persistenti dell'applicazione, file Compose, file di ambiente, configurazione del reverse proxy, unità di servizio, script, certificati e altre risorse di distribuzione che un archivio dedicato esclusivamente a Jellyfin non conosce automaticamente.

Questo ambito più ampio è utile in caso di guasto del disco di sistema o di migrazione a un host sostitutivo. Il compromesso riguarda la coerenza: i normali strumenti di copia dei file non comprendono un database SQLite in continua evoluzione, quindi arresta Jellyfin correttamente prima di copiare il suo stato persistente attivo.

La guida di ZimaSpace sui layout di archiviazione di Jellyfin a rischio di ripristino evidenzia lo stesso problema: un backup è incompleto quando nessuno può riprodurre i percorsi, i mount, le autorizzazioni e le dipendenze esterne necessari al server ripristinato.

Il backup consapevole del database è diverso dalla copia di un file SQLite in uso

SQLite supporta backup online coerenti tramite interfacce consapevoli del database, ma un copiatore generico che legge i file mentre Jellyfin li modifica non riceve automaticamente la stessa garanzia.

L'API di backup di SQLite è progettata per copiare un database attivo in una destinazione coerente tramite operazioni coordinate sul database. Per questo motivo, “i file sono stati copiati senza errori” non è una prova sufficiente per un backup manuale di Jellyfin eseguito mentre il servizio è attivo.

Se il tuo metodo manuale consiste solo in rsync, una copia SMB, zip o una copia generica del filesystem, arresta prima Jellyfin, a meno che lo snapshot dello storage non sia coordinato con le scritture dell'applicazione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Confronta l'ambito prima della praticità

Dimensione	Backup integrato	Backup a livello di file
Il server può rimanere online	Sì, preferibilmente con poca attività	Arresta Jellyfin per una copia ordinaria
Database di Jellyfin	Incluso	Incluso se i percorsi persistenti vengono copiati correttamente
Metadati/sottotitoli/trickplay	Supportati selettivamente	Inclusi quando i percorsi copiati li contengono
Script Compose dell'host/configurazione del proxy	Non automaticamente	Possono essere inclusi
Procedura di sostituzione dell'host	Utile per lo stato di Jellyfin	Migliore per uno stato di distribuzione più ampio
Rischio di incoerenza	Consapevole dell'applicazione	Dipende dall'arresto delle attività o dal metodo di snapshot

Conserva il backup al di fuori del dominio di guasto di Jellyfin

Nessuno dei due metodi protegge dalla perdita del pool quando tutti i backup si trovano nello stesso filesystem guasto. Copia gli archivi di backup verificati o i set di ripristino creati a server arrestato su un altro disco, NAS o in una posizione esterna.

Conserva almeno un punto precedente all'aggiornamento, perché Jellyfin applica migrazioni dei dati all'avvio di una versione più recente e non offre una procedura generale di downgrade sul posto.

Prova entrambi i tipi di ripristino se fanno parte del piano di recupero. Un archivio integrato dimostra il ripristino dell'applicazione; una simulazione a livello di file dimostra che l'ambiente è in grado di ricreare i percorsi persistenti e le autorizzazioni necessari.

Domande frequenti

Devo arrestare Jellyfin prima di usare il backup integrato?

No. Il metodo integrato è progettato per funzionare mentre Jellyfin è in esecuzione, anche se si consigliano una bassa attività e l'assenza di scansioni attive della libreria. Arresta il server per una normale copia manuale dei dati di Jellyfin in uso.

Il backup integrato può sostituire il backup dell'host?

Non sempre. Protegge lo stato dell'applicazione Jellyfin, ma un ripristino completo dell'host può dipendere anche da file Compose, impostazioni del proxy, certificati, mount, autorizzazioni, script e altre configurazioni esterne.