Immich peut consommer bien plus d’espace que le disque système de ZimaOS n’est conçu pour en fournir, en particulier lorsque les téléversements depuis les téléphones, les miniatures, les vidéos encodées, les modèles d’apprentissage automatique et la base de données PostgreSQL commencent à prendre de l’ampleur. Le guide original de la communauté IceWhale a résolu ce problème en avril 2025 en modifiant certains mappages de volumes lors d’une installation personnalisée de ZimaOS, afin que les données d’Immich résident sur un volume RAID plutôt que sur le disque de ZimaOS.
Cette solution de contournement est utile pour comprendre la manière dont le conteneur est configuré, mais elle ne doit pas être considérée comme une procédure universelle à appliquer aujourd’hui. Des réponses ultérieures ont fait état d’installations échouées, de redémarrages répétés, d’un conteneur PostgreSQL défaillant et même de téléversements de photos corrompus après des essais de modification des mappages. ZimaOS a également ajouté et amélioré ses outils de migration intégrés, tandis que les versions actuelles de Docker Compose pour Immich utilisent des variables côté hôte telles que UPLOAD_LOCATION et DB_DATA_LOCATION. Sur un système actuel, utilisez d’abord le chemin de migration intégré de ZimaOS s’il correspond à votre objectif, et réservez la modification manuelle des volumes aux cas où vous avez spécifiquement besoin d’une configuration de stockage Immich personnalisée.
Ce que le guide ZimaOS Immich original de 2025 a modifié
Le tutoriel de la communauté utilisait l’installation personnalisée de ZimaOS ou l’écran des paramètres de l’application après son installation, et parcourait les onglets du service un par un. Son objectif était de rediriger les données persistantes d’Immich vers un emplacement RAID de plus grande capacité, tout en conservant les chemins côté conteneur attendus par Immich.
Base de données : déplacez le chemin hôte, conservez le chemin du conteneur
Dans l’onglet de la base de données, l’auteur a modifié l’emplacement de stockage côté ZimaOS pour utiliser un chemin RAID, tout en conservant le suffixe du répertoire de la base de données. Le principe important était de ne pas réécrire le chemin de droite à l’intérieur du conteneur. Modifier la destination dans le conteneur peut interrompre le service, car PostgreSQL attend ses données à l’emplacement défini par le paquet Immich ou la configuration Compose.
La documentation actuelle de Docker Compose pour Immich expose cet emplacement sur l’hôte via DB_DATA_LOCATION. Immich avertit également que les partages réseau ne sont pas pris en charge pour la base de données PostgreSQL. La base de données doit donc rester sur un stockage local fiable et directement connecté, plutôt que sur un partage SMB ou NFS.
Apprentissage automatique : ne redirigez le cache des modèles que si nécessaire
Le guide d’origine redirigeait également le cache des modèles d’apprentissage automatique côté hôte, tout en laissant inchangé le chemin du cache côté conteneur. Le déplacement de ce cache peut libérer de l’espace sur un petit disque système, même s’il est moins important que la protection de la photothèque et de la base de données, car les modèles téléchargés peuvent généralement être recréés.
Serveur Immich : la section des volumes la plus sensible
L’onglet du serveur Immich est la partie que l’auteur a trouvée la plus facile à dérégler. Des mappages d’hôtes supplémentaires ont été ajoutés afin que les téléversements et autres répertoires de médias persistants soient dirigés vers le stockage RAID. La discussion souligne à plusieurs reprises qu’il faut modifier uniquement les emplacements côté hôte prévus et ne pas changer inconsidérément les chemins côté conteneur.
L’onglet Redis ne nécessitait aucune modification du stockage dans le guide d’origine. C’est une autre raison de ne pas appliquer un remplacement global à chaque entrée de volume : les différents services Immich ont des exigences de persistance différentes.
Utilisez d’abord la migration des données de ZimaOS sur les systèmes actuels
La mise à jour la plus importante de la discussion ultérieure est que ZimaOS propose désormais une procédure de migration dédiée. Une réponse de l’équipe IceWhale dans le fil avertissait précisément que la copie manuelle des données des applications peut provoquer des erreurs et recommandait d’utiliser la fonction de migration dans la plupart des cas.
Le guide actuel sur la migration des données de ZimaOS répertorie trois catégories de stockage déplaçables : les images Docker, les données des applications Docker et les bases de données utilisateur. La procédure normale est la suivante :
- Ouvrez Paramètres > Migration des données.
- Sélectionnez la catégorie de stockage que vous souhaitez déplacer.
- Choisissez Modifier l’emplacement.
- Sélectionnez le disque de destination ou l’espace de stockage.
- Consultez l’avertissement, démarrez la migration, puis attendez le rapport de fin.
Cette migration intégrée constitue le meilleur point de départ si votre objectif est simplement de conserver les données des applications Docker à l’écart du disque système ZimaOS. Elle réduit également le risque de laisser des chemins, des autorisations ou des liens symboliques incohérents après un déplacement manuel.
Que faire si vous voulez Immich sur le SSD, mais les photos sur le RAID ?
Une question ultérieure dans le fil a soulevé une disposition plus pertinente à long terme : conserver l’application et les composants sensibles aux performances sur un SSD, mais placer la grande photothèque sur un RAID. L’auteur d’origine n’avait pas testé cette configuration séparée ; le fil ne fournit donc pas de recette ZimaOS vérifiée pour celle-ci.
La documentation actuelle d’Immich présente bien deux concepts qui permettent de définir la bonne disposition. Pour les fichiers multimédias téléversés dans Immich, la configuration Docker Compose officielle utilise UPLOAD_LOCATION comme chemin hôte pour le stockage des fichiers multimédias. Pour une collection existante de photos qu’Immich doit indexer sans l’importer dans son espace de téléversement géré, Immich prend en charge les bibliothèques externes.
Dans un déploiement Immich standard basé sur la version actuelle de Compose, les valeurs d’environnement pertinentes se présentent conceptuellement ainsi :
UPLOAD_LOCATION=/path/to/large-media-storage
DB_DATA_LOCATION=/path/to/local-database-storageNe collez pas aveuglément ces chemins dans une ancienne définition d’application ZimaOS. Commencez par examiner la configuration Compose ou d’installation personnalisée utilisée par le paquet Immich exact que vous avez installé. Le fichier Compose officiel actuel d’Immich monte ${UPLOAD_LOCATION} dans le conteneur du serveur et ${DB_DATA_LOCATION} dans PostgreSQL, tandis que les anciennes versions et les paquets communautaires peuvent utiliser d’autres destinations internes.
Pour connaître les informations officielles à jour, consultez le guide d’installation d’Immich avec Docker Compose et le guide des bibliothèques externes d’Immich.
Pourquoi la modification manuelle des volumes peut interrompre Immich
Les réponses montrent plusieurs modes de défaillance après la modification des mappages de stockage. Un participant a d’abord signalé que l’application ne fonctionnait plus, puis a indiqué qu’elle s’était remise à fonctionner après plusieurs redémarrages. Un autre utilisateur a déclaré que des expérimentations répétées avaient endommagé Immich et que certaines importations depuis un téléphone étaient devenues corrompues. Un signalement ultérieur décrivait plusieurs échecs d’installation liés à un service PostgreSQL défaillant.
Ces signalements ne prouvent pas l’existence d’un bug unique et partagé. Ils montrent toutefois pourquoi une migration de stockage doit être traitée comme une opération d’intégrité des données, et non comme un simple changement esthétique de chemin. Parmi les causes courantes à vérifier, citons :
- Mauvaise destination dans le conteneur : le chemin hôte peut être personnalisé, mais le chemin à l’intérieur du conteneur doit correspondre à celui attendu par votre déploiement d’Immich.
- Autorisations : la destination doit être accessible en écriture pour l’utilisateur du conteneur ou le service qui possède les fichiers.
- Emplacement de la base de données : PostgreSQL nécessite un stockage local fiable et ne doit pas être placé sur un partage réseau non pris en charge.
- Déplacements incomplets : copier manuellement seulement une partie d’une arborescence de données Immich existante peut désynchroniser la base de données et le stockage multimédia.
- Incompatibilité de versions : la configuration des volumes d’Immich a évolué ; les instructions rédigées pour un ancien paquet peuvent donc ne pas correspondre à Immich v2, v3 ou à une définition ultérieure de l’App Store ZimaOS.
Checklist pour une migration plus sûre du stockage d’Immich
- Sauvegardez la base de données Immich et les fichiers multimédias irremplaçables avant de modifier un mappage de volume.
- Confirmez la version d’Immich et le paquet de l’App Store ZimaOS que vous utilisez.
- Déterminez si vous souhaitez déplacer toutes les données des applications ou uniquement la volumineuse bibliothèque multimédia.
- Si vous déplacez les données générales des applications ZimaOS, essayez d’abord Settings > Data Migration avant de modifier les chemins des conteneurs individuellement.
- Si vous utilisez une configuration Immich personnalisée, notez chaque chemin hôte existant et chaque destination dans le conteneur avant d’effectuer toute modification.
- Ne modifiez pas les chemins côté conteneur, sauf si la documentation correspondant exactement à votre version d’Immich l’exige explicitement.
- Assurez-vous que le système de fichiers de destination est monté et accessible en écriture avant de recréer les conteneurs.
- Ne placez pas le répertoire de données PostgreSQL sur un partage réseau non pris en charge.
- Après la migration, importez un petit échantillon de test et vérifiez les originaux, les miniatures, la lecture des vidéos, les métadonnées et les nouveaux téléversements mobiles avant de déplacer le reste de votre bibliothèque.
- Conservez l’ancienne copie jusqu’à ce que vous ayez vérifié la base de données et les fichiers multimédias sur le nouveau stockage.
Ce que les réponses de la communauté ont ajouté au guide original
Les réponses les plus utiles ont modifié l’interprétation du tutoriel original de trois façons. Premièrement, elles ont montré que le mappage manuel pouvait fonctionner, mais qu’il dépendait de la version exacte de l’application, des autorisations de stockage et de l’état après redémarrage. Deuxièmement, les utilisateurs souhaitaient une configuration SSD + RAID distincte, plutôt que de déplacer tous les composants d’Immich vers le même ensemble RAID. Troisièmement, un membre de l’équipe IceWhale a recommandé d’utiliser la fonction de migration intégrée et a averti que la copie manuelle pouvait entraîner des erreurs.
Cela signifie qu’il vaut mieux comprendre la publication originale de 2025 comme un exemple communautaire fonctionnel pour son époque, et non comme une spécification figée applicable à toutes les versions ultérieures d’Immich ou de ZimaOS. Si votre interface ZimaOS actuelle n’affiche plus les mêmes champs d’installation personnalisée que ceux présentés dans les captures d’écran, suivez l’interface actuelle de migration et examinez la configuration Compose de l’application installée plutôt que d’essayer de recréer les anciens champs.
FAQ sur le stockage d’Immich dans ZimaOS
Puis-je installer Immich sur un disque RAID plutôt que sur le disque système de ZimaOS ?
Oui, mais faites la distinction entre le déplacement des données d’application de ZimaOS et la conception d’une structure multimédia Immich personnalisée. Dans les versions actuelles de ZimaOS, utilisez d’abord la fonction intégrée de migration des données si votre objectif est de déplacer les données des applications Docker. Les mappages de volumes manuels doivent plutôt être réservés à une conception délibérée avec stockage séparé.
Dois-je modifier le chemin du volume Immich à droite dans l’installation personnalisée ?
Pas à moins que la documentation correspondant exactement à votre déploiement d’Immich ne vous l’indique. Le guide communautaire d’origine modifiait les emplacements côté hôte tout en conservant les destinations côté conteneur. Réécrire une destination interne peut empêcher le service de trouver les répertoires attendus de la base de données, du cache ou des fichiers multimédias.
Puis-je conserver Immich sur le SSD et stocker uniquement les photos sur le RAID ?
Oui, en principe, et la version actuelle d’Immich permet de choisir un emplacement d’importation sur l’hôte ainsi que de monter des bibliothèques externes. Le mappage exact dans ZimaOS dépend du paquet et de la version d’Immich installés ; vérifiez donc la définition Compose actuelle avant de modifier les chemins.
Pourquoi PostgreSQL devient-il défaillant après le changement d’emplacement du stockage ?
Les causes possibles incluent une destination de montage incorrecte, des autorisations manquantes, des fichiers de base de données incomplets ou un stockage non pris en charge. Vérifiez que l’intégralité du répertoire de la base de données a été correctement déplacée, que la destination est locale et accessible en écriture, et que la destination du conteneur correspond toujours à la configuration Compose installée.
Puis-je simplement copier le dossier AppData d’Immich vers un autre disque ?
Ce n’est pas la méthode actuellement recommandée dans ZimaOS. Un membre de l’équipe IceWhale a spécifiquement averti dans le fil de discussion que la copie manuelle pouvait provoquer des erreurs et a recommandé la fonction de migration pour la plupart des déplacements d’applications.
Le guide illustré d’avril 2025 est-il toujours à jour ?
Cela reste utile comme explication historique des mappages de volumes de ZimaOS, mais les fonctionnalités de migration de ZimaOS et la structure Compose d’Immich ont changé depuis. Considérez les captures d’écran comme une référence de la configuration d’origine, puis vérifiez les champs et les chemins affichés par votre installation actuelle avant d’appliquer toute modification.
