Comment revenir en toute sécurité à une version antérieure d’Immich après une mise à jour incompatible

Ne rétrogradez Immich qu’après avoir préservé l’état actuel et déterminé si la nouvelle version a modifié la base de données ou la configuration d’une manière que l’ancienne image ne peut pas lire.

Une image de conteneur peut être remplacée, mais son état persistant a peut-être déjà été migré. Si une mise à niveau démarre mal, désactivez les mises à jour automatiques et les nouvelles écritures, notez les deux versions, protégez la base de données et les fichiers multimédias actuels, puis choisissez entre un simple retour à l’ancienne image et une restauration du point de récupération précédant la mise à niveau.

Gelez la mise à niveau échouée avant qu’elle ne modifie davantage l’état

Désactivez les mises à jour automatiques des images et empêchez les clients d’ajouter de nouvelles photos pendant que vous recueillez les éléments nécessaires. Notez les versions ou condensats exacts des anciennes et nouvelles images Immich, la version de PostgreSQL, les fichiers Compose et d’environnement, les chemins de montage, ainsi que la première erreur de démarrage ou de migration.

Le guide de ZimaSpace sur les limites du retour à une image de conteneur établit une distinction essentielle : les volumes persistants survivent au remplacement de l’image, mais cela n’est sûr que si l’ancienne application reste compatible avec l’état qu’ils contiennent.

Effectuez une sauvegarde native de la base de données dans son état actuel défaillant si celle-ci peut être lue, et conservez séparément la sauvegarde précédant la mise à niveau. Ne remplacez aucune des deux lors d’expérimentations répétées. La copie actuelle pourra être nécessaire pour poursuivre la mise à niveau ultérieurement, même si l’objectif immédiat est de revenir à l’ancienne version.

Déterminez si la version a franchi une limite de migration de la base de données

Examinez la première erreur survenue après la mise à niveau et déterminez si elle apparaît avant ou pendant la migration de la base de données, après la migration au démarrage de l’application, ou uniquement lors d’un flux de travail utilisateur. Ce moment modifie le plan de retour, car une ancienne image peut ne pas comprendre un schéma déjà modifié par la nouvelle version.

Un récent signalement concernant Immich, où le service n’a pas démarré après un parcours de mise à niveau, montre pourquoi des parcours de migration non pris en charge ou ignorés peuvent rendre un simple changement de version peu fiable. Considérez cette discussion comme une étude de cas et vérifiez la séquence exacte des migrations pour vos versions.

Si la nouvelle application n’a jamais touché à la base de données et que l’échec se limite à une incompatibilité d’image ou d’environnement d’exécution, le retour à une image épinglée peut suffire. Si les migrations sont terminées, considérez la sauvegarde de la base de données précédant la mise à niveau comme le choix le plus sûr pour l’ancienne image, sauf preuve explicite de compatibilité.

Restaurez une base de données et un environnement d’exécution correspondants au lieu de mélanger les époques

Construisez la cible de retour à partir de la dernière version connue comme fonctionnelle, de sa configuration de déploiement compatible et du point de récupération de la base de données datant d’avant la modification incompatible. Conservez l’arborescence des fichiers multimédias, sauf si la version a modifié ces fichiers d’une manière documentée ; ne recopiez pas plusieurs téraoctets simplement parce que l’image de l’application a changé.

La discussion sur le retour compatible avec la base de données explique le danger général du déploiement d’un code plus ancien sur un schéma qu’il ne comprend plus. Ce principe est plus important que le simple fait que le conteneur démarre correctement.

Démarrez l’instance restaurée de manière isolée afin que les clients mobiles et les tâches planifiées ne puissent pas écrire avant la fin de la validation. Si l’ancienne version signale immédiatement des erreurs de schéma, arrêtez-la. Ne forcez pas manuellement les migrations à revenir en arrière sur l’unique copie de la base de données, sauf si vous disposez d’une procédure de récupération testée et spécifique à la version.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Épinglez l’image exacte connue comme fonctionnelle et reproduisez sa configuration

Utilisez une version précise ou une référence d’image immuable plutôt qu’une balise susceptible d’évoluer. Restaurez l’environnement correspondant, les dépendances des services, les mappages de périphériques, les réseaux, les ports et la cible du proxy inverse à partir du dernier déploiement connu comme fonctionnel. Un retour qui modifie discrètement plusieurs couches de l’infrastructure crée un deuxième incident.

Conservez la nouvelle image et la configuration défaillantes à côté des notes de retour. Cela permettra une récupération contrôlée vers l’avant une fois l’incompatibilité comprise. Supprimer immédiatement tous les nouveaux artefacts peut compliquer la comparaison des états défaillant et fonctionnel ou la reproduction de la mise à niveau dans un environnement de test.

Si l’ancien service démarre avec l’état restauré, examinez les journaux avant de réactiver les clients. Vérifiez qu’il n’y a aucune tentative inattendue de migration, initialisation d’une nouvelle installation, absence de montage du stockage ou réécriture des permissions. Une simple page de connexion ne prouve pas que le retour utilise les données attendues.

Validez l’ancienne version avec le déclencheur d’origine et conservez une voie de reprise vers l’avant

Testez des utilisateurs représentatifs, des éléments anciens et récents, les albums, le partage, la recherche, un nouvel envoi contrôlé, les tâches en arrière-plan, la création d’une sauvegarde de la base de données et la route du proxy inverse. Redémarrez la pile une fois et vérifiez que les mêmes montages et la même base de données sont restaurés sans intervention manuelle.

Suspendez les nouveaux envois jusqu’à la réussite de ces vérifications, puis rétablissez l’accès et surveillez la période de charge habituelle. Conservez à la fois la sauvegarde précédant la mise à niveau et la sauvegarde de l’état défaillant de la nouvelle version afin de pouvoir réessayer la mise à niveau ultérieurement dans une copie isolée, une fois le problème de compatibilité compris.

Le retour a échoué si l’ancienne version signale une incompatibilité de schéma, si des données connues sont absentes ou si les écritures aboutissent à un chemin inattendu. Arrêtez-vous et restaurez à nouveau le point de récupération conservé au lieu d’empiler les réparations. Faites remonter le problème avec les versions exactes, les journaux de migration, les horodatages des sauvegardes de la base de données, la différence de configuration Compose et la première étape de vérification qui échoue.