Comment configurer le cache et le stockage temporaire d’Immich
Configurez le cache et le stockage temporaire d’Immich en séparant d’abord l’état durable de la bibliothèque, les dérivés générés, le cache de modèles réutilisable et les données de travail réellement jetables des conteneurs.
Les miniatures et les vidéos encodées peuvent sembler être du cache, car Immich peut les régénérer, mais ce sont des ressources de travail persistantes qui peuvent devenir volumineuses et coûteuses à recréer. Les téléchargements de modèles suivent un autre cycle de vie, tandis que les journaux et les données temporaires de la couche inscriptible ne doivent pas remplir discrètement le disque de démarrage. Attribuez un stockage à chaque rôle, puis testez le nettoyage et le comportement après redémarrage.
Classez chaque rôle de stockage avant de le déplacer
Créez un inventaire comprenant au moins quatre catégories : les originaux et l’état requis de l’application ; les miniatures et aperçus générés ; les vidéos encodées générées ; et les données de modèles, de journaux ou d’exécution temporaire. Pour chaque catégorie, notez le chemin actuel, la taille, le rythme de croissance, la politique de sauvegarde, le coût de reconstruction et le service qui y écrit.
Un rapport utilisateur sur la croissance des miniatures et vidéos générées montre pourquoi les miniatures et les vidéos encodées doivent être mesurées séparément. Les proportions individuelles ne sont pas universelles, car le type de médias et les paramètres de traitement modifient la quantité produite.
Ne qualifiez pas un répertoire de « cache » simplement parce que sa suppression libère de l’espace. Si sa perte entraîne plusieurs jours de régénération, interrompt la lecture active ou supprime un état que votre plan de récupération prévoit de conserver, attribuez-lui explicitement un rôle persistant, même si l’application peut techniquement le recréer.
Placez les données générées à forte activité là où la latence et l’endurance sont adaptées
Les miniatures et les aperçus servent à la navigation interactive et impliquent souvent de nombreuses petites lectures, tandis que les vidéos encodées peuvent consommer une capacité séquentielle bien plus importante. Un SSD rapide peut améliorer les activités dépendantes des dérivés, mais uniquement si le déplacement de ce rôle élimine l’attente mesurée au lieu de créer un autre petit volume qui se remplit de manière imprévisible.
L’explication de ZimaSpace sur la croissance du stockage des miniatures fournit une leçon de stockage transposable : le stockage actif de l’application peut se remplir même lorsque les originaux se trouvent ailleurs. Les chemins propres à Immich diffèrent, mais la nécessité de surveiller le rôle réellement inscriptible reste la même.
Si les médias volumineux restent sur un disque dur ou un stockage NAS tandis que les dérivés sont déplacés vers un SSD, surveillez les seuils d’espace libre des deux emplacements et vérifiez chaque point de montage après un redémarrage. Un niveau de dérivés rapide n’est utile que s’il est suffisamment grand pour la croissance normale et que sa défaillance ne peut pas être confondue avec la perte des originaux de référence.
Conservez délibérément le cache des modèles, mais considérez-le comme reconstructible
Les modèles d’apprentissage automatique sont téléchargés ou préparés pour des inférences répétées et peuvent consommer un espace important. La conservation du cache des modèles évite les téléchargements et le travail de démarrage inutiles, en particulier avec des connexions lentes, mais ce cache ne doit pas être confondu avec la base de données ou les originaux familiaux dans la hiérarchie de récupération.
Une discussion communautaire sur l’architecture de stockage d’Immich montre pourquoi les opérateurs séparent les données rapides assimilables à un cache du stockage volumineux des photos. Utilisez ces configurations uniquement comme exemples ; vérifiez les chemins et les points de montage actuels dans votre propre définition Compose avant de déplacer quoi que ce soit.
Si le cache des modèles est perdu, la récupération acceptable consiste généralement à le recréer ou à le télécharger à nouveau, à condition que le service puisse accéder à la source requise et dispose de suffisamment d’espace disque. Documentez ce comportement afin qu’un outil de sauvegarde ne consacre pas accidentellement une capacité hors site limitée à la protection d’un cache volumineux et régénérable.
Limitez les couches inscriptibles, les journaux et l’espace de travail temporaire
Les couches inscriptibles des conteneurs ne doivent pas devenir un emplacement non documenté pour les dérivés persistants, les transcodages temporaires ou les journaux volumineux. Inspectez l’utilisation du disque Docker et les points de montage des conteneurs afin que chaque chemin volumineux en croissance soit soit conservé délibérément, soit supprimable intentionnellement. Une hausse inexpliquée de la couche inscriptible est un symptôme de configuration, pas une cible de nettoyage par défaut.
Le processus Docker HQ de 2026 pour nettoyer le disque Docker en toute sécurité met l’accent sur l’audit avant le nettoyage et sur la protection des volumes susceptibles de contenir des bases de données. Appliquez cette prudence ici : n’exécutez jamais de commandes de nettoyage globales sur un hôte Immich de production tant que la propriété de chaque volume et de chaque couche n’est pas connue.
Configurez la rotation des journaux, placez les chemins de travail temporaire sur un stockage disposant d’une marge suffisante pour les pointes d’activité et surveillez les inodes aussi bien que l’espace en octets lorsque de nombreux petits fichiers sont créés. Si un chemin temporaire est saturé, la bonne solution consiste à limiter ou à déplacer ce rôle, et non à supprimer des répertoires inconnus jusqu’à ce que l’application démarre par hasard.
Validez les changements de stockage avec des tests de redémarrage, de reconstruction et d’espace libre
Après avoir modifié les chemins, ouvrez des ressources anciennes et récentes, parcourez plusieurs albums, lisez une vidéo, exécutez une tâche de miniature ou d’apprentissage automatique et importez un nouveau fichier contrôlé. Confirmez que les écritures aboutissent sur les appareils prévus et que la base de données référence toujours des médias lisibles.
Redémarrez les conteneurs, puis l’hôte. Une configuration fonctionnelle remonte automatiquement chaque rôle, conserve les dérivés et le cache de modèles attendus, garde les données de travail temporaires supprimables et indique suffisamment d’espace libre sur chaque niveau actif. Surveillez le stockage pendant une période de charge normale afin de confirmer que la croissance se produit aux emplacements prévus.
Annulez la modification d’un chemin si Immich crée des répertoires en double, signale des ressources manquantes ou écrit silencieusement dans la couche du conteneur parce qu’un point de montage a échoué. Lors de l’escalade, fournissez la cartographie des montages, la taille des chemins, les propriétaires, l’espace libre du système de fichiers, l’utilisation du disque des conteneurs et la tâche exacte qui a écrit en premier au mauvais emplacement.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
