Maak een back-up van de Plex-gegevensmap voordat je downgrade’t en ga daarna telkens slechts één versie terug, nadat je hebt gecontroleerd of de nieuwere release de compatibiliteit van de database heeft gewijzigd.
Een Plex-rollback betekent niet alleen dat je een binair bestand of Docker-image vervangt. De serverdatabase kan door een update worden gemigreerd en een oudere server begrijpt mogelijk niet de status die door een nieuwere server is opgeslagen. Bewaar eerst de huidige gegevens, bepaal welke build voor het laatst goed werkte en zorg dat de rollback omkeerbaar blijft. Het doel is vast te stellen dat de update de regressie heeft veroorzaakt, zonder van een softwareprobleem een databaseherstelprobleem te maken.
Bevries de huidige status voordat je de serverversie wijzigt
Stop Plex op de juiste manier en maak een kopie van de permanente servergegevensmap. Noteer de huidige serverversie en het exacte symptoom waarvoor je teruggaat. Als je Docker gebruikt, noteer dan ook de huidige imagetag of digest en de laatst bekende goed werkende tag, zodat de rollback expliciet is en niet neerkomt op “latest versus wat er toevallig in de cache stond”.
Een recent voorbeeld van herstel op het Plex-forum vermeldt dat eerdere installatieprogramma’s mogelijk beschikbaar zijn in de map Updates van de server en bespreekt het teruggaan naar een eerdere serverversie. Beschouw dit als een operationele referentie die specifiek is voor die versie, niet als een garantie dat elk platform pakketten op dezelfde manier opslaat.
Verwijder de huidige database of voorkeuren niet als eerste rollbackstap. Als de oudere build niet werkt, heb je de ongewijzigde back-up nodig om terug te keren naar de status van vóór de rollback. Bij een veilige rollback blijven beide richtingen behouden: terug naar de oude build en weer vooruit naar de huidige build.
Controleer vóór de downgrade of er een database-migratiegrens is
Lees de releaseopmerkingen of bespreking van bekende regressies voor de versie die je hebt geïnstalleerd. Sommige Plex-releases hebben de databasecompatibiliteit gewijzigd, waardoor een grote stap terug kan mislukken, zelfs als het oudere uitvoerbare bestand zelf correct wordt geïnstalleerd. Als er een migratiegrens bestaat, volg dan het ondersteunde tussenpad of herstel een compatibele databaseback-up in plaats van de oude server tegen nieuwere status te forceren.
De richtlijnen uit de Plex-community rond de migratie in versie 1.40 beschreven een specifiek geval waarin de databasecompatibiliteit de mogelijke rollbackpaden beperkte. De exacte versienummers in dat geval zijn historisch; de blijvende regel is dat je vóór een downgrade de migratiegrens voor jouw release controleert.
Als Plex momenteel een databasemigratie uitvoert, onderbreek die dan niet alleen om sneller terug te kunnen gaan. Laat de migratie voltooien of herstel een bekende compatibele back-up. Het onderbreken van schemawijzigingen veroorzaakt een andere fouttoestand, waardoor het moeilijker wordt om vast te stellen of de release zelf het oorspronkelijke probleem heeft veroorzaakt.
Installeer of pin de vorige build zonder andere variabelen te wijzigen
Wijzig alleen de Plex-serverversie. Behoud dezelfde koppeling naar de app-gegevens, mediapaden, netwerkmodus, hardwareapparaten en clientinstellingen. Pin in Docker de vorige imagetag in plaats van op een zwevende tag te vertrouwen; gebruik bij pakketinstallaties het vorige installatieprogramma van een betrouwbare bron die geschikt is voor het platform.
De herstelchecklist voor ZimaSpace-thuisservers gebruikt hetzelfde herstelprincipe: bewaar een leesbare status, bepaal welke laag faalt en voorkom dat je eerst het verkeerde onderdeel vervangt of opnieuw opbouwt. Een Plex-rollback moet net zo beperkt blijven.
Start Plex en controleer de logboeken op databasefouten voordat je het afspelen test. Als de oude build de database weigert of als een nieuwe server start, stop dan onmiddellijk en herstel de beveiligde status, in plaats van nieuwe bestanden naar een niet-passende gegevensmap te laten schrijven.
Reproduceer de oorspronkelijke regressie voordat je besluit terug te blijven
Zodra de oude build normaal start, reproduceer je exact de situatie die na de update mislukte: dezelfde client, media, netwerkroute, bibliotheekactie of geplande taak. Een rollback bewijst pas dat de release erbij betrokken was wanneer de oude versie de oorspronkelijke trigger goed doorloopt en de rest van de server gezond blijft.
Start Plex eenmaal opnieuw en herhaal de trigger, zodat je weet dat het herstel een normale levenscyclus doorstaat. Controleer vervolgens de toegang tot bibliotheken, kijkgeschiedenis, externe toegang indien gebruikt en elk hardwaretranscoderingspad dat door de update kan zijn geraakt. Verklaar het probleem niet opgelost op basis van alleen het startscherm.
Als de vorige build ook faalt, keer dan terug naar de huidige beveiligde status en ga verder met de diagnose in plaats van nog meer downgrades op elkaar te stapelen. Als de vorige build het probleem oplost, houd de rollback dan tijdelijk, documenteer de werkende versie en wacht op een latere Plex-release die de regressie verhelpt voordat je opnieuw upgradet.
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...

