Quand faut-il reconstruire plutôt que réparer une installation d’Immich ?

Réparez Immich lorsque la panne est localisée et que les données persistantes sont manifestement intactes ; reconstruisez l’environnement d’exécution lorsque la dérive de configuration est étendue, mais qu’une base de données vérifiée, une bibliothèque multimédia, une définition de déploiement et une copie de restauration peuvent recréer le service en toute sécurité.

Reconstruire ne signifie pas tout supprimer. Les conteneurs et les réseaux sont remplaçables, tandis que la base de données et les originaux constituent l’historique de la bibliothèque. Commencez par évaluer l’intégrité, l’étendue et la reproductibilité. Si la seule base de données ou l’unique copie des photos est peut-être endommagée, préservez-la et arrêtez-vous : repartir de zéro malgré ces éléments peut transformer un incident diagnostiquable en perte définitive.

Réparer lorsque la panne est localisée et réversible

Privilégiez la réparation lorsqu’un seul point de montage, une permission, une valeur d’environnement, une dépendance, une tâche ou une image figée explique la panne, et que le système fonctionnait normalement avant une modification connue. Capturez les journaux, effectuez une sauvegarde, modifiez cette seule couche, puis reproduisez le déclencheur.

La réussite rétablit la fonction défaillante sans créer de ressources manquantes, d’erreurs de base de données ni de nouveaux avertissements au démarrage. Si la même panne réapparaît après recréation, sa cause peut se trouver dans la définition du déploiement ou l’état persistant ; remplacer à répétition les conteneurs ne constitue alors plus une réparation fondée sur des preuves.

Une discussion sur la corruption d’une base de données montre à quelle vitesse les choix de récupération deviennent risqués lorsque la base de données est la couche suspecte. Utilisez la leçon consistant à préserver les données avant toute réparation, et non une commande destructive non vérifiée.

Reconstruire l’environnement d’exécution lorsque la dérive est impossible à circonscrire

Choisissez une reconstruction propre de l’environnement d’exécution lorsque les versions des images, les réseaux, les valeurs d’environnement, les montages et les modifications manuelles des conteneurs ne peuvent plus être reproduits, mais que les composants persistants vérifiés restent intacts. Construisez le nouvel environnement à côté de l’ancienne instance, avec des versions figées et des ports isolés, plutôt que de l’effacer.

Une reconstruction convient également après une compromission de l’hôte ou lorsqu’une installation non prise en charge a accumulé des modifications inconnues, car la restauration d’entrées de déploiement fiables crée une nouvelle limite d’audit. Faites pivoter les identifiants exposés et inspectez les sauvegardes avant de les connecter à la nouvelle cible propre.

La présentation ZimaSpace du déploiement d’applications auto-hébergées fournit un contexte plus large sur la pile de services ; Immich exige néanmoins que la relation entre sa base de données et ses fichiers multimédias soit validée séparément.

Ne reconstruisez pas par-dessus des données persistantes incertaines

Arrêtez-vous lorsque la base de données et la bibliothèque de téléversements pourraient être désynchronisées, lorsque l’unique sauvegarde n’a pas été testée ou lorsque la copie faisant autorité n’est pas claire. Faites un instantané ou un clone de tous les éléments candidats et notez leurs horodatages avant de tenter une récupération de la base de données ou une réconciliation des fichiers multimédias.

Une discussion sur la récupération avec Unraid montre la difficulté opérationnelle de restaurer Immich lorsque les composants de sauvegarde et les versions ne correspondent pas. Sa discussion sur les limites de la restauration recommande d’effectuer les tests en isolation plutôt que d’écraser les chemins de production.

Si les originaux sont intacts mais que la base de données est irrécupérable, préservez les deux et documentez les conséquences avant d’envisager une nouvelle importation dans une bibliothèque. Il s’agit d’une décision de reconstruction des données, et non d’une réparation courante ; elle peut entraîner la perte des albums, des paramètres de partage, des visages, des favoris ou des métadonnées historiques.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valider les données persistantes sur une cible propre

Restaurez ou connectez les données persistantes copiées à la cible propre, puis testez les utilisateurs, le nombre d’éléments de la chronologie, un échantillon d’originaux, les albums, la recherche, les données de reconnaissance faciale, les bibliothèques externes, un nouveau téléversement, les tâches, ainsi qu’une nouvelle sauvegarde de la base de données. Comparez les résultats avec les éléments préservés provenant de la source.

Comparez le nombre d’éléments de la base de données avec des fichiers échantillonnés sur plusieurs dates, utilisateurs et types de médias. Confirmez les chemins des bibliothèques externes, les tâches dérivées et une nouvelle exportation de la base de données avant d’attribuer l’adresse de production. Un simple écran de connexion ne prouve pas l’intégrité des données.

Redémarrez les conteneurs et l’hôte deux fois. La validation exige des montages stables, une configuration reproductible, l’absence de boucle de migration et le fonctionnement de la charge habituelle. Si la cible propre reproduit la même erreur de base de données ou de fichier, la dérive de l’environnement d’exécution n’était pas la cause ; une récupération spécialisée des données reste alors l’option la plus sûre.

Basculer avec une limite de restauration

Transférez l’adresse de production uniquement après la réussite des vérifications isolées, et laissez l’ancien système éteint mais récupérable pendant une période d’observation convenue. Empêchez les deux instances d’accepter simultanément des téléversements ou d’exécuter la même automatisation.

Après le basculement, exécutez le flux habituel de téléversement familial, de navigation, de recherche, de partage et de sauvegarde. La validation préserve les nombres d’éléments et les originaux après le redémarrage suivant ; en cas d’écart, redirigez le trafic vers la cible préservée sans écraser l’un ou l’autre jeu de données.

Revenez à la réparation ou à la récupération spécialisée si la cible propre reproduit les mêmes erreurs de base de données ou de fichier : l’environnement d’exécution n’en était pas la cause. Annulez le basculement si les nombres d’éléments ou les originaux diffèrent. Escaladez le problème avec les versions, les sommes de contrôle, les horodatages des sauvegardes, la première erreur et la limite exacte entre l’état copié et l’état nouvellement créé.