Pourquoi la sauvegarde des photos du téléphone s’arrête-t-elle lorsque l’application s’exécute en arrière-plan ?
La sauvegarde des photos du téléphone s’arrête en arrière-plan lorsque le système d’exploitation mobile suspend l’application ou qu’un transfert échoué empêche le prochain lot planifié.
Les applications photo auto-hébergées ne disposent pas d’une exécution en arrière-plan illimitée. iOS et Android déterminent quand l’application peut se réveiller en fonction des autorisations, de l’état de la batterie, des conditions réseau, de l’utilisation récente et de la pression exercée sur les ressources système. Le processus de sauvegarde peut également se bloquer sur un fichier non pris en charge, une session expirée, un serveur inaccessible ou un original stocké uniquement dans le cloud qui doit d’abord être téléchargé. Déterminez si l’application n’est jamais planifiée, si elle démarre puis s’arrête, ou si elle échoue systématiquement sur le même fichier.
Vérifier si la sauvegarde fonctionne lorsque l’application est ouverte
Connectez le téléphone au Wi-Fi habituel, gardez l’application au premier plan et surveillez le nombre d’éléments en attente, le nom du fichier actif, le débit de transfert et le journal du serveur. Cela permet de confirmer le bon fonctionnement de l’authentification, de l’accessibilité du serveur, du stockage et de la sélection des albums avant d’impliquer la planification en arrière-plan.
Des utilisateurs d’Immich ont signalé que les importations s’arrêtaient immédiatement après avoir quitté l’application, même si les paramètres de sauvegarde étaient activés. Le symptôme distinctif est que l’importation au premier plan fonctionne, mais que la progression en arrière-plan s’arrête.
Si la sauvegarde au premier plan échoue également, poursuivez avec l’URL du serveur, le certificat, la connexion, le stockage et les erreurs propres aux fichiers. Si la sauvegarde au premier plan progresse normalement, ne modifiez pas ces éléments pendant que vous testez la planification et les restrictions du système d’exploitation.
Vérifier les autorisations d’arrière-plan et les réglages d’actualisation du système
Sur iOS, vérifiez l’actualisation en arrière-plan des apps, l’accès à la photothèque, l’accès au réseau local si nécessaire, les notifications si l’application les utilise et le mode économie d’énergie. Sur Android, vérifiez l’optimisation de la batterie, les données en arrière-plan, l’utilisation de la batterie sans restriction et l’existence éventuelle d’une liste supplémentaire de mise en veille des applications propre au fabricant.
Un rapport Immich sur iOS montre que l’application indiquait à plusieurs reprises que l’actualisation en arrière-plan était désactivée, alors que le réglage système était déjà activé. Ce cas illustre que l’état de l’application et celui du système d’exploitation peuvent diverger.
Désactivez puis réactivez l’autorisation concernée uniquement comme réinitialisation contrôlée, rouvrez l’application et vérifiez que le réglage est reconnu. Ne désactivez pas globalement toutes les protections de la batterie ; exemptez uniquement l’application de sauvegarde photo si la plateforme l’exige.
Distinguer la planification mobile normale d’une tâche bloquée
Le travail en arrière-plan est opportuniste et peut ne pas commencer immédiatement après l’extinction de l’écran. Notez si la sauvegarde reprend plus tard, après la mise en charge, après la reconnexion au Wi-Fi ou après une brève réouverture de l’application.
Des utilisateurs Android ont signalé l’échec de la synchronisation en arrière-plan même lorsque l’optimisation de la batterie et les restrictions étaient désactivées, ce qui montre que les autorisations seules ne prouvent pas que la planification fonctionne.
Utilisez un petit album de test contenant plusieurs fichiers JPEG ordinaires. Si ces fichiers finissent par être importés en arrière-plan, le planificateur système fonctionne et l’échec de la bibliothèque complète est probablement lié à la taille ou au type des fichiers, à la durée du réseau ou à l’état de la file d’attente.
Vérifier si un seul fichier défaillant bloque le lot
Ouvrez l’écran des détails de la sauvegarde et identifiez le premier nom de fichier qui échoue de manière répétée. Notez son extension, sa taille, son emplacement de stockage, son état de modification et vérifiez si le téléphone peut ouvrir l’original sans devoir le télécharger.
Un problème Immich décrit l’arrêt de la sauvegarde lorsqu’elle rencontrait des fichiers .pic non pris en charge, au lieu de les ignorer et de continuer. Le problème principal était qu’un seul fichier non pris en charge bloquait la file d’attente.
Déplacez le fichier hors de l’album sélectionné pour la sauvegarde ou exportez-le dans un format pris en charge, puis réessayez. Ne supprimez pas l’original avant de l’avoir conservé dans un autre emplacement vérifié et d’avoir confirmé la fin du reste de la file d’attente.
Tester les conditions réseau lentes ou interrompues
Vérifiez si le téléphone alterne entre le Wi-Fi et le réseau mobile, passe d’un point d’accès à un autre, perd la connexion au VPN ou au proxy inverse, ou se verrouille pendant l’importation d’une vidéo volumineuse. Comparez une petite photo avec la plus grande vidéo en attente.
Des importations en arrière-plan auraient cessé après l’expiration du délai d’une connexion lente et n’auraient repris qu’après le redémarrage de l’application. Le schéma pertinent est un délai d’expiration qui tue le processus en arrière-plan.
Testez d’abord sur un Wi-Fi local stable en utilisant l’adresse locale du serveur, puis via le nom d’hôte distant habituel. Si la sauvegarde locale fonctionne mais que la sauvegarde distante se bloque, vérifiez les limites d’importation du proxy, les délais d’inactivité, TLS et les changements de réseau mobile.
Tenir compte des originaux stockés uniquement dans le cloud et du stockage optimisé du téléphone
Sur les téléphones utilisant le stockage cloud optimisé, la miniature visible peut représenter un original qui n’est plus stocké localement. L’application de sauvegarde doit d’abord télécharger l’original depuis le cloud avant de l’importer sur le serveur domestique.
Une discussion Immich décrit une grande photothèque iOS optimisée dans laquelle l’application devait télécharger des dizaines de milliers de photos avant de vérifier les doublons et de procéder à l’importation. Cela crée une dépendance au téléchargement depuis le cloud que la planification en arrière-plan peut ne pas maintenir.
Laissez le téléphone en charge sur un Wi-Fi stable et assurez-vous qu’il dispose de suffisamment d’espace libre local lors de la première migration. Envisagez d’importer directement sur le serveur une exportation officielle du cloud, puis d’utiliser la sauvegarde du téléphone uniquement pour les nouveaux fichiers une fois l’ancienne bibliothèque vérifiée.
Réinitialiser uniquement l’état de sauvegarde dont l’obsolescence est avérée
Déconnectez-vous puis reconnectez-vous uniquement après avoir enregistré l’adresse du serveur et confirmé les identifiants. Effacez une file d’importation bloquée ou les données locales de l’application uniquement lorsque celle-ci fournit une procédure de récupération prise en charge et que le serveur contient déjà des originaux vérifiés.
Le guide ZimaSpace consacré à la sauvegarde des photos d’iPhone sur un serveur domestique énonce la règle générale selon laquelle la fin de l’importation doit être vérifiée avant de supprimer les originaux du téléphone ou du cloud.
Le problème est résolu lorsque de nouvelles photos de test sont importées sans laisser l’application ouverte, que les transferts interrompus reprennent, que les fichiers non pris en charge ne bloquent plus la file d’attente et que la progression en arrière-plan reste fiable lors de la mise en charge, des changements de Wi-Fi, des redémarrages du téléphone et des mises à jour de l’application.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
