Comment revenir en toute sécurité à une version antérieure de Plex après une mise à jour problématique

Sauvegardez le répertoire de données Plex avant de procéder à la rétrogradation, puis revenez en arrière une version à la fois, uniquement après avoir vérifié si la version plus récente a modifié la compatibilité de la base de données.

Annuler une mise à jour de Plex ne consiste pas simplement à remplacer un binaire ou une image Docker. La base de données du serveur peut être migrée lors d’une mise à jour, et un serveur plus ancien peut ne pas comprendre les données écrites par une version plus récente. Préservez d’abord les données actuelles, identifiez la dernière version connue comme fiable et faites en sorte que la rétrogradation puisse être annulée. L’objectif est de prouver que la mise à jour a provoqué la régression, sans transformer un problème logiciel en problème de récupération de base de données.

Figez l’état actuel avant de modifier la version du serveur

Arrêtez Plex proprement et copiez le répertoire de données persistant du serveur. Notez la version actuelle du serveur ainsi que le symptôme précis pour lequel vous effectuez la rétrogradation. Si vous utilisez Docker, notez également le tag ou le digest de l’image actuelle, ainsi que le tag de la dernière version connue comme fiable, afin que la rétrogradation soit explicite plutôt que définie comme « latest contre une version quelconque mise en cache ».

Un récent exemple de récupération publié sur le forum Plex indique que les anciens installateurs peuvent être disponibles dans le répertoire Updates du serveur et explique comment revenir à une version précédente du serveur. Considérez cela comme une référence opérationnelle limitée à une version donnée, et non comme la garantie que toutes les plateformes stockent les paquets de la même manière.

Ne supprimez pas la base de données ni les préférences actuelles comme première étape de la rétrogradation. Si l’ancienne version échoue, vous aurez besoin de la sauvegarde intacte pour revenir à l’état antérieur à la rétrogradation. Une rétrogradation sûre préserve toujours les deux possibilités : revenir à l’ancienne version et repasser à la version actuelle.

Vérifiez l’existence d’une limite de migration de la base de données avant la rétrogradation

Lisez les notes de version ou les discussions consacrées aux régressions connues pour la version que vous avez installée. Certaines versions de Plex ont modifié la compatibilité des bases de données, ce qui signifie qu’un retour trop important en arrière peut échouer même si l’ancien exécutable s’installe correctement. Lorsqu’une limite de migration existe, suivez le parcours intermédiaire pris en charge ou restaurez une sauvegarde compatible de la base de données au lieu de forcer l’ancien serveur à utiliser un état plus récent.

Les recommandations de la communauté Plex concernant la migration 1.40 ont documenté un cas précis où la compatibilité de la base de données limitait les possibilités de rétrogradation. Les numéros de version exacts de ce cas sont historiques ; la règle durable consiste à vérifier la limite de migration correspondant à votre version avant de procéder à la rétrogradation.

Si Plex effectue actuellement une migration de base de données, ne l’interrompez pas simplement pour accélérer le retour en arrière. Laissez la migration se terminer ou restaurez une sauvegarde connue comme compatible. Interrompre une modification du schéma crée un autre état d’échec, ce qui complique la vérification de la responsabilité de la version dans le problème initial.

Installez ou épinglez la version précédente sans modifier les autres variables

Ne modifiez que la version du serveur Plex. Conservez le même montage des données d’application, les mêmes chemins d’accès aux médias, le même mode réseau, les mêmes périphériques matériels et les mêmes paramètres client. Dans Docker, épinglez le tag de l’image précédente plutôt que de vous fier à un tag flottant ; pour les installations fondées sur des paquets, utilisez l’ancien installateur provenant d’une source fiable et adaptée à la plateforme.

La liste de contrôle de récupération d’un serveur domestique de ZimaSpace applique le même principe de récupération : préserver un état lisible, identifier la couche défaillante et éviter de remplacer ou de reconstruire d’abord le mauvais composant. Une rétrogradation de Plex doit être tout aussi ciblée.

Démarrez Plex et surveillez les journaux à la recherche d’erreurs de base de données avant de tester la lecture. Si l’ancienne version refuse la base de données ou démarre comme un nouveau serveur, arrêtez-vous immédiatement et restaurez l’état protégé plutôt que de la laisser écrire de nouveaux fichiers dans un répertoire de données incompatible.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Reproduisez la régression initiale avant de décider de rester sur l’ancienne version

Une fois l’ancienne version démarrée normalement, reproduisez exactement la condition qui échouait après la mise à jour : le même client, le même média, le même chemin réseau, la même action sur la bibliothèque ou la même tâche planifiée. Une rétrogradation ne prouve que la version était impliquée que si l’ancienne version réussit le déclencheur initial et que le reste du serveur demeure fonctionnel.

Redémarrez Plex une fois et répétez le déclencheur afin de vérifier que la récupération résiste à un cycle de fonctionnement normal. Vérifiez ensuite l’accès aux bibliothèques, l’historique de visionnage, l’accès à distance si vous l’utilisez et tout chemin de transcodage matériel que la mise à jour aurait pu modifier. Ne déclarez pas la réussite en vous basant uniquement sur l’écran d’accueil.

Si l’ancienne version échoue également, revenez à l’état actuel protégé et poursuivez le diagnostic au lieu d’empiler d’autres rétrogradations. Si l’ancienne version résout le problème, gardez la rétrogradation temporaire, documentez la version fonctionnelle et attendez une version ultérieure de Plex corrigeant la régression avant de mettre à nouveau le serveur à niveau.