Så separerar du appdata, cache och säkerhetskopior för Jellyfin

Skilj åt Jellyfins appdata, cache och säkerhetskopior genom att fråga dig vad som måste överleva en återskapning, vad som kan återskapas och vad som måste finnas tillgängligt även om enheten med det aktiva tillståndet går sönder. Dessa tre roller kan dela en fysisk SSD i en liten server, men de bör inte ha samma livscykel eller återställningspolicy.

Beständigt apptillstånd omfattar databasen, konfigurationen, användar- och uppspelningstillstånd samt andra filer som krävs för att återställa samma server. Cache och transkodningsdata kan raderas när inga aktiva uppgifter längre behöver dem. Säkerhetskopior är återställningskopior och bör inte vara beroende av samma lagringsgräns som de är avsedda att återställa från.

Gör beständiga appdata till den auktoritativa tillståndsrollen

Börja med att kartlägga värdsökvägen eller volymen där Jellyfins beständiga tillstånd lagras. I en containerdistribution kan avbildningen bytas ut; det monterade tillståndet är det som måste återanslutas när containern återskapas. Dokumentera värdsökväg, containersökväg, ägarskap, filsystem, minsta lediga utrymme och säkerhetskopieringsmetod.

En aktuell Jellyfin-layout för Docker Compose skiljer beständiga konfigurations- och cachekataloger åt innan media monteras. Den skillnaden mellan sökvägar är praktiskt användbar även när båda katalogerna till en början ligger på samma SSD.

Placera inte den auktoritativa databasen på en plats som du är beredd att rensa vid felsökning. En lyckad rensning av cache ska aldrig kunna återställa användare, bibliotek, visningshistorik eller serveridentitet.

Behandla cache och transkodningsutrymme som återskapningsbara arbetsdata

Cache används för att minska mängden arbete som behöver göras upprepade gånger eller för att lagra tillfälliga bearbetningsresultat. Värdet ligger i prestanda och bekvämlighet, inte i att bevara identiteten. Ge den tillräcklig kapacitet för de största normala topparna i bakgrundsarbete och transkodning, men se till att den kan återskapas utan att hela servern behöver återställas.

Låt inte cache med hög omsättning eller transkodning styra säkerhetskopieringspolicyn för databasen. Om samma snabba enhet används för båda rollerna, använd separata kataloger eller datauppsättningar med egna kvoter och övervakning. Då kan en tillfällig belastning inte förbruka det lediga utrymme som behövs för databasskrivningar eller en framtida återställning.

När bläddring, metadata och tillståndsåtgärder känns långsamma medan sekventiella medieläsningar fortfarande fungerar bra, ger ZimaSpaces analys av att ha interaktivt medieserverstillstånd på SSD ett användbart nästa test, utan att behandla det stora mediebiblioteket som samma lagringsarbetsbelastning.

Containern är förbrukningsbar; tillståndet och receptet för återuppbyggnad är det inte

En container kan hämtas igen; dess driftsättningsrecept och beständiga data kan inte förutsättas dyka upp igen. Spara Compose- eller tjänstedefinitionen, avbildningsversionen eller taggpolicyn, monteringskartan, tjänstens identitet, referenser till nödvändiga hemligheter och det beständiga Jellyfin-tillståndet.

Den praktiska tumregeln i det här arbetsflödet för säkerhetskopiering av Docker-volymer är att användbara återställningsdata finns i volymer, bind-monteringar, appdata och tjänstedefinitioner, inte i själva den förbrukningsbara containern.

För aktiva databaser är konsekvens viktigare än att kopiera varje byte medan tjänsten är upptagen. Använd applikationens stödda säkerhetskopieringsmetod eller en kontrollerad stopp-/ögonblicksbildsmetod som passar driftsättningen, i stället för att betrakta en godtycklig kopiering av en aktiv fil som en beprövad återställningspunkt.

Featured

ZimaCube 2 personlig moln-NAS för hemmet

ZimaCube2

$799.00 - $2,499.00

Buy Now

En säkerhetskopia bredvid det aktiva tillståndet täcker inte fel på värden

En säkerhetskopia bredvid den aktiva databasen kan hjälpa vid oavsiktliga ändringar, men den klarar inte alla händelser som kan slå ut produktionen, som fel på lagringspoolen eller värden, utpressningsprogram, stöld eller strömavbrott. Förvara en återställningskopia på en annan enhet eller inom en annan administrativ gräns och skydda de nycklar eller inloggningsuppgifter som behövs för att läsa den.

En plan för säkerhetskopiering vid självhosting bör omfatta tillstånd, hemligheter, återställningskopior och instruktioner för återställning. Den här granskningen av återställning vid självhosting betonar kopior utanför den uppenbara skadezonen och skriftliga underlag för återuppbyggnad, i stället för att räkna ögonblicksbilder som en komplett plan.

Låt inte lagringsmålet för säkerhetskopior påverkas av samma cachelagringsregel eller rensningskommando som den aktiva applagringen. Säkerhetskopian har en separat roll även om den tillfälligt lagras i samma chassi.

Kartlägg lagringsrollerna innan du köper eller flyttar diskar

Den här översikten förebygger ett vanligt misstag vid omstrukturering: att flytta allt till den snabbaste disken när det bara var svarstiden för apptillståndet som var ett problem, eller att säkerhetskopiera alla tillfälliga filer men utelämna tjänstdefinitionen som behövs för att återskapa containern.

Visa separationen med en tillfällig återställning

Återställ Jellyfin-tillståndet till en ny sökväg eller en isolerad värd, rikta en kopia av driftsättningsdefinitionen mot den platsen, ge icke-destruktiv åtkomst till representativa medier och starta tjänsten utan den ursprungliga cachen. Servern ska komma tillbaka med förväntad identitet, bibliotek, användare och inställningar trots att cachen är tom från början.

Skillnaden blir mätbar först när en säkerhetskopia återställs till en isolerad målmiljö och verifieras utan att använda produktionsdata. Testinstansen av Jellyfin ska startas från återställningskopian, återansluta de sökvägar den behöver och visa att den aktiva volymen inte i hemlighet slutför återställningen.

Upplägget fungerar när cache kan tas bort utan att identiteten går förlorad, körmiljön kan återskapas utan att biblioteket måste byggas upp från minnet och minst en säkerhetskopia kan återställa tjänsten när man utgår från att enheten med appdata inte längre är tillgänglig.