Immich peut-il utiliser une base de données externe sans compromettre les mises à niveau ?

Immich peut être configuré pour utiliser un service PostgreSQL externe, mais cela ne rend pas automatiquement les mises à niveau sûres ; cela transfère hors de la pile par défaut la responsabilité des versions de la base de données, des extensions, des privilèges, des sauvegardes et des restaurations.

Considérez une base de données externe comme une frontière de compatibilité avancée, et non comme une simple option de performance. Avant chaque mise à niveau d’Immich ou de PostgreSQL, vérifiez les exigences de la version exacte d’Immich que vous prévoyez d’exécuter, confirmez que le serveur externe peut fournir les extensions et privilèges requis, effectuez une sauvegarde restaurable et ne modifiez qu’une seule couche de mise à niveau à la fois afin de savoir quel composant a introduit une défaillance.

Commencez par définir le contrat de la base de données externe

Documentez le point de terminaison de la base de données, le nom de la base, le compte de service, le mode TLS, la version majeure de PostgreSQL, les noms et versions des extensions installées, ainsi que les personnes autorisées à mettre ces extensions à niveau. Conservez cet enregistrement à côté de la définition du déploiement d’Immich afin qu’une recréation du conteneur ne se reconnecte pas silencieusement à un autre serveur ou à une autre base de données.

Un serveur PostgreSQL préexistant est possible, mais il ne s’agit pas de la configuration recommandée par défaut pour Immich. Pour les versions actuelles, l’utilisation d’une base de données autonome nécessite pgvector ainsi que VectorChord ; Immich est réputé fonctionner avec PostgreSQL 14 à 19, pgvector >=0.7 et <0.9, et VectorChord >=0.3 et <2.0. Vérifiez à nouveau ces plages avant chaque mise à niveau, car elles peuvent changer.

Planifiez les privilèges avant la bascule. Immich s’attend généralement à disposer d’un rôle de base de données avec des privilèges de superutilisateur ; fonctionner sans ces privilèges est une voie avancée qui peut nécessiter une intervention manuelle lors des mises à jour, et les sauvegardes automatisées actuelles de la base de données nécessitent des privilèges de superutilisateur. Si votre fournisseur externe ne peut pas satisfaire ces exigences, arrêtez-vous avant de déplacer les données de production.

Vérifiez la compatibilité de PostgreSQL et des extensions avant toute modification

Répertoriez les versions actuelles et cibles de PostgreSQL ainsi que toutes les extensions dont dépend Immich. Une mise à niveau majeure de PostgreSQL peut nécessiter des binaires d’extension compilés pour la version majeure cible, tandis qu’une mise à niveau d’Immich peut nécessiter une extension plus récente ou un comportement de migration différent, même si PostgreSQL démarre toujours correctement.

Les fichiers des paquets d’extensions et l’état SQL des extensions doivent être transférés volontairement avec la base de données, et non être supposés suivre automatiquement une mise à niveau de PostgreSQL. Consultez les dépendances liées à la mise à niveau des extensions PostgreSQL avant de modifier la version majeure de la base de données ou les paquets d’extensions requis par Immich.

Si votre fournisseur externe ne vous permet pas d’installer ou de mettre à niveau l’extension requise, de modifier les paramètres de préchargement partagé lorsque cela est nécessaire ou d’accorder les privilèges requis par la migration, arrêtez-vous avant de mettre Immich à jour. Une base de données qui accepte les requêtes ordinaires peut tout de même être inadaptée à la prochaine migration de l’application.

Séparez les mises à niveau majeures de la base de données des mises à niveau d’Immich

Évitez de combiner une mise à niveau majeure de PostgreSQL, une mise à niveau d’extension et une mise à niveau de l’application Immich au cours d’une même intervention de maintenance, sauf si vous avez déjà répété l’intégralité de la procédure. Lorsque plusieurs frontières de compatibilité évoluent simultanément, un échec au démarrage ne permet plus de déterminer quelle couche en est la cause.

Les mises à jour mineures de PostgreSQL et les mises à niveau de version majeure sont des opérations de maintenance différentes, et les mises à niveau majeures nécessitent de préparer au préalable l’environnement cible, y compris les extensions tierces. Séparez autant que possible les mises à niveau majeures de PostgreSQL d’une mise à niveau de l’application Immich afin qu’un échec au démarrage corresponde toujours à une modification clairement identifiable.

Pour un serveur domestique, la séquence présentant généralement le moins de risques est la suivante : effectuer les sauvegardes, vérifier une restauration, mettre à jour une seule couche, exécuter les contrôles de validation, puis poursuivre. Si une version d’Immich nécessite une modification de la base de données, suivez l’ordre prescrit par cette version plutôt que d’appliquer une procédure générique de mise à niveau de PostgreSQL.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Préservez une possibilité de restauration couvrant la base de données et les médias

Une base de données externe facilite l’oubli du fait que l’état d’Immich est réparti entre PostgreSQL et la bibliothèque multimédia. Sauvegardez la base de données avec une méthode garantissant sa cohérence et préservez l’état pertinent des médias et de la configuration pendant la même fenêtre de récupération avant une migration susceptible de modifier les schémas ou les métadonnées des ressources.

L’état de la base de données, les fichiers de l’application, la configuration et les téléversements doivent être cohérents au moment de la restauration. Utilisez une sauvegarde cohérente d’un conteneur de base de données comme modèle d’acceptation, plutôt que de vérifier simplement si PostgreSQL démarre.

Ne considérez pas la restauration comme prête tant que vous ne savez pas ce qui se passe des deux côtés si la migration de l’application aboutit partiellement. Conservez suffisamment longtemps l’ancienne version de l’application, la définition du déploiement, la sauvegarde de la base de données et l’état des médias pour pouvoir récupérer les données sans écraser la seule copie connue comme fonctionnelle avec un état plus récent.

Validez la mise à niveau comme celle d’une application, et pas seulement comme celle d’une connexion à une base de données

Après la modification, vérifiez que PostgreSQL accepte le rôle Immich prévu, que les extensions requises sont présentes dans les versions attendues et que la migration d’Immich se termine sans erreurs répétées de base de données. Une connexion TCP réussie ou `SELECT 1` prouve la connectivité, mais pas la compatibilité avec l’application.

Utilisez ensuite Immich normalement : chargez d’anciens albums, ouvrez des photos et vidéos représentatives, effectuez des recherches, inspectez les utilisateurs ou les partages lorsque cela est pertinent et téléversez une ressource sans importance. Surveillez les journaux de l’application et de la base de données pendant ces opérations afin de détecter les extensions manquantes, les erreurs de permission, les échecs de migration ou les nouvelles tentatives répétées.

Ce n’est qu’après la réussite de ces contrôles que vous devez reprendre la conservation normale des sauvegardes et supprimer la copie de restauration. Si la base de données externe fait régulièrement dépendre les mises à niveau courantes d’Immich d’interventions manuelles sur les extensions ou les privilèges que vous ne pouvez pas répéter de manière fiable, le cycle de vie par défaut d’une base de données dédiée constitue le choix opérationnel le plus sûr.