Quelles données d’Immich doivent être conservées, et pourquoi les rôles de stockage sont-ils importants ?

La fiabilité d’Immich dépend de la conservation des originaux faisant autorité et de l’état persistant de l’application, tout en traitant les dérivés régénérables et les tâches temporaires comme des rôles de stockage distincts.

Placer chaque répertoire sur un seul volume peut fonctionner, mais cela masque les données qui doivent survivre à une reconstruction, celles qui peuvent être recréées et celles qui doivent rester indépendantes en tant que sauvegarde. Cette distinction influence davantage le temps de récupération, l’emplacement du stockage et la sécurité des opérations de nettoyage que les noms des répertoires eux-mêmes.

Les contenus multimédias originaux constituent le rôle de contenu irremplaçable

Les photos et vidéos importées sont les souvenirs de la famille que l’application existe pour préserver. Leur chemin de stockage peut varier selon le déploiement et les choix de modèles de stockage, mais leur rôle reste stable : ce sont des ressources sources, pas un cache, et leur perte ne peut pas être réparée en régénérant les miniatures ou les index de recherche.

Un aperçu actuel de l’auto-hébergement qui sépare l’emplacement des contenus multimédias et de la base de données est utile, car il présente le stockage comme une conception axée sur la fiabilité plutôt que comme un simple chiffre de capacité. Considérez ses recommandations matérielles comme des exemples, tout en conservant la distinction plus générale entre les originaux volumineux et l’état actif de l’application.

Ne classez pas un répertoire selon la facilité avec laquelle le conteneur peut être recréé. Les conteneurs et les images d’application sont remplaçables ; les contenus multimédias montés auxquels ils font référence peuvent ne pas l’être. Avant tout nettoyage ou toute migration, identifiez l’emplacement canonique des originaux et vérifiez qu’une copie indépendante existe.

PostgreSQL constitue le rôle des relations faisant autorité

La base de données conserve la compréhension qu’a l’application des utilisateurs, des ressources, des chemins, des albums, du partage, des métadonnées, des paramètres et de l’état lié à la recherche. Un dossier rempli de photos n’est donc pas équivalent à une instance Immich restaurée : le système de fichiers et la base de données décrivent des parties différentes de la même bibliothèque.

L’architecture du service rend cette dépendance visible en séparant PostgreSQL du stockage multimédia et du traitement en arrière-plan. Cette séparation explique pourquoi la latence de la base de données peut affecter l’interaction et pourquoi une sauvegarde des seuls contenus multimédias ne peut pas préserver toutes les relations de l’application.

La limite de défaillance est importante : un seul vidage de la base de données ne constitue pas non plus une sauvegarde des photos. Il peut restaurer les métadonnées et les relations uniquement lorsque les fichiers multimédias correspondants sont présents dans l’état logique attendu. Protégez les deux côtés et testez-les ensemble.

Les contenus multimédias générés échangent de l’espace de stockage contre une utilisation plus rapide

Les miniatures, les aperçus et les encodages vidéo compatibles existent pour rendre la navigation et la lecture pratiques sans retraiter constamment les originaux complets. Ils peuvent occuper un espace considérable, mais leur valeur pour la récupération diffère, car nombre d’entre eux peuvent être régénérés si les originaux et l’état requis de l’application survivent.

Un exemple de laboratoire domestique avec des rôles de stockage distincts montre pourquoi les opérateurs placent souvent le travail actif de la base de données et le stockage volumineux des photos sur des supports différents. L’idée n’est pas que chaque foyer ait besoin des mêmes disques, mais que les données générées à forte activité puissent avoir une politique de performances et de sauvegarde différente de celle des originaux.

Régénérable ne signifie pas gratuit. La reconstruction des dérivés pour une grande bibliothèque familiale peut consommer des heures ou des jours de processeur, d’entrées-sorties de stockage et de temps de file d’attente. Les exclure de la sauvegarde est une décision concernant le temps de récupération, et non la preuve qu’ils sont dépourvus de valeur opérationnelle.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Les files d’attente et les caches ne constituent pas une source de vérité durable

L’état des files d’attente et les caches aident le système en fonctionnement à coordonner et à accélérer les tâches, mais ils ne devraient pas devenir le seul endroit où existe un fait irremplaçable. Si une file d’attente temporaire disparaît après un redémarrage, l’état durable de la base de données et du système de fichiers devrait tout de même permettre à l’application de déterminer ce qui doit se passer ensuite.

L’article de ZimaSpace sur le chemin des données d’Immich est utile pour séparer l’état persistant des services qui acheminent les requêtes dans le système. Une file d’attente décrit le travail en cours ; elle ne doit pas être confondue avec les archives familiales elles-mêmes.

Ce modèle cesse d’être sûr si une intégration personnalisée stocke un état unique uniquement dans un chemin temporaire, une couche de conteneur non sauvegardée ou un emplacement auxiliaire non documenté. Répertoriez les montages personnalisés et les remplacements avant de supposer que les catégories de persistance par défaut couvrent l’intégralité du déploiement.

Construisez une matrice de récupération avant de déplacer le stockage

Répertoriez chaque rôle — originaux, profils, base de données, miniatures générées, vidéos encodées, cache de modèles, sauvegardes, configuration et bibliothèques externes éventuelles. Pour chacun, indiquez son chemin sur l’hôte, s’il fait autorité, s’il peut être régénéré, la perte maximale acceptable et le temps de restauration prévu.

Le guide de sauvegarde des photos familiales de ZimaSpace définit la bonne limite opérationnelle : un service familial utilisable nécessite des contenus multimédias protégés ainsi que l’état de l’application requis pour rendre ces contenus cohérents après une défaillance.

N’acceptez la conception de la persistance que lorsqu’un nouvel hôte peut restaurer des originaux représentatifs, les comptes et les relations, puis régénérer les dérivés volontairement exclus. Si la récupération dépend du souvenir d’un volume non documenté ou de la récupération d’une couche inscriptible de conteneur, les rôles de stockage ne sont pas encore définis de manière sûre.