Comment sauvegarder Plex sans capturer une base de données incohérente

Pour une sauvegarde complète des données de l’application Plex, arrêtez Plex avant de copier ou de prendre un instantané du système de fichiers ; pour la seule base de données principale, la sauvegarde planifiée de Plex constitue la méthode adaptée à l’application.

Plex écrit des bases de données, des métadonnées, des préférences et du cache pendant que le serveur fonctionne. Une tâche de sauvegarde générique peut donc capturer des fichiers à des moments différents. Cela ne signifie pas que toute sauvegarde à chaud est corrompue, mais qu’une copie brute est plus difficile à considérer comme fiable, sauf si l’application ou la couche de stockage coordonne la cohérence. Déterminez d’abord si vous avez besoin de la base de données principale de Plex ou de l’état complet du serveur, puis utilisez une méthode adaptée à cette portée et vérifiez une procédure de restauration avant de considérer la sauvegarde comme terminée.

Distinguez la sauvegarde de la base de données principale de la sauvegarde complète des données du serveur

Les tâches planifiées de Plex peuvent sauvegarder les bases de données principales qui contiennent l’état de visionnage et les informations de correspondance. C’est utile pour restaurer la base de données, mais Plex précise que cette sauvegarde ne remplace pas la sauvegarde de l’intégralité du répertoire de données de Plex Media Server. Considérez ces deux sauvegardes comme des outils de récupération distincts, au lieu de supposer qu’un seul fichier couvre tout.

La documentation de Plex sur les sauvegardes recommande de sauvegarder le répertoire principal de données du serveur et indique que le cache peut être exclu sur certaines plateformes. Définissez soigneusement l’ensemble à sauvegarder afin que le cache temporaire n’augmente pas inutilement la taille de l’archive, tout en protégeant les bases de données et les métadonnées essentielles.

Si votre objectif est de « restaurer le serveur exactement dans son état précédent », incluez l’arborescence persistante de données de l’application ainsi que les paramètres spécifiques à la plateforme requis par Plex. Si votre objectif est seulement de « récupérer l’état de visionnage et la base de données principale de la bibliothèque », la sauvegarde planifiée de la base de données peut constituer une solution de secours plus légère et ciblée.

Mettez Plex en pause avant une copie brute du système de fichiers

Pour une simple sauvegarde au niveau des fichiers, arrêtez le conteneur Plex et vérifiez qu’il a bien terminé son arrêt avant de copier ou de prendre un instantané du chemin de données persistant. Réduisez la durée d’interruption : arrêtez le service, capturez un état cohérent, redémarrez-le, puis laissez la copie plus lente vers un autre hôte se poursuivre depuis l’instantané si votre système de fichiers prend en charge ce flux de travail.

La documentation de l’API de sauvegarde de SQLite montre pourquoi la copie à chaud d’une base de données est un problème de coordination, et pas seulement de taille de fichier. Une sauvegarde adaptée à l’application ou un instantané pris après mise en pause fournit un état défini de la base de données : copier aveuglément des fichiers de base de données, WAL et métadonnées qui changent laisse davantage d’incertitude quant au point de récupération.

N’arrêtez pas Plex pendant des heures le temps qu’une grosse sauvegarde parcoure un stockage lent si votre NAS peut créer un instantané instantané. La méthode la plus sûre consiste à interrompre brièvement les écritures pour établir la cohérence, puis à lancer un instantané ou une procédure d’archivage qui permet au service de redémarrer pendant que la sauvegarde est transférée ailleurs.

Appliquez des règles de récupération distinctes aux journaux, au cache et aux données persistantes

Le cache et les journaux détaillés peuvent changer rapidement et n’ont généralement pas besoin de la même durée de conservation que la base de données et les métadonnées de Plex. La séparation de ces chemins réduit la taille des sauvegardes et clarifie la limite de restauration. Elle empêche également un arbre de journaux ou de cache volumineux de consommer l’espace réservé à l’état de l’application.

Le guide de ZimaSpace sur la séparation des journaux des conteneurs et des données des applications explique pourquoi l’état de l’application, les journaux et le cache ont des cycles de vie et des exigences de récupération différents. Plex bénéficie de la même politique, même si les trois éléments sont initialement définis dans une seule configuration de conteneur.

Si vous modifiez la portée de la sauvegarde, effectuez un test de restauration sur une copie destinée à être supprimée ou dans un conteneur isolé. Une politique de sauvegarde n’est pas validée par un simple téléversement réussi : elle l’est lorsque Plex peut ouvrir la base de données et les métadonnées récupérées avec l’état attendu du serveur.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez la sauvegarde en restaurant un état connu

Choisissez un petit ensemble d’éléments vérifiables après une restauration : le nom du serveur, une bibliothèque, un élément regardé, un élément partiellement regardé et un paramètre que vous connaissez. Un test de restauration doit récupérer ces éléments sans demander à Plex de créer un nouveau serveur ni de reconstruire la bibliothèque à partir des fichiers multimédias.

Plex documente une procédure de restauration de base de données qui commence par l’arrêt du serveur et le remplacement de la base de données active par une sauvegarde. Même si votre méthode de sauvegarde complète est différente, la règle consistant à arrêter le serveur avant de remplacer la base de données constitue une bonne pratique de récupération.

Si le test de restauration échoue, corrigez la méthode de sauvegarde avant d’augmenter la durée de conservation ou d’automatiser davantage de copies. Ne recourez à la réparation de la base de données que lorsqu’une sauvegarde connue comme fiable ne peut pas être restaurée ; n’écrasez pas la dernière copie récupérable pendant que vous expérimentez sur une base de données active endommagée.