Bewaar de Plex-status die de server en bibliotheek definieert; beschouw tijdelijke cache- en transcodegegevens als opnieuw op te bouwen, tenzij je herstelontwerp anders vereist.
Het draait om herstelbaarheid, niet om de mapgrootte. Configuratie, databases, metagegevens, illustraties, verwijzingen naar de kijkstatus en de serveridentiteit zijn lastig of tijdrovend om consistent opnieuw te maken, terwijl tijdelijke transcoderingsbestanden en veel cachebestanden opnieuw kunnen worden gegenereerd. Classificeer elk pad op basis van wat er na verwijdering zou gebeuren voordat je bepaalt waar het thuishoort.
De serverstatus is meer dan een instellingenbestand
Een Plex-implementatie wordt bepaald door een groep permanente bestanden, niet alleen door de zichtbare voorkeuren in de webinterface. De bibliotheekdatabase en metagegevensmappen bevatten relaties en serverstatus die ervoor zorgen dat een herstelde instantie eruitziet als de oude.
Plex-opslag van metagegevens omvat databases, illustraties, indexen en andere bestanden met serverstatus.
Maak een lijst van elk gekoppeld Plex-pad en markeer welke paden nodig zijn om dezelfde bibliotheken en metagegevens op een schone host opnieuw te maken. Als een pad de serverdatabase of metagegevensstatus bevat, neem het dan op in de permanente back-upset. Door permanente containergegevens buiten de vervangbare runtime te bewaren, scheid je opnieuw op te bouwen lagen van status die een containervervanging moet overleven.
Cache is waardevol, maar meestal opnieuw op te bouwen
Cache kan de latentie verlagen zonder de canonieke kopie van de bibliotheek te zijn. Het verlies van een opgewarmde cache kan de server tijdelijk trager laten aanvoelen, maar moet niet hetzelfde worden behandeld als het verlies van de database.
Linux-paginacaching kan herhaalde toegang tot opslag verminderen zodra gegevens in het geheugen zijn opgewarmd.
Start een testinstantie opnieuw op nadat je alleen bekende wegwerpbare cache hebt gewist en vergelijk het opwarmgedrag met dat van de intacte server. Als de server zijn bibliotheekidentiteit of instellingen verliest, was het verwijderde pad niet slechts tijdelijke cache.
Database-integriteit verandert de back-upprioriteit
Permanente gegevens zijn alleen nuttig als de vastgelegde database intern consistent is. Een gekopieerde database die tijdens schrijfbewerkingen is gemaakt, is mogelijk minder betrouwbaar dan een back-up die tijdens een gecontroleerde rustige toestand is geproduceerd.
Schrijfveiligheid van SQLite geeft de voorkeur aan gecontroleerde schrijfbewerkingen. Gebruik de actieve Plex-database daarom niet als test voor toegangsrechten.
Plan indien praktisch een back-upvenster waarin de schrijver tijdelijk wordt stilgelegd of gestopt en controleer vervolgens of de gekopieerde database kan worden geopend. Als de hersteltest mislukt terwijl de bestanden wel succesvol zijn gekopieerd, verbeter dan eerst de consistentie van de back-up voordat je de bewaartermijn verlengt.
Tijdelijke transcodeerruimte valt in een andere herstelcategorie
Transcoderingsuitvoer is werkgegevens die voor een afspeelpad worden gemaakt, niet de gezaghebbende bibliotheek. Je kunt deze gegevens plaatsen met het oog op snelheid en capaciteit, zonder hetzelfde duurzaamheidsbeleid als voor de Plex-database te hanteren.
Wanneer Plex-transcodering nodig is, verschuift de compatibiliteit met clients het decodeer- en encodeerwerk naar de server.
Documenteer transcodeer- en cachekoppelingen afzonderlijk van de koppeling voor permanente Plex-gegevens in je implementatiebestand. Als een tijdelijk pad de enige plaats is waar een unieke instelling of een databasebestand bestaat, classificeer het dan opnieuw vóór de volgende migratie.
Tech & AI HUB
Meer om te lezen

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

