Pourquoi Immich perd-il l’accès aux données persistantes après la recréation de la stack ?

Lorsque Immich semble vide ou ne parvient pas à lire sa bibliothèque après la recréation de la pile, partez du principe que les anciennes données persistantes sont déconnectées ou illisibles avant de supposer qu’elles ont été supprimées.

La recréation des conteneurs peut modifier l’identité du projet Compose, la source d’un montage bind, l’association d’un volume nommé, le moment du montage d’un partage réseau ou l’UID/GID utilisé pour lire les données. Arrêtez l’instance qui semble neuve avant qu’elle n’écrive trop de nouvelles données, localisez sur l’hôte les anciens chemins de la base de données et des médias, puis comparez la pile recréée avec le dernier mappage fonctionnel connu. L’objectif est d’abord de reconnecter l’état existant ; ne restaurez depuis une sauvegarde qu’après avoir prouvé que cet état est réellement manquant ou endommagé.

Arrêtez l’instance neuve et vérifiez que les anciennes données existent toujours

Un assistant de configuration, une chronologie vide ou une bibliothèque externe manquante immédiatement après une recréation indiquent un problème de persistance. Arrêtez Immich et inspectez sur l’hôte les emplacements de l’ancienne base de données et des médias avant d’importer de nouveaux fichiers ou d’accepter une nouvelle configuration vide. De nouvelles écritures peuvent compliquer les comparaisons ultérieures des chemins.

Vérifiez dans les anciens répertoires le nombre de fichiers attendu, les dates de modification, les fichiers ou sauvegardes de la base de données ainsi que quelques images originales représentatives. Si les données sont présentes sur l’hôte, le problème concerne l’accès ou le mappage, et non leur disparition. Créez un instantané ou une sauvegarde en lecture seule de cet état avant de modifier les propriétaires ou de déplacer les répertoires.

Si les anciennes données sont introuvables aux emplacements attendus, recherchez-les dans le pool de stockage et dans l’inventaire des volumes Docker avant de supprimer quoi que ce soit. La décision est binaire : soit l’état existant est localisé et protégé, soit il est réellement indisponible et la procédure de récupération passe à une sauvegarde fiable plutôt qu’à la réparation des montages.

Comparez les montages recréés avec ceux de la pile précédente

Inspectez les montages effectifs des conteneurs du serveur et de la base de données Immich recréés, et pas seulement le texte Compose que vous vous souvenez avoir modifié. Un chemin de montage bind relatif peut être résolu depuis un autre répertoire de projet, et un projet Compose renommé peut associer un nouveau volume nommé tout en laissant l’ancien intact mais inutilisé.

Un montage défaillant, modifié ou manquant peut afficher un répertoire vide dans un conteneur alors que les données attendues existent toujours ailleurs sur l’hôte. Utilisez les vérifications des montages de volumes Docker pour comparer Source, Destination, le type de montage et l’identité du volume nommé pour chaque chemin persistant d’Immich. Un décalage à ce niveau explique directement l’apparence d’une instance neuve.

Corrigez uniquement le mappage de montage incorrect, puis créez ou démarrez le conteneur sans supprimer les volumes. Si les fichiers attendus apparaissent au même chemin dans le conteneur après la modification, laissez les données en place. Si la liste des montages est correcte mais que l’accès échoue toujours, conservez le mappage et examinez la disponibilité du stockage de l’hôte et les permissions plutôt que de créer un autre volume.

Vérifiez que le stockage externe était monté avant le démarrage d’Immich

Si les données d’Immich résident sur un pool de disques durs, un partage NAS, une couche de fusion ou un autre montage externe, vérifiez que ce stockage est réellement monté sur l’hôte avant de démarrer la pile Docker. Un chemin tel que /mnt/photos peut toujours exister en tant que répertoire local ordinaire alors que le périphérique réel est absent.

Les données Docker persistantes survivent au remplacement d’un conteneur uniquement lorsque le volume ou le montage bind prévu est correctement rattaché. Le modèle de persistance des volumes Docker sous-jacent ne fait pas apparaître automatiquement un disque hôte ou un partage réseau manquant. Vérifiez donc le périphérique de stockage et la présence d’un fichier connu sur l’hôte avant de tester le même chemin dans Immich.

Si vous découvrez que des fichiers de secours ont été écrits dans le point de montage vide alors que le stockage réel était absent, arrêtez Immich avant de monter le périphérique par-dessus. Traitez ces fichiers séparément, ajoutez une dépendance au démarrage ou une vérification d’état pour le montage de stockage, puis redémarrez la pile. Si le stockage de l’hôte est stable et que le chemin du conteneur reste illisible, passez à la branche des permissions.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez l’UID, le GID et les permissions des répertoires sans tout réécrire

Une pile recréée peut exécuter un service avec une identité numérique, un espace de noms utilisateur ou un contexte de sécurité différent de celui de l’ancienne pile. Le résultat diffère d’un montage manquant : le chemin existe et les fichiers sont visibles depuis l’hôte, mais les journaux d’Immich affichent des erreurs de permission ou Immich ne peut pas créer les fichiers attendus.

Comparez le propriétaire numérique et les bits de mode des répertoires concernés sur l’hôte avec l’identité utilisateur à l’intérieur du conteneur recréé. Commencez par tester une lecture sans risque, puis une écriture réversible dans un emplacement temporaire situé sous le même montage. Évitez de modifier récursivement le propriétaire de toute l’archive photo avant de savoir quel service doit disposer d’un accès en écriture et quels fichiers originaux doivent rester intacts.

Corrigez le plus petit décalage de répertoire ou d’identité qui explique l’échec, redémarrez une fois, puis vérifiez à nouveau les journaux. Si l’accès échoue toujours avec des montages et des permissions correspondants, cessez de modifier le système de fichiers et inspectez la connexion à la base de données, la substitution des variables d’environnement ou la couche de sécurité qui a changé lors de la recréation.

Reconnectez l’état original et validez une nouvelle recréation

Une fois les anciens chemins de la base de données et des médias rattachés et lisibles, démarrez Immich et recherchez les anciens utilisateurs, albums, personnes et éléments représentatifs. Ne considérez pas la réparation comme terminée simplement parce que la page d’accueil se charge ; vérifiez que l’application lit bien l’état original plutôt qu’une base de données nouvellement initialisée à côté.

Le principe important est que les conteneurs peuvent être jetables, tandis que l’état de l’application doit rester sur un stockage stable indépendant du cycle de vie des conteneurs. Documentez les noms de montages et les chemins hôte corrigés, et utilisez des rôles de stockage persistants sur serveur de fichiers afin que la prochaine recréation de la pile reste rattachée aux mêmes données.

Enfin, recréez une nouvelle fois la pile dans des conditions contrôlées et répétez les vérifications initiales. La correction n’est prouvée que si la même base de données et les mêmes médias réapparaissent après la recréation et après le redémarrage de l’hôte. Si l’ancien état disparaît à nouveau, ou si la base de données signale une corruption plutôt que des erreurs d’accès, revenez à la copie protégée et passez à une récupération de la base de données ou depuis une sauvegarde au lieu de poursuivre les expérimentations sur les montages.