Comment restaurer Immich après l’échec d’une mise à jour du conteneur

Restaurez Immich après l’échec d’une mise à jour de conteneur en figeant les éléments actuels, en épinglant chaque service Immich sur la dernière version connue comme fonctionnelle et en ne restaurant les données que si un retour coordonné en arrière ne permet pas de démarrer la pile.

Une mise à jour peut modifier simultanément le code de l’application, les attentes du schéma de la base de données, les variables d’environnement et les versions des services associés. Télécharger plusieurs fois la dernière version ou mélanger des conteneurs anciens et nouveaux rend la limite de récupération plus difficile à déterminer. Enregistrez le fichier Compose, l’environnement, les journaux, la base de données et les chemins des fichiers importés avant d’intervenir, puis choisissez entre un retour à une image antérieure et une restauration complète de la base de données et de la bibliothèque.

Figez l’état défaillant et identifiez la limite de la mise à jour

Arrêtez les redémarrages automatiques et notez les images ou condensats exacts du serveur, du service d’apprentissage automatique, de la base de données et des services de cache. Enregistrez les journaux de démarrage et les fichiers de déploiement avant tout nouveau téléchargement. La réussite signifie que vous pouvez identifier ce qui a changé ; en cas d’échec, la récupération doit être interrompue jusqu’à ce que les anciennes versions puissent être identifiées dans l’historique des déploiements ou parmi les images locales.

Vérifiez si le serveur s’arrête avant de se connecter à la base de données, pendant une migration ou après être devenu opérationnel. Une erreur de connexion à une dépendance indique un problème de réseau, d’identifiants ou de vérification d’état ; une erreur de migration augmente le risque d’une restauration limitée à l’image de l’application, car la base de données peut déjà avoir été modifiée.

Le guide consacré aux mises à jour versionnées d’Immich montre pourquoi la limite de version et les fichiers de déploiement sont importants. Utilisez-le pour dresser l’inventaire de la transition, tout en considérant vos propres journaux et sauvegardes comme la référence pour le retour en arrière.

Essayez d’abord un retour complet à la dernière image connue comme fonctionnelle

Épinglez toutes les images de l’application Immich sur la version exacte qui fonctionnait auparavant, plutôt que de ne modifier qu’un seul service. Recréez les conteneurs concernés en laissant les volumes persistants intacts. Si la pile redevient saine et que les journaux ne montrent aucune incompatibilité de schéma, ce retour à faible impact est réussi.

Si l’ancien serveur refuse le schéma actuel de la base de données, arrêtez-vous. N’alternez pas les versions sur la même base de données et ne modifiez pas manuellement les tables de migration. Cet échec signifie que la mise à jour a franchi une limite de données et que la récupération doit utiliser une sauvegarde de la base de données dont l’horodatage correspond à la version d’application sélectionnée.

Un rapport sur Immich v1.135.3 documente un échec précis du démarrage lors d’une migration de base de données après une mise à jour. Son exemple de migration délimitée justifie une lecture attentive de la première erreur fatale ; il ne constitue pas une autorisation de copier les commandes de ce cas dans une autre version.

Ne restaurez la base de données et les fichiers multimédias que si le retour en arrière est impossible

Créez une copie de sécurité ou un instantané du stockage de l’état défaillant avant la restauration. Préparez une cible de récupération propre, restaurez la sauvegarde de la base de données, puis rendez accessibles la bibliothèque de fichiers importés correspondante et les fichiers de déploiement requis. Ne remplacez pas l’unique bibliothèque actuelle par une copie plus ancienne dans le seul but d’aligner les horodatages.

Les enregistrements de la base de données et les fichiers multimédias doivent décrire la même collection. Si la sauvegarde est antérieure aux importations récentes, conservez ces fichiers plus récents séparément pour une réconciliation ultérieure. La restauration est réussie lorsque les migrations s’achèvent, que les utilisateurs et fichiers attendus apparaissent et que des originaux échantillonnés s’ouvrent sans erreurs généralisées de fichiers manquants.

Le guide de migration d’Immich de ZimaSpace fournit un inventaire utile pour déplacer les composants persistants sans considérer une image de conteneur comme la bibliothèque de photos elle-même.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Validez la récupération avant de retenter la mise à jour

Testez la connexion, la navigation dans la timeline, le téléchargement des originaux, la génération des miniatures, Smart Search, le traitement des visages, une nouvelle importation et une sauvegarde de la base de données. Redémarrez une fois les conteneurs et l’hôte. La réussite exige de retrouver les mêmes fichiers et fonctionnalités après le redémarrage, sans erreurs répétées de migration ou d’autorisation.

Conservez les états défaillant et récupéré sous des noms distincts jusqu’à la fin de la validation. Si la récupération dépend d’une version plus ancienne, désactivez le téléchargement automatique des images et documentez la version épinglée. Ne retentez la mise à jour qu’après avoir examiné chaque version intermédiaire et effectué une nouvelle sauvegarde coordonnée.

Revenez à la cible de récupération conservée si une nouvelle importation disparaît, si les originaux ne s’ouvrent pas ou si les tâches se terminent à répétition de manière anormale. Procédez à une escalade en indiquant les versions source et cible, les condensats des images, le premier journal d’erreur fatal, l’horodatage de la sauvegarde de la base de données et la correspondance des stockages ; ne supprimez jamais la dernière copie connue comme fonctionnelle tant que la compatibilité de la mise à jour n’est pas résolue.