Qu’est-ce que l’état d’Immich et quelles parties doivent être persistantes ?
L’état d’Immich regroupe les médias, la base de données, les identités, la configuration et les données dérivées nécessaires pour reproduire le comportement attendu de la bibliothèque.
Les fichiers originaux sont essentiels, mais ils ne constituent pas toute l’application. Les albums, les utilisateurs, les droits de propriété, les visages, les représentations utilisées pour la recherche, les mappages de chemins et les secrets déterminent la manière dont ces fichiers apparaissent et qui peut les utiliser ; certains font autorité, tandis que d’autres peuvent être reconstruits au prix d’un certain effort.
Les médias originaux et les relations de la base de données constituent le cœur du système
Les photos et vidéos originales préservent le contenu irremplaçable. La base de données conserve la manière dont Immich interprète ce contenu : utilisateurs, propriété, albums, identifiants des ressources, métadonnées et relations de traitement. L’un ou l’autre séparément est incomplet lorsque l’objectif est de restaurer le même service domestique, plutôt que de simplement récupérer des fichiers isolés.
Le guide de sauvegarde Immich de ZimaSpace explique qu’une protection complète inclut les médias importés et la base de données. Cette distinction fournit une définition utile de l’état : les médias indiquent quels octets existent, tandis que les enregistrements de la base de données indiquent comment l’application associe, présente et contrôle ces octets.
Mappez la base de données et chaque emplacement des médias originaux vers des chemins durables de l’hôte ou du système de stockage. Vérifiez que les bibliothèques externes sont protégées par leur propre politique. Ne déduisez pas la persistance d’un chemin interne de conteneur ; inspectez le volume effectif ou le montage bind qui subsiste après la suppression et la recréation du conteneur.
La configuration et les secrets recréent la frontière du service
Les définitions Compose, les paramètres d’environnement, les mappages de stockage, les règles du proxy et la configuration du fournisseur d’identité déterminent la manière dont les services trouvent les données et les autres services. Les mots de passe, les éléments de signature et les identifiants d’API doivent également être conservés de manière sécurisée. Reconstruire les fichiers sans ces paramètres peut rendre la base de données accessible avec la mauvaise identité ou via les mauvais chemins.
Une analyse de la planification du stockage d’Immich distingue l’emplacement de la base de données et des miniatures de celui du stockage en volume des originaux. Sa leçon est architecturale : un même service logique peut s’étendre sur plusieurs emplacements physiques ; l’inventaire de la persistance doit donc suivre chaque montage et chaque dépendance, plutôt qu’un seul répertoire de projet.
Stockez les définitions de déploiement dans un système de contrôle de version après en avoir retiré les secrets. Conservez les secrets dans une sauvegarde chiffrée ou un gestionnaire de secrets avec une procédure de restauration documentée. Notez le propriétaire et les permissions des montages bind. Lors d’un exercice, vérifiez l’accès du service à la base de données et la lecture des médias avant d’exposer l’accès à distance ou d’accepter de nouveaux imports.
Les données dérivées peuvent être reconstruites, mais restent importantes sur le plan opérationnel
Les miniatures, les vidéos encodées et certaines sorties d’apprentissage automatique peuvent être régénérées à partir des sources faisant autorité, selon la version et les enregistrements conservés. Les exclure peut réduire la taille des sauvegardes. Le compromis est un temps de reconstruction, une charge de calcul, de la chaleur et une réactivité réduite pendant qu’un serveur restauré reconstruit une grande bibliothèque familiale.
Un guide de sauvegarde indépendant distingue les données indispensables — imports, bibliothèque et profils — des miniatures et des vidéos encodées qu’Immich peut régénérer. Cela ne rend pas les données dérivées insignifiantes ; cela offre aux opérateurs un choix entre la taille de la sauvegarde et le temps nécessaire pour retrouver une navigation et une lecture entièrement préparées.
Mesurez un taux de reconstruction représentatif avant d’exclure les données dérivées. Multipliez prudemment ce taux par le type de ressources concernées et incluez les écritures de stockage ainsi que la concurrence avec les tâches au premier plan. Si le délai obtenu dépasse l’objectif de récupération, protégez certains chemins de données dérivées ou maintenez une capacité de calcul de secours pour la période de reconstruction.
Prouvez la persistance avec un exercice de destruction des conteneurs
Utilisez un clone jetable du déploiement, jamais la production. Enregistrez les sommes de contrôle d’un échantillon d’originaux, d’un album de test, de deux comptes disposant de droits différents et d’une recherche connue. Supprimez uniquement les conteneurs clonés tout en conservant le stockage persistant déclaré, puis recréez la pile à partir de la configuration et des secrets enregistrés.
Un rapport de la communauté sur la persistance décrit Immich revenant à l’assistant de configuration après des redémarrages parce que le répertoire de base de données prévu sur l’hôte restait vide. C’est un exemple qui rappelle qu’un chemin configuré ne prouve pas que les écritures y parviennent ; l’état observable doit survivre à l’opération réelle du cycle de vie concernée.
L’exercice n’est réussi que lorsque les deux comptes sont restaurés, que l’appartenance à l’album correspond, que les sommes de contrôle des originaux concordent et que la recherche connue fonctionne comme prévu ou passe dans un état de reconstruction documenté. Toute réinitialisation inexpliquée révèle une persistance manquante. Mettez à jour la cartographie de l’état avant de vous fier à une automatisation des sauvegardes fondée sur les mêmes hypothèses.
Produits recommandés
Centre Tech & IA
Plus à lire
Comment Immich gère-t-il l’authentification entre les sessions locales et distantes ?
Immich utilise une identité gérée côté serveur avec des sessions client, tandis que les en-têtes de proxy, les origines et les redirections OIDC peuvent...
Qu’est-ce qui ralentit les recherches ou les résultats de requêtes Immich à mesure que les données augmentent ?
La croissance d’Immich peut augmenter la taille des index, évincer les pages fréquemment utilisées, complexifier les filtres et retarder la diffusion des médias ;...
Pourquoi Immich se comporte-t-il différemment après le redémarrage d’un conteneur ?
Après un redémarrage d’Immich, une perte temporaire du cache est normale ; des problèmes persistants de connexion, de base de données ou de fichiers...
