Pourquoi Immich retraitе-t-il les données existantes après une mise à niveau ?

Immich peut retraiter les éléments existants lorsqu’une mise à niveau modifie le code, les modèles, les métadonnées ou les règles de dérivation qui définissent un résultat actuel.

Les photos originales n’ont pas changé, mais les vignettes, les représentations vectorielles, les visages, les aperçus ou les enregistrements de la base de données peuvent ne plus être conformes à la nouvelle version. L’explication qui suit précise quel résultat a été invalidé, quelle file d’attente le régénère et si l’opération s’effectue une seule fois ou se répète anormalement.

Une mise à niveau peut modifier la définition d’un résultat actuel

Les données générées sont valides par rapport au code, au modèle, aux paramètres et au schéma qui les ont produits. Lorsque ces attentes changent, une vignette, une représentation vectorielle, un résultat de reconnaissance faciale ou un enregistrement de métadonnées existant peut ne plus être considéré comme actuel. L’élément reste l’entrée, même si seule sa représentation dérivée doit être retraitée.

L’article de ZimaSpace sur la sauvegarde Immich distingue les originaux essentiels et l’état de la base de données des éléments dérivés qui peuvent être régénérés. Cette distinction explique pourquoi le travail lié à une mise à niveau peut être important sans signifier que les fichiers originaux ont été dupliqués : l’application peut reconstruire l’état dérivé autour de fichiers multimédias inchangés.

Notez quelles files d’attente augmentent immédiatement après la mise à niveau et quels répertoires ou tailles de bases de données évoluent. Une file de génération de vignettes, une file d’apprentissage automatique et une migration de base de données correspondent à des mécanismes différents. Les appeler toutes « réindexation » supprime les éléments nécessaires pour estimer la durée et la pression exercée sur les ressources.

Les changements de dépendances et de modèles peuvent invalider le travail précédent

Immich repose sur le code de l’application, le comportement de la base de données, la coordination des files d’attente, les modèles d’apprentissage automatique et les éléments multimédias dérivés. Une mise à niveau peut modifier les interfaces ou les attentes concernant la représentation stockée entre ces composants. Une migration peut mettre à jour rapidement les enregistrements, tandis que des processus en arrière-plan régénèrent ensuite des résultats coûteux pour chaque élément concerné.

Une discussion communautaire sur la préparation d’Immich v3 souligne les incertitudes concernant PostgreSQL, Redis, les extensions vectorielles et les versions de l’application. Cette discussion ne prouve aucune action de mise à niveau particulière, mais elle montre que la compatibilité des dépendances fait partie de la transition d’état plutôt que d’être un détail de maintenance sans rapport.

Conservez les versions des composants avant la mise à niveau ainsi qu’un instantané des files d’attente après celle-ci. Si une seule catégorie de résultats est planifiée et se termine une fois, le comportement correspond à une régénération limitée. Si les composants ne s’accordent pas sur le schéma ou les extensions, des échecs répétés peuvent survenir avant même que le retraitement utile ne commence.

Le retraitement transforme le travail de compatibilité en pression sur les ressources

Une photothèque importante peut transformer une seule règle modifiée en milliers de tâches. La génération de vignettes et l’analyse multimédia utilisent le processeur ou des accélérateurs, tandis que la lecture des originaux et l’écriture des éléments dérivés consomment de la bande passante de stockage. Les mises à jour de la base de données et l’activité des files d’attente se poursuivent simultanément ; la navigation au premier plan peut donc ralentir même lorsque le retraitement fonctionne correctement.

Un fil d’assistance Immich signale une forte charge processeur nocturne et une nouvelle génération de vignettes après une mise à jour sur deux serveurs. Il s’agit d’un retour de terrain et non d’une preuve du comportement attendu, mais il fournit exactement le schéma d’observation à confronter à la progression des files d’attente, aux journaux et à la récurrence des tâches une fois terminées.

Suivez le nombre d’éléments terminés par minute, l’espace de stockage disponible, la latence des appareils, la pression mémoire et une requête interactive fixe. Un retraitement sain doit réduire un retard fini. Réduire la concurrence peut préserver l’usage domestique au prix d’une durée plus longue ; ajouter des processus peut aggraver la contention du stockage ou de la base de données lorsque ces étapes fixent déjà la limite.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Distinguer une régénération ponctuelle d’un problème répétitif

Avant la mise à niveau, enregistrez le nombre de tâches, les versions, l’espace disponible et les identifiants de plusieurs éléments connus. Ensuite, échantillonnez ces mêmes identifiants et notez quel résultat est reconstruit, si le nombre d’éléments en file diminue et si le travail réapparaît après un redémarrage ou lors de la prochaine fenêtre de maintenance planifiée.

Une discussion sur la récupération des vignettes indique que des images manquantes sont réapparues une fois le traitement terminé, tandis qu’une actualisation manuelle a aidé certains éléments individuellement. Ces témoignages divergents renforcent la distinction : le temps écoulé ne suffit pas à classifier le comportement ; la progression d’une file finie diffère d’un échec répété sur les mêmes éléments ou de leur remise en file récurrente.

Considérez comme une régénération ponctuelle les files d’attente qui diminuent constamment avec des résultats stables. Faites remonter le problème lorsque le nombre d’éléments terminés revient à zéro, que les mêmes éléments réapparaissent, que les erreurs se répètent, que l’espace disponible s’effondre ou qu’aucun débit utile n’est observé. Conservez les sauvegardes et les journaux avant de modifier l’état des tâches, car la suppression des éléments de preuve peut empêcher de déterminer si la boucle a été déclenchée par la mise à niveau ou par l’environnement.