Comment vérifier une restauration Jellyfin avant de mettre l’ancien serveur hors service

Ne mettez pas l’ancien serveur Jellyfin hors service tant qu’une restauration propre n’a pas reproduit les utilisateurs, les chemins, la lecture, les permissions et le comportement au redémarrage requis.

La nouvelle instance se contente-t-elle d’ouvrir son tableau de bord, ou a-t-elle résisté à la même charge de clients et de stockage que l’ancien hôte ? Gardez l’ancien serveur arrêté et récupérable pendant vos tests. Une connexion réussie n’est que le premier signal : la restauration doit confirmer l’état et les chemins de données réellement utilisés par le foyer.

Vérifiez l’état persistant avant la lecture

Vérifiez que la configuration et la base de données restaurées contiennent les utilisateurs, bibliothèques, états de visionnage, plugins et permissions attendus. Contrôlez chaque chemin de bibliothèque depuis le contexte du service Jellyfin et lisez un fichier d’exemple dans chaque emplacement de stockage. Des montages manquants ou un propriétaire incorrect peuvent rester invisibles jusqu’à une analyse ou une demande de lecture.

Notez ce qui a été volontairement recréé, comme le cache ou les illustrations téléchargées, afin de ne pas confondre une différence avec un échec de restauration. Conservez la sauvegarde et l’ancienne copie des données de l’application inchangées jusqu’à l’étape suivante.

Comparez le nombre d’éléments restaurés et un enregistrement connu de l’état de visionnage avec le dernier inventaire de l’ancien serveur. Le démarrage réussi de la base de données ne prouve pas que chaque chemin multimédia ou permission utilisateur a été préservé.

Exécutez la charge de travail d’origine des clients

Testez une lecture directe locale, un transcodage forcé, les sous-titres, l’accès distant s’il est utilisé et un compte utilisateur restreint. Comparez le mode de lecture, l’audio, le rendu des sous-titres, la visibilité des bibliothèques et le temps de démarrage avec le comportement connu de l’ancien serveur.

Si un seul client échoue, isolez sa capacité ou son chemin avant de modifier l’ensemble de la restauration. Le parcours de migration est utile comme liste de contrôle, mais la décision d’acceptation doit reposer sur votre propre charge de travail domestique.

Répétez une session après avoir laissé le service fonctionner assez longtemps pour terminer ses tâches normales de démarrage. Cela permet de détecter les problèmes différés de montage, de plugin ou de métadonnées qu’une connexion rapide ne révèle pas.

Franchissez les étapes de redémarrage à froid et de récupération

Arrêtez Jellyfin, redémarrez l’hôte, attendez les montages de stockage et les services réseau, puis répétez les mêmes tests clients. Créez ou localisez une nouvelle sauvegarde de l’état restauré. Effectuez ensuite un second test de restauration ou vérifiez au minimum que la sauvegarde contient le répertoire de données exact et les permissions nécessaires à la récupération.

Ne mettez l’ancien serveur hors service que lorsque l’hôte restauré a réussi deux fois les vérifications de l’état, des chemins, des utilisateurs, de la lecture, du redémarrage à froid et de l’emplacement de sauvegarde. Arrêtez-vous et revenez en arrière lorsque la base de données ne peut pas être ouverte, que la charge de travail d’origine des clients échoue ou que la copie de récupération n’est pas lisible indépendamment.

Notez le point de restauration exact, le propriétaire des fichiers et la correspondance des chemins qui ont réussi. Ces informations deviennent la procédure de récupération si le nouvel hôte tombe en panne pendant la période de mise hors service.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Clôturez la période de mise hors service en toute sécurité

Laissez l’ancien serveur arrêté mais récupérable jusqu’à ce que l’hôte restauré réussisse un deuxième test de démarrage à froid et qu’une nouvelle sauvegarde puisse être localisée indépendamment.

Ne mettez l’ancien hôte hors service qu’après la réussite de la lecture locale, de la lecture distante si nécessaire, de l’accès utilisateur, des analyses de bibliothèques et de la documentation de restauration. Conservez les anciennes données de l’application jusqu’à la fin de la période de conservation.

Arrêtez-vous et revenez en arrière lorsqu’un client requis échoue, que la base de données restaurée change de manière inattendue ou que la sauvegarde ne peut pas reproduire l’état testé.