Moet je een back-up maken van Plex terwijl het actief is, of de service eerst stoppen?
Voor een normale back-up op bestandsniveau van Plex-appgegevens stopt of pauzeert u Plex eerst. Een live kopie is alleen geschikt wanneer de back-upmethode is ontworpen om een consistente draaiende database vast te leggen en de rest van de Plex-status met compatibele semantiek wordt beschermd.
De keuze gaat niet echt over ‘uitvaltijd versus geen uitvaltijd’. Het gaat om ‘een eenvoudige consistente kopie versus een live methode die actieve databasebewerkingen begrijpt’. Als u niet kunt uitleggen hoe de live methode een geldige Plex-database op een bepaald moment bewaart, plan dan een korte stop en controleer de back-up in plaats van ervan uit te gaan dat het veilig is om geopende bestanden te kopiëren.
Kies eerst de back-upmethode en daarna de uitvaltijd
Begin met het benoemen van het back-upmechanisme. Een tar-archief, rsync, SMB-kopie, cloudsync-client of algemene snapshot van actieve bestanden werkt anders dan een databasebewuste back-upopdracht. De veilige bedrijfsstatus hangt af van wat de tool kan garanderen, niet van het feit of de kopieeropdracht succesvol wordt voltooid.
Plex-appgegevens bevatten databases en metadata en configuratie die kunnen veranderen terwijl de server actief is. Een algemeen overzicht van Plex-back-ups vermeldt dat de Plex-gegevensmap metadata en databases bevat. De server beschermen is dus meer dan alleen de mediabestanden opslaan.
Beschouw voor deze beslissing een gewone kopie van het bestandssysteem als de voorzichtige optie en een applicatiebewuste databaseback-up als een afzonderlijke techniek. Noem een live kopie niet veilig alleen omdat de bestemming bestanden met de verwachte namen en grootte ontvangt.
Stop Plex voor een gewone kopie van appgegevens op bestandsniveau
Als uw back-uptaak eenvoudigweg de map met Plex-appgegevens kopieert, is de veiligste standaardinstelling om de Plex-service of -container gedurende het kopieervenster te stoppen. Daarmee voorkomt u gelijktijdige schrijfbewerkingen terwijl de database en gerelateerde status worden vastgelegd.
In een discussie in de Plex-community waarschuwt een ervaren technische bijdrager dat een gewone live bestandskopie een inconsistente database kan vastleggen. Daarbij wordt onderscheid gemaakt tussen statische metadata-bestanden en de geopende database. Dit ondersteunt sterk het pauzeren van Plex wanneer de back-uptool geen mechanisme voor databaseconsistentie heeft.
Houd de stop zo kort mogelijk: controleer of er geen kritieke scan of opname bezig is, stop Plex, voer de voorbereide kopie uit, controleer of de taak is voltooid en start Plex opnieuw. Gebruik de uitvaltijd niet om problemen met rechten op de bestemming of beschikbare ruimte te ontdekken die vooraf gecontroleerd hadden kunnen worden.
Gebruik alleen een live back-up wanneer de databasemethode dit ondersteunt
Plex stoppen is geen vereiste van SQLite zelf. Een live back-up kan geldig zijn wanneer de methode SQLite-bewuste voorzieningen gebruikt die een consistente databasesnapshot maken terwijl normale toegang door de applicatie doorgaat.
Een beoordeling van SQLite-back-ups in productie legt uit dat de SQLite-back-up-API een live database kan kopiëren terwijl andere verbindingen blijven schrijven. De back-up vertegenwoordigt een gedefinieerde databasestatus in plaats van een blinde kopie van veranderende bestanden.
Die uitzondering dekt alleen wat de applicatiebewuste methode daadwerkelijk beschermt. Als uw workflow een live SQLite-back-up voor de database gebruikt maar metadata en voorkeuren afzonderlijk kopieert, leg dan vast hoe deze onderdelen in de tijd op elkaar aansluiten en test een herstel. Hoge beschikbaarheid is niet nuttig als het gecombineerde resultaat de verwachte serverstatus niet kan reconstrueren.
Maak een back-up van meer dan alleen het databasebestand
Een back-up van alleen de database kan belangrijke bibliotheekgegevens bewaren, maar voor volledig herstel van Plex kunnen ook metadata, voorkeuren, plug-ingegevens, certificaten en platformspecifieke instellingen nodig zijn. Bepaal welke daarvan u nodig zou hebben als de oorspronkelijke host verdween, in plaats van alleen het eenvoudigste bestand te back-uppen.
Bescherming van mediabestanden moet u als een afzonderlijke capaciteitsbeslissing behandelen. De Plex-configuratie kan gigabytes groot zijn, terwijl de mediabibliotheek terabytes kan omvatten, en voor die gegevensverzamelingen zijn vaak verschillende back-upschema’s en bestemmingen nodig. Eén klein archief met appgegevens mag niet de indruk wekken dat de films of familiemedia zelf beschermd zijn.
De ZimaSpace-handleiding voor consistente back-ups van databasecontainers is een nuttige vervolgstap wanneer u appgegevens, databasestatus, persistente volumes en een hersteltest moet coördineren binnen een draaiende thuisserverstack.
Controleer de back-up voordat u een van beide methoden vertrouwt
Welke methode u ook kiest, inspecteer de back-up buiten de live Plex-map. Controleer of de verwachte bestanden aanwezig zijn, noteer het tijdstip en de grootte en valideer de database of het archief met de tool die bij het back-upformaat past voordat u de vorige bekende goede kopie verwijdert.
Voer daarna, indien praktisch mogelijk, een hersteltest uit naar een geïsoleerd pad of een testinstantie. Het doel is te bewijzen dat de back-up als een coherente serverstatus kan worden geopend, niet alleen dat de back-upsoftware succes heeft gemeld. Bewaar ten minste één ouder herstelpunt totdat het nieuwste die test heeft doorstaan.
Een back-upmethode slaagt niet voor de operationele test als herstel ongedocumenteerde aannames vereist over paden, eigenaarschap, inloggegevens of welke databasekopie bij welke metadataboom hoort. Verbeter de werkwijze terwijl Plex in productie nog gezond is, in plaats van deze afhankelijkheden pas na een storing te ontdekken.
Kies de routine met het laagste risico voor uw beschikbaarheidsbehoeften
Voor de meeste Plex-servers thuis is een korte geplande stop de eenvoudigste betrouwbare routine voor een volledige kopie van appgegevens op bestandsniveau. Plan deze in een periode met weinig gebruik, bereid de bestemming vooraf voor en automatiseer het opnieuw starten en controleren zodat de uitvaltijd voorspelbaar blijft.
Kies alleen een live workflow wanneer beschikbaarheid de extra complexiteit rechtvaardigt en de methode expliciet databaseconsistente semantiek biedt voor de draaiende status die u beschermt. Houd een gedocumenteerd alternatief voor stoppen en kopiëren achter de hand voor het geval de live back-uptool verandert of de hersteltest mislukt.
De praktische beslisregel is: als de back-up een gewone kopie van actieve Plex-bestanden is, stopt u de service eerst; als het een applicatiebewuste live databasemethode is, bewijst u de consistentie en dekking met een hersteltest. De betere back-up is degene die u herhaaldelijk kunt herstellen, niet degene die nul uitvaltijd rapporteert.
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...
