Come eseguire il backup di Plex senza acquisire un database incoerente

Per un backup completo dei dati dell’app Plex, arresta Plex prima di copiare o acquisire uno snapshot del filesystem; per il solo database principale, il backup pianificato di Plex è la procedura consapevole dell’applicazione.

Plex scrive database, metadati, preferenze e cache mentre il server è in esecuzione, quindi un processo di backup generico può acquisire i file in momenti diversi. Questo non significa che ogni backup a caldo sia corrotto, ma rende più difficile considerare affidabile una copia grezza, a meno che l’applicazione o il livello di archiviazione non coordinino la coerenza. Decidi innanzitutto se ti serve il database principale di Plex o l’intero stato del server, quindi usa un metodo adeguato all’ambito scelto e verifica una procedura di ripristino prima di considerare completato il backup.

Separa il backup del database principale dal backup completo dei dati del server

Le attività pianificate di Plex possono eseguire il backup dei database principali che contengono lo stato di visualizzazione e le informazioni sulle corrispondenze. È utile per il ripristino del database, ma Plex specifica chiaramente che non sostituisce il backup dell’intera directory dei dati di Plex Media Server. Considera questi due backup come strumenti di ripristino distinti, invece di presumere che un solo file contenga tutto.

La documentazione di Plex sui backup consiglia di eseguire il backup della directory principale dei dati del server e segnala che, su alcune piattaforme, la cache può essere esclusa. Definisci deliberatamente il set di backup, in modo che la cache temporanea non aumenti inutilmente le dimensioni dell’archivio mentre il database e i metadati fondamentali restano protetti.

Se il tuo obiettivo è “ripristinare il server esattamente com’era”, includi l’albero persistente dei dati dell’app e tutte le impostazioni specifiche della piattaforma richieste da Plex. Se invece vuoi solo “recuperare lo stato di visualizzazione e il database principale della libreria”, il backup pianificato del database può essere un fallback più piccolo e mirato.

Metti Plex in pausa prima di una copia grezza del filesystem

Per un semplice backup a livello di file, arresta il container Plex e verifica che sia terminato prima di copiare o acquisire uno snapshot del percorso persistente dei dati. Riduci al minimo l’interruzione: arresta il servizio, acquisisci il punto coerente, riavvialo, quindi lascia che la copia più lenta verso una posizione esterna continui dallo snapshot, se il filesystem supporta questo flusso di lavoro.

La documentazione dell’API di backup di SQLite mostra perché la copia di un database in esecuzione è un problema di coordinamento, non soltanto di dimensioni dei file. Un backup consapevole dell’applicazione o uno snapshot acquisito dopo aver messo in pausa il servizio offre uno stato del database definito; copiare alla cieca database, file WAL e metadati in continua modifica offre meno certezze sul punto di ripristino.

Non arrestare Plex per ore mentre un backup di grandi dimensioni attraversa uno spazio di archiviazione lento, se il tuo NAS è in grado di creare uno snapshot istantaneo. Il modello più sicuro consiste in una breve pausa delle scritture per stabilire la coerenza, seguita da uno snapshot o da un flusso di archiviazione che consenta al servizio di tornare operativo mentre il backup viene trasferito altrove.

Gestisci log, cache e stato persistente con regole di ripristino diverse

La cache e i log dettagliati possono cambiare rapidamente e di solito non richiedono la stessa conservazione del database e dei metadati di Plex. Separare questi percorsi rende i backup più piccoli e chiarisce il perimetro del ripristino. Inoltre impedisce che un albero di log o cache molto voluminoso consumi lo spazio riservato allo stato dell’applicazione.

La guida di ZimaSpace alla separazione dei log dei container dai dati delle app spiega perché stato dell’app, log e cache hanno cicli di vita e requisiti di ripristino diversi. Plex trae vantaggio dalla stessa politica, anche se tutti e tre iniziano nella stessa configurazione del container.

Se modifichi l’ambito del backup, esegui un test di ripristino su una copia usa e getta o su un container isolato. Una politica di backup non è convalidata dal solo completamento di un caricamento; è convalidata quando Plex riesce ad aprire il database e i metadati recuperati con lo stato del server previsto.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica il backup ripristinando uno stato noto

Scegli un piccolo insieme di elementi verificabili dopo il ripristino: nome del server, una libreria, un elemento già visto, un elemento visto parzialmente e un’impostazione che conosci. Un test di ripristino dovrebbe recuperare questi elementi senza chiedere a Plex di creare un nuovo server o ricostruire la libreria dai file multimediali.

Plex documenta una procedura per il ripristino di un database che inizia arrestando il server e sostituendo il database attivo con un backup. Anche se il metodo usato per il backup completo è diverso, la regola di arrestare il servizio prima di sostituire il database è utile per il ripristino.

Se il test di ripristino non riesce, correggi il metodo di backup prima di aumentare la conservazione o automatizzare ulteriori copie. Ricorri alla riparazione del database solo quando non è possibile ripristinare un backup sicuramente valido; non sovrascrivere l’ultima copia recuperabile mentre fai esperimenti con un database attivo danneggiato.