Plex-appgegevens, cache en back-ups scheiden

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Separate Plex App Data, Cache, and Backups - Zima Store Online

Een duurzame Plex-indeling scheidt appgegevens, opnieuw op te bouwen cache, tijdelijk werk en back-upkopieën voordat deze aan opslaglagen worden toegewezen.

Het ontwerp moet de database en metadata behouden wanneer de container of host wordt vervangen, terwijl cache- en transcodegegevens zonder risico voor herstel kunnen worden gewist. Back-ups horen op een ander foutpad dan de actieve toestand te staan. Zodra deze rollen expliciet zijn, kan SSD-capaciteit worden gereserveerd voor latentiegevoelige gegevens in plaats van te worden verbruikt door bulk-kopieën die deze snelheid niet nodig hebben.

Bewaar de servertoestand op een permanent pad met lage latentie

De Plex-database, metadata, voorkeuren en aan de identiteit gekoppelde gegevens definiëren de server en moeten een vervanging van de runtime overleven. Bij deze rol zijn voorspelbare latentie en herstelbaarheid belangrijker dan ruwe capaciteit.

Databaseworkloads reageren sterk op opslaglatentie en bandbreedte wanneer hun toegangspatroon I/O-gevoelig is. Dat ondersteunt het plaatsen van actieve applicatiegegevens op de snellere opslaglaag wanneer metingen dit rechtvaardigen.

Koppel de Plex-toestand onafhankelijk van de containerimage en documenteer eigenaarschap, back-up- en herstelstappen. De indeling van permanente appgegevens vormt het stabiele middelpunt van het opslagontwerp.

Cache kan de reactiesnelheid verbeteren en transcodeerruimte kan snelle tijdelijke schrijfbewerkingen vereisen, maar geen van beide mag worden beschouwd als de gezaghebbende kopie van de bibliotheek. Het verlies ervan mag alleen de prestaties verminderen, niet de serveridentiteit wissen.

Gecachte pagina's kunnen herhaalde opslaglezingen voorkomen en toch opnieuw kunnen worden opgebouwd. Daarom hoort cache in een andere duurzaamheidsklasse dan de Plex-database en metagegevens.

Plaats tijdelijke gegevens op een pad dat veilig kan worden gewist en sluit dit uit van kostbare langetermijnback-ups, tenzij een specifieke herstelvereiste anders bepaalt.

Plaats back-ups op een ander foutpad

Een back-up die naast de actieve Plex-toestand wordt opgeslagen, beschermt tegen sommige applicatiefouten, maar niet tegen apparaatverlies, poolcorruptie of hostuitval. Herstelkopieën moeten een foutgrens overschrijden.

Back-upsystemen hebben verschillende capaciteits- en wijzigingskenmerken. Dimensioneer het back-updoel daarom als een eigen opslagrol in plaats van als ongebruikte ruimte op het apparaat met appgegevens.

Bewaar ten minste één kopie buiten het apparaat met de actieve toestand en definieer hoe snel deze kan worden hersteld. Een snapshot is nuttig, maar niet het enige herstelpad.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Valideer de indeling met een vervangingstest

Met een goede rolindeling kun je de runtime vervangen, de toestand opnieuw koppelen, de cache opnieuw genereren en vanuit een back-up herstellen zonder tijdens het incident paden opnieuw te hoeven classificeren.

Bouw Plex opnieuw op een wegwerphost met alleen de gedocumenteerde locaties voor toestand en back-ups en wis vervolgens bewust het cachepad. Als de serveridentiteit of bibliotheek verloren gaat, zijn de rollen niet correct gescheiden.

Gebruik het geslaagde herstel als het topologiecontract voor toekomstige opslagupgrades.