Een back-up van Plex maken zonder een inconsistente database vast te leggen
Stop Plex vóór het kopiëren of maken van een snapshot van het bestandssysteem voor een volledige back-up van Plex-appgegevens; voor alleen de kerndatabase is Plex’ geplande back-up de toepassingsbewuste methode.
Plex schrijft databases, metagegevens, voorkeuren en cache terwijl de server actief is, waardoor een algemene back-uptaak bestanden op verschillende momenten kan vastleggen. Dat betekent niet dat elke live back-up beschadigd is, maar een onbewerkte kopie is moeilijker te vertrouwen tenzij de toepassing of opslaglaag de consistentie coördineert. Bepaal eerst of je de kerndatabase van Plex of de volledige serverstatus nodig hebt. Gebruik vervolgens een methode die bij die scope past en controleer een herstelprocedure voordat je de back-up als voltooid beschouwt.
Scheid de back-up van de kerndatabase van een volledige back-up van servergegevens
Geplande taken in Plex kunnen de kerndatabases back-uppen waarin kijkstatus en matchingsinformatie worden opgeslagen. Dat is nuttig voor databaseherstel, maar Plex zegt expliciet dat dit geen vervanging is voor het back-uppen van de volledige gegevensmap van Plex Media Server. Beschouw deze twee back-ups als verschillende herstelmiddelen in plaats van ervan uit te gaan dat één bestand alles omvat.
De Plex-documentatie over back-ups raadt aan de hoofdmap met servergegevens te back-uppen en vermeldt dat cache op sommige platformen kan worden uitgesloten. Definieer de back-upset bewust, zodat tijdelijke cache het archief niet onnodig vergroot en essentiële database- en metagegevens behouden blijven.
Als je doel is “de server precies herstellen zoals die was”, neem dan de persistente app-d gegevensstructuur op, evenals platform specifieke instellingen die Plex vereist. Als je doel alleen is “de kijkstatus en kerndatabase van de bibliotheek herstellen”, kan de geplande database back-up een kleinere, gerichtere terugvaloptie zijn.
Pauzeer Plex vóór een onbewerkte kopie van het bestandssysteem
Stop voor een eenvoudige back-up op bestandsniveau de Plex-container en controleer of deze is afgesloten voordat je het persistente gegevenspad kopieert of er een snapshot van maakt. Houd de downtime kort: stop de server, leg het consistente punt vast, start opnieuw en laat vervolgens de tragere kopie naar een externe locatie vanaf de snapshot doorgaan als je bestandssysteem die werkwijze ondersteunt.
De documentatie van de back-up-API van SQLite laat zien waarom het kopiëren van een actieve database een coördinatieprobleem is en niet alleen een probleem van bestandsgrootte. Een toepassingsbewuste back-up of een gepauzeerde snapshot levert een gedefinieerde databasestatus op; blind kopiëren van veranderende database-, WAL- en metagegevensbestanden geeft minder zekerheid over het herstelpunt.
Stop Plex niet urenlang terwijl een grote back-up trage opslag doorloopt als je NAS een momentopname kan maken. De veiligere aanpak is een korte schrijfpauze om consistentie vast te leggen, gevolgd door een snapshot- of archiefworkflow waarmee de service weer actief kan worden terwijl de back-up elders naartoe wordt verplaatst.
Hanteer afzonderlijke herstelregels voor logboeken, cache en persistente gegevens
Cache en uitgebreide logboeken kunnen snel veranderen en hebben doorgaans niet dezelfde bewaartermijn nodig als de Plex-database en metagegevens. Door deze paden te scheiden, worden back-ups kleiner en wordt de herstelgrens duidelijker. Zo voorkom je ook dat een omvangrijke logboek- of cachestructuur de ruimte voor applicatiegegevens in beslag neemt.
De ZimaSpace-gids over het scheiden van containerlogboeken en appgegevens legt uit waarom appstatus, logboeken en cache verschillende levenscycli en herstelvereisten hebben. Plex profiteert van hetzelfde beleid, ook als alle drie aanvankelijk in één containerconfiguratie staan.
Voer één hersteltest uit op een wegwerpkopie of in een geïsoleerde container als je de scope van de back-up wijzigt. Een back-upbeleid is niet gevalideerd door alleen een geslaagde upload; het is gevalideerd wanneer Plex de herstelde database en metagegevens kan openen met de verwachte serverstatus.
Controleer de back-up door een bekende status te herstellen
Kies een kleine reeks gegevens die je na herstel kunt controleren: servernaam, één bibliotheek, één bekeken item, één gedeeltelijk bekeken item en een instelling die je kent. Bij een testherstel moeten deze gegevens terugkomen zonder dat Plex wordt gevraagd een nieuwe server aan te maken of de bibliotheek opnieuw op te bouwen op basis van mediabestanden.
Plex documenteert een herstelprocedure voor een database die begint met het stoppen van de server en het vervangen van de actieve database door een back-up. Ook als je volledige back-upmethode hiervan afwijkt, is stoppen vóór het vervangen van de database een nuttige herstelregel.
Als de hersteltest mislukt, verbeter dan eerst de back-upmethode voordat je de bewaartermijn verlengt of meer kopieën automatiseert. Schakel pas over op databaseherstel wanneer een bekende goede back-up niet kan worden hersteld; overschrijf de laatst herstelbare kopie niet terwijl je experimenteert met een beschadigde actieve database.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
