Oui, mais préparez les sources séparément, normalisez les fichiers annexes et les horodatages, éliminez les doublons en fonction du contenu et des métadonnées, puis vérifiez les albums avant de les fusionner dans une seule bibliothèque gérée.
La compatibilité devient une véritable question lorsque les archives Google Takeout chevauchent les sauvegardes d'appareils photo d'iPhone ou d'Android et peuvent contenir des copies modifiées, des fichiers annexes JSON, des doublons et des interprétations différentes des fuseaux horaires. Commencez par un chemin ou un compte jetable, conservez l'état de fonctionnement précédent à portée de main et évaluez la conception en fonction de la charge de travail d'origine plutôt que d'un test de connexion ponctuel.
Identifiez le propriétaire de la ressource partagée
La branche prise en charge consiste en des importations préparées et étiquetées par source, avec déduplication tenant compte du contenu. La branche concurrente est un téléversement groupé qui supprime la provenance et considère les noms de fichiers comme des identifiants. Notez les versions, identités, adresses, chemins de montage, permissions et l'état observable actuel avant de modifier l'une ou l'autre branche.
L'exportation des données Google pertinente définit la première limite de compatibilité. Utilisez-la pour circonscrire l'affirmation, puis vérifiez le même comportement sur ce serveur domestique précis au lieu de considérer une fonctionnalité documentée comme la preuve que la conception complète fonctionne.
Établissez la règle de décision avant les tests : la réussite doit conserver la date de prise de vue et l'appariement corrects des originaux, tout en regroupant les doublons exacts et en maintenant distinctes les modifications significatives ; l'échec inclut le décalage des dates, la dissociation des fichiers annexes, la disparition de l'appartenance aux albums ou la fusion de photos similaires mais différentes. Cela évite de prendre une connexion partielle ou une sortie de commande réussie pour une compatibilité de bout en bout.
Ne modifiez qu'un écouteur ou une route à la fois
Utilisez un seul facteur discriminant contrôlé : extrayez une année dans des dossiers de préparation distincts, associez les fichiers annexes, calculez les hachages, importez-les dans un compte de test, puis comparez les dates, les lieux, les albums, les Live Photos et les doublons. Gardez le client, la charge de travail, le jeu de fichiers, le compte et le calendrier constants afin que le composant modifié soit la seule explication plausible.
Utilisez l'importation Immich en ligne de commande pour choisir la deuxième observation importante pour ce chemin. Capturez les deux côtés de la transaction : résolveur ou route, protocole négocié, identité du processus, statut de sortie, latence, octets transférés et tout événement de récupération.
Répétez le test après l'événement du cycle de vie indiqué dans le titre : recréation, reconnexion, remontage, redémarrage, basculement ou changement de client. Une conception qui ne fonctionne que lorsque d'anciens sockets, caches ou identifiants restent actifs n'a pas réussi le test.
préparer par source -> associer les fichiers annexes -> calculer les hachages -> importation pilote -> comparer les dates/albums/associations -> étendre année par année
Utilisez des preuves de routage observables pour décider
RÉUSSITE : les originaux conservent leur date de prise de vue et leur appariement corrects, tandis que les doublons exacts sont regroupés et que les modifications significatives restent distinctes. Enregistrez les versions exactes et la topologie qui ont produit cet état, car la conclusion s'applique à ces conditions et non à toutes les implémentations du protocole.
ÉCHEC : les dates changent, les fichiers annexes se dissocient, l'appartenance aux albums disparaît ou des photos similaires mais différentes sont fusionnées. Vérifiez les dépendances partagées telles que le DNS, la MTU, l'identité, l'état du pare-feu, la latence du stockage et les sessions mises en cache avant d'attribuer la responsabilité à l'une ou l'autre branche principale.
EXCEPTION : supprimez uniquement l'importation de test, conservez les archives intactes et corrigez l'analyse ou le regroupement avant d'élargir la plage de dates. N'augmentez pas les privilèges, ne supprimez pas les données sources, ne réduisez pas la sécurité du transport et ne remplacez pas le stockage fonctionnel avant qu'une observation reproductible n'identifie la limite qui a échoué.
Vérifiez de nouveau l'isolation avant le retour du trafic de production
Appliquez uniquement l'action correspondant à la branche observée, puis relancez la charge de travail d'origine. Conservez la conception uniquement lorsque les originaux conservent leur date de prise de vue et leur appariement corrects, tandis que les doublons exacts sont regroupés et que les modifications significatives restent distinctes pendant deux cycles de vie pertinents et sous la charge simultanée attendue.
Utilisez les fichiers annexes des exportations cloud pour vérifier le flux dépendant le plus proche. Son comportement en matière d'accès, de calendrier et de récupération doit rester inchangé pendant l'activation de la nouvelle conception.
Arrêtez-vous et revenez à l'état enregistré si les dates changent, si les fichiers annexes se dissocient, si l'appartenance aux albums disparaît ou si des photos similaires mais différentes sont fusionnées. Faites remonter le problème avec les horodatages, les versions exactes, les preuves liées à la route ou au montage et la reproduction la plus petite possible, plutôt que d'ajouter une solution de contournement.
Comparez le résultat avec les sauvegardes photo séparées afin que le risque ne soit pas simplement déplacé vers une autre couche réseau, d'identité, de sauvegarde ou de stockage.
Pour l'importation combinée de photos, la réponse nuancée est donc le jugement initial - et non un oui inconditionnel. L'état observable de réussite constitue la ligne d'acceptation ; l'état d'échec constitue la ligne de retour en arrière.
FAQ
Faut-il supprimer les doublons exacts avant l'importation ?
Conservez d'abord les exportations intactes ; éliminez les doublons d'une copie de travail après avoir enregistré les hachages et les relations avec les fichiers annexes.
Pourquoi les dates de Takeout diffèrent-elles de celles des sauvegardes du téléphone ?
Les dates du système de fichiers, les métadonnées de prise de vue, les fichiers annexes JSON, les modifications et la conversion des fuseaux horaires peuvent représenter des événements différents.
L'appartenance aux albums peut-elle être conservée avec les deux sources ?
Uniquement si l'importateur comprend les métadonnées d'album de chaque source ; validez d'abord avec un petit album avant l'importation groupée.
Assistance et conseils
Plus à lire

Une galerie auto-hébergée peut-elle préserver l’association des Live Photos Apple ?
Une décision conditionnelle concernant un serveur personnel pour l’association des Live Photos Apple, avec des tests contrôlés, l’interprétation des résultats, une procédure de retour...

Immich peut-il utiliser une bibliothèque externe sans prendre possession des fichiers ?
Une décision conditionnelle pour serveur personnel concernant la propriété des bibliothèques externes d’Immich, avec des tests contrôlés, l’interprétation des résultats, un retour en arrière...

Un serveur multimédia peut-il lire les métadonnées NFO d’une bibliothèque en lecture seule ?
Une décision conditionnelle pour un serveur domestique concernant les métadonnées NFO en lecture seule, avec des tests contrôlés, l’interprétation des résultats, un retour en...

