Checklist de migration sécurisée d’Immich vers un nouveau serveur domestique

Une migration Immich sûre commence par la vérification de ce qui doit être préservé avant toute copie : les fichiers photo, la base de données et les paramètres de déploiement qui les reconnecteront sur le nouvel hôte.

Sur un serveur domestique, le risque vient généralement du déplacement de ces éléments à des moments différents ou du démarrage de la destination avec des chemins incorrects. Considérez l’ancien serveur comme la copie de restauration, bloquez les écritures évitables, notez la version actuelle et les mappages de stockage, puis déplacez un ensemble de données vérifié vers la nouvelle machine. La checklist ci-dessous permet de garder l’opération réversible jusqu’à ce que la nouvelle instance puisse se connecter, trouver la bibliothèque d’origine, traiter les tâches et survivre à un redémarrage sans revenir à un état vide.

Geler la source et documenter l’état connu comme fonctionnel

Commencez sur le serveur fonctionnel, pas sur le nouveau. Notez la version d’Immich, la définition Compose ou de l’App Store, les valeurs d’environnement qui contrôlent les chemins de la base de données et du stockage, l’emplacement de la bibliothèque photo, celui de la base de données ainsi que les montages des bibliothèques externes. Notez également l’URL actuelle du serveur et le compte utilisateur que vous utiliserez pour la validation.

Cette inventaire vise à éviter qu’une migration ne devienne discrètement une mise à niveau, une refonte des chemins et une modification du réseau en même temps. Gardez la version de l’application et la structure logique du stockage aussi stables que possible jusqu’à la validation de la restauration ; les changements de version pourront être effectués une fois la destination vérifiée.

Avant la copie, arrêtez ou mettez en pause les nouveaux téléversements si votre foyer peut le supporter. Si ce n’est pas possible, définissez une fenêtre de bascule et prévoyez une courte synchronisation finale. La sortie de cette étape doit être une cartographie écrite de la source permettant de savoir où se trouvent les originaux, où se trouve l’état de la base de données et quelle configuration recrée les mêmes relations.

Capturer la base de données, les ressources et la configuration dans un même ensemble de migration

Traitez la base de données et les fichiers multimédias comme un seul ensemble de récupération plutôt que comme deux sauvegardes indépendantes. Les sauvegardes actuelles de la base de données Immich contiennent les métadonnées et les références aux fichiers, mais pas les photos ni les vidéos elles-mêmes. La sauvegarde de la base de données doit donc être transférée avec le contenu correspondant de UPLOAD_LOCATION et avec les données des bibliothèques externes que vous gérez séparément.

Un ensemble de migration exploitable doit inclure les ressources, l’état PostgreSQL et la configuration qui les reconnecte. Un ensemble de sauvegarde Immich complet comprend les ressources téléversées, une sauvegarde de base de données prise en charge et la configuration du déploiement, avec des tests de restauration servant à prouver que l’ensemble fonctionne. Gardez ces éléments ensemble afin que la destination puisse être associée à un même point de récupération.

Vérifiez l’ensemble de migration avant de toucher à la destination. Confirmez que l’export de la base de données n’est pas vide, échantillonnez plusieurs fichiers originaux dans la bibliothèque copiée et conservez les fichiers Compose et d’environnement dans le même dossier de migration ou le même ensemble documentaire. Si un composant ne peut pas être vérifié, arrêtez-vous ici et effectuez une nouvelle copie plutôt que de compenser sur le nouveau serveur.

Préparer le nouvel hôte sans créer d’état concurrent

Créez d’abord les répertoires et les montages de destination, puis confirmez que le nouvel hôte voit les disques ou partages réseau prévus aux chemins exacts que vous comptez utiliser. Un montage NAS manquant peut laisser un répertoire vide ordinaire à sa place, et un conteneur peut très bien s’initialiser sur ce chemin de secours.

Installez l’environnement d’exécution et recréez la définition du déploiement, mais ne laissez pas une instance Immich vierge accumuler des téléversements ou une configuration avant la restauration de l’ancien état. Gardez les identifiants, le nom de la base de données, les variables de stockage et les cibles de montage des bibliothèques externes alignés sur la source, sauf si le plan de migration prévoit explicitement un changement de chemin contrôlé.

Si le nouveau serveur nécessite des chemins différents côté hôte, mappez-les délibérément tout en conservant la cohérence des chemins visibles dans les conteneurs et des attentes de la base de données. La destination n’est prête que lorsque ses montages effectifs pointent vers les emplacements des données copiées et que vous pouvez expliquer chaque traduction de chemin avant le démarrage complet de l’application.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaurer l’état et reconnecter chaque chemin de stockage

Restaurez la base de données à l’aide de la procédure de récupération adaptée à la version d’Immich qui a créé la sauvegarde, puis démarrez les autres services uniquement lorsque la base de données est prête. N’improvisez pas de commandes de base de données destructrices à partir d’un ancien guide lorsqu’une installation plus récente utilise une procédure de restauration différente.

Pendant la bascule, préservez la relation entre la base de données et le stockage avant de reprendre l’utilisation normale. Une séquence de migration Immich testée suit le même principe : l’application doit s’ouvrir sur l’état restauré de la base de données et les chemins multimédias prévus, et non initialiser une bibliothèque vierge en imposant une reconstruction complète.

Après le démarrage, vérifiez l’accès au stockage avant de lancer les tâches en arrière-plan lourdes. Ouvrez plusieurs anciennes ressources à des dates différentes, vérifiez que les miniatures se chargent, confirmez la présence d’un album et d’une personne ou d’un résultat de recherche existant avant la migration, et assurez-vous que les bibliothèques externes sont lisibles si vous les utilisez. Un écran d’intégration vierge ou une chronologie vide est un signal d’arrêt : revérifiez les mappages de la base de données et des montages avant d’écrire un nouvel état.

Valider la charge de travail d’origine avant de mettre l’ancien serveur hors service

Une première connexion réussie ne marque pas la fin de la migration. Téléversez une photo de test sans importance depuis le client habituel, vérifiez qu’elle apparaît dans le stockage hôte prévu, puis supprimez-la via Immich et assurez-vous que la bibliothèque reste saine. Cela vérifie l’ensemble du chemin d’écriture au lieu de prouver uniquement que les anciennes données sont lisibles.

Redémarrez le nouveau serveur domestique et répétez les vérifications importantes pour votre foyer : connexion au navigateur, connexion de sauvegarde mobile, plusieurs anciennes photos, recherche, une vidéo représentative, files de tâches et accès distant s’il fait partie de la configuration habituelle. La migration n’est terminée que lorsque le même état survit au redémarrage de l’hôte et que les montages de stockage sont disponibles avant le démarrage d’Immich.

Gardez l’ancien serveur éteint mais inchangé pendant une période de retour en arrière au lieu de l’effacer immédiatement. Si la nouvelle instance commence à écrire dans un dossier vide inattendu, ne parvient pas à reproduire l’ancienne bibliothèque après un redémarrage ou affiche des erreurs de base de données que vous ne pouvez pas expliquer, arrêtez les nouveaux téléversements et revenez à la source connue comme fonctionnelle pendant que vous comparez l’ensemble de migration. Ne mettez l’ancien hôte hors service qu’après validation de la destination en utilisation normale et réalisation d’un nouveau test de sauvegarde.