Comment déplacer les données d’Immich sans perdre les utilisateurs, l’historique ni les paramètres

Déplacez Immich comme une migration de l’état de l’application, et non comme une simple copie de dossier : préservez la base de données, l’arborescence des médias, la configuration, les secrets et les chemins qui les relient.

Une migration peut sembler réussie parce que chaque fichier JPEG existe sur le nouveau disque, alors que les comptes, albums, personnes, partages, favoris ou relations historiques ont disparu. Créez d’abord un point de restauration, capturez un état source cohérent, copiez-le sans modifier les identifiants, restaurez-le sur une cible isolée et ne basculez qu’après avoir vérifié que les flux de travail du foyer correspondent.

Inventoriez l’état qui doit être déplacé ensemble

Répertoriez la base de données PostgreSQL, les médias importés, les données générées que vous souhaitez conserver, les définitions des bibliothèques externes, la configuration Compose ou de l’application, les valeurs d’environnement, les secrets, les noms de réseau et les mappages de stockage actuels. Indiquez quel élément fait autorité et lequel peut être régénéré après la récupération.

Une discussion de 2026 sur la conservation des utilisateurs Immich lors d’un déplacement renforce le point central : l’état des utilisateurs et des bibliothèques dépend de la base de données et des chemins montés, pas de l’image du conteneur. Considérez les commandes de la communauté comme des exemples et adaptez-les à la version exacte déployée.

Avant le déplacement, notez un petit ensemble de vérification : deux utilisateurs, plusieurs albums, des favoris, des éléments partagés, une personne ou un résultat de recherche, des fichiers anciens et récents, ainsi qu’un chemin de bibliothèque externe s’il est utilisé. Ces enregistrements connus rendront la validation post-migration bien plus fiable qu’une simple comparaison de la taille totale des fichiers.

Créez un point de restauration cohérent avant la copie

Mettez en pause les nouveaux imports ou planifiez une fenêtre de maintenance afin que la source cesse de changer pendant la capture de l’état à migrer. Effectuez une sauvegarde native de la base de données et protégez les médias ainsi que la configuration de la source. Après la capture, laissez l’instance d’origine intacte jusqu’à ce que la destination ait passé la vérification.

Le guide de récupération de ZimaSpace consacré à la restauration conjointe des composants d’une photothèque explique pourquoi les originaux, l’état du catalogue et la configuration qui définit les chemins doivent représenter un point de récupération compatible. C’est la même limite qu’exige une migration.

N’utilisez pas le répertoire de la base de données de production en cours d’utilisation comme cible ordinaire de copie de fichiers pendant qu’il évolue. Si la durée d’arrêt doit être courte, utilisez un export compatible avec la base de données et une méthode de stockage dont vous comprenez l’ordre de capture. Une migration n’est récupérable qu’à hauteur du point que vous pouvez restaurer, et non du nombre de fichiers copiés.

Copiez les médias en conservant les chemins et les permissions

Copiez l’arborescence des médias vers la destination sans réorganiser les dossiers pendant la migration. Préservez le propriétaire, les permissions, les horodatages et toutes les fonctionnalités du système de fichiers dont dépend votre déploiement. Si le chemin visible dans le conteneur doit rester identique, modifiez la source du montage côté hôte tout en conservant le mappage dans le conteneur.

Le flux de migration avec rsync actuel met en avant le mode archive, les exécutions à blanc, les transferts reprenables et le danger des options de miroir destructrices. Effectuez une comparaison à blanc avant toute suppression et vérifiez la destination au lieu de supposer qu’une commande terminée équivaut à une migration complète de l’application.

Comparez le nombre et la taille des fichiers, puis vérifiez un échantillon représentatif de sommes de contrôle comprenant d’anciennes photos, de nouvelles photos, des vidéos et des fichiers volumineux. Si des erreurs de copie ou des fichiers « disparus » apparaissent parce que la source a changé, cessez d’accepter les imports et répétez le passage différentiel au lieu de supprimer la source pour donner à la destination une apparence propre.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaurez la base de données et la configuration sur une cible isolée

Démarrez la destination avec un nom d’hôte temporaire ou sur un réseau isolé afin que les clients mobiles ne puissent pas y importer de fichiers pendant la validation. Montez les médias copiés sur les chemins attendus dans le conteneur, restaurez la base de données correspondante et reproduisez l’environnement, les secrets, les réseaux et les paramètres du proxy nécessaires à cette version.

Un autre témoignage de 2026 sur une migration de serveur par étapes montre pourquoi les opérateurs testent le nouvel hôte avant de retirer l’ancien. Utilisez ces témoignages pour trouver des idées de pannes, mais laissez vos enregistrements connus déterminer si la migration a réellement préservé l’état.

Arrêtez-vous si la destination s’ouvre comme une nouvelle installation, signale un stockage manquant ou propose une initialisation destructive. Ces symptômes indiquent généralement que la base de données ou les montages ne sont pas ceux attendus. Corrigez d’abord le chemin ou la cible de restauration ; n’importez pas de nouveaux fichiers dans une instance qui semble vide et ne créez pas deux historiques concurrents.

Ne basculez qu’après validation des utilisateurs, de l’historique et des nouvelles écritures

Connectez-vous avec chaque utilisateur de référence et vérifiez l’appartenance aux albums, les favoris, les partages, l’état de la recherche ou des personnes, les originaux représentatifs, les horodatages et les nombres de fichiers attendus dans les bibliothèques. Importez ensuite une photo de test et confirmez qu’elle apparaît, est traitée et reste disponible après le redémarrage d’un conteneur.

Modifiez la cible de production du DNS ou du proxy uniquement après la réussite du test isolé. Laissez l’ancienne instance arrêtée mais récupérable afin que les deux systèmes ne puissent pas accepter des écritures simultanément. Conservez la sauvegarde de la base de données précédant la migration et les médias sources jusqu’à ce que le nouvel hôte ait effectué ses sauvegardes normales et au moins un test de restauration.

Revenez en arrière si les nombres divergent, si des relations connues disparaissent, si les nouveaux imports sont écrits sur le mauvais disque ou si la destination échoue après un redémarrage. Pour l’escalade, fournissez les versions source et cible, l’horodatage de la sauvegarde de la base de données, les mappages de montage, les journaux de copie, les différences de permissions et le premier élément de vérification qui a échoué.