Comment tester l’acceptation d’un nouveau serveur Plex avant d’y transférer les données de production

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les laboratoires informatiques personnels et les logiciels open source, elle se spécialise dans la vulgarisation de concepts techniques complexes au moyen de guides pratiques et concrets. Eva pense que l’hébergement personnel doit être amusant, et non intimidant. À travers ses tutoriels, elle aide la communauté à démystifier les configurations matérielles, de la construction de leur premier NAS à la maîtrise des conteneurs Docker.

Ne transférez les données Plex de production qu’après la réussite d’un test de validation à froid confirmant que l’état, les chemins, les utilisateurs, la lecture et la récupération fonctionnent sur le nouvel hôte.

Laissez l’ancien serveur arrêté et n’y touchez pas pendant que vous testez le nouvel hôte dans le cadre du même usage domestique. La dépendance clé n’est pas une connexion réussie, mais un chemin reproductible allant du montage du stockage à la base de données de la bibliothèque, puis à la lecture sur un client. Traitez l’accès à distance comme un critère distinct et conservez une copie de secours jusqu’à ce qu’une nouvelle sauvegarde ait été localisée et testée.

Geler l’ancien serveur et définir les critères de validation

Commencez avec l’ancien hôte arrêté, une sauvegarde de ses données d’application et une liste écrite des bibliothèques, des utilisateurs, des clients distants et des tâches planifiées. Cela évite que deux identités de serveur modifient le même flux de travail pendant que vous comparez les résultats. Un autre guide de migration recommande également de conserver une copie de secours pendant le transfert de la bibliothèque et des métadonnées (Guide de migration de bibliothèque Plex). Ne passez à l’étape suivante que lorsque vous pouvez indiquer l’emplacement des anciennes données, celui des nouvelles et la procédure de restauration.

Valider les chemins de stockage, les droits de propriété et l’état de l’application

Pour chaque bibliothèque, ouvrez le chemin depuis l’hôte Plex, et non depuis un navigateur de fichiers sur votre poste de travail. Vérifiez que le montage est présent après le redémarrage, que le compte de service peut lire les fichiers multimédias et que le répertoire des données de l’application est accessible en écriture et persistant. Testez un fichier de chaque emplacement de stockage. Considérez l’état du système, la base de données Plex, les fichiers multimédias irremplaçables, les vignettes recréables et les copies de sauvegarde comme des rôles de données distincts : la redondance ne constitue pas une sauvegarde.

Une migration qui ne fonctionne que parce qu’un montage a été effectué manuellement est un échec. La décision est PASS lorsque toutes les bibliothèques sont accessibles depuis le contexte du service et que la base de données résiste au redémarrage du service sans qu’une nouvelle analyse détruise son état.

Tester la lecture sur l’ensemble réel des clients

Utilisez une petite matrice plutôt qu’un seul film lu avec succès : un fichier en lecture directe, un fichier habituellement transcodé, un contenu avec de nombreux sous-titres, une session à distance si le visionnage à distance fait partie du flux de travail et un compte dont l’accès à la bibliothèque est limité. Consignez l’heure de démarrage, le mode de lecture, le comportement audio et des sous-titres, et si l’utilisateur concerné voit bien la bibliothèque attendue. Le nouveau serveur n’est pas prêt si la lecture ne fonctionne qu’avec le compte administrateur ou uniquement sur le réseau local.

Effectuer les vérifications de redémarrage à froid et de retour arrière

Arrêtez Plex proprement, redémarrez l’hôte, attendez que le stockage et les montages réseau soient disponibles, puis répétez les vérifications de lecture représentative et d’accès des utilisateurs. Créez une nouvelle sauvegarde des données de l’application après le redémarrage et vérifiez où elle peut être restaurée. Une procédure pratique de déplacement des métadonnées consiste également à conserver l’ancien répertoire sous un autre nom jusqu’à ce que le nouvel emplacement soit confirmé (pratique de retour arrière des métadonnées).

Ne mettez l’ancien hôte hors service que lorsque tous les critères sont satisfaits deux fois : état et chemins, lecture représentative, utilisateurs concernés, redémarrage à froid et emplacement de la sauvegarde. Si un critère échoue, réparez le nouvel hôte tout en gardant l’ancienne copie disponible ; n’élargissez pas le changement en supprimant la cible de retour arrière.

Définir un seuil d’arrêt mesurable

Arrêtez la migration lorsque le nouvel hôte a satisfait à la matrice de validation et que le prochain déclencheur d’extension est connu, par exemple davantage de transcodages simultanés ou un niveau de stockage devenu insuffisant. Gardez l’ancien hôte tant que les autorisations, la persistance des montages, le routage à distance ou la restauration n’ont pas été vérifiés. La migration la plus économique et la plus sûre est celle qui conserve une voie de récupération connue.

Configuration de NAS et de serveur

À lire aussi

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.