¿Por qué se detiene la copia de seguridad de las fotos del teléfono cuando la aplicación se ejecuta en segundo plano?
La copia de seguridad de las fotos del teléfono se detiene en segundo plano cuando el sistema operativo móvil suspende la aplicación o una transferencia fallida impide el siguiente lote programado.
Las aplicaciones de fotos autoalojadas no reciben ejecución ilimitada en segundo plano. iOS y Android deciden cuándo puede activarse la aplicación según los permisos, el estado de la batería, las condiciones de red, el uso reciente y la presión sobre los recursos del sistema. El proceso de copia también puede atascarse debido a un archivo no compatible, una sesión iniciada caducada, un servidor inaccesible o un original almacenado solo en la nube que primero debe descargarse. Determina si la aplicación nunca se programa, si se inicia y se detiene o si falla repetidamente con el mismo archivo.
Confirma si la copia de seguridad funciona con la aplicación abierta
Conecta el teléfono a la red Wi‑Fi habitual, mantén la aplicación en primer plano y observa el número de elementos pendientes, el nombre del archivo activo, la velocidad de transferencia y el registro del servidor. Esto demuestra si la autenticación, la accesibilidad del servidor, el almacenamiento y la selección de álbumes funcionan antes de involucrar la programación en segundo plano.
Los usuarios de Immich han informado de que las cargas se detienen inmediatamente después de salir de la aplicación, aunque la configuración de copia de seguridad estuviera activada. El síntoma distintivo es que la carga en primer plano funciona, pero el progreso en segundo plano se detiene.
Si la copia en primer plano también falla, continúa revisando la URL del servidor, el certificado, el inicio de sesión, el almacenamiento y los errores específicos de los archivos. Si la copia en primer plano avanza con normalidad, mantén esas capas sin cambios mientras pruebas la programación y las restricciones del sistema operativo.
Comprueba los permisos en segundo plano y la configuración de actualización del sistema
En iOS, verifica la actualización en segundo plano de las aplicaciones, el acceso a la fototeca, el acceso a la red local cuando sea necesario, las notificaciones si la aplicación las utiliza y el modo de bajo consumo. En Android, comprueba la optimización de batería, los datos en segundo plano, el uso de batería sin restricciones y si el fabricante tiene una lista adicional de aplicaciones en suspensión.
Un informe de Immich para iOS muestra que la aplicación afirmaba repetidamente que la actualización en segundo plano estaba desactivada, aunque la configuración del sistema ya estaba activada. El caso demuestra que el estado de la aplicación y el del sistema operativo pueden no coincidir.
Activa y desactiva el permiso correspondiente solo como restablecimiento controlado, vuelve a abrir la aplicación y verifica que reconozca la configuración. No desactives globalmente toda la protección de batería; exime únicamente la aplicación de copia de seguridad de fotos si la plataforma lo requiere.
Distingue la programación móvil normal de una tarea atascada
El trabajo en segundo plano es oportunista y puede no comenzar inmediatamente después de apagar la pantalla. Registra si la copia se reanuda más tarde, después de poner el teléfono a cargar, tras volver a conectarlo a la red Wi‑Fi o después de abrir brevemente la aplicación.
Los usuarios de Android han informado de fallos en la sincronización en segundo plano incluso con la optimización de batería y las restricciones desactivadas, lo que demuestra que los permisos por sí solos no demuestran que la programación funcione.
Usa un álbum de prueba pequeño con varios archivos JPEG normales. Si esos archivos terminan cargándose en segundo plano, el programador del sistema funciona y el fallo de la biblioteca completa probablemente se deba al tamaño o tipo de archivo, la duración de la red o el estado de la cola.
Comprueba si un solo archivo fallido detiene el lote
Abre la pantalla de detalles de la copia de seguridad e identifica el primer nombre de archivo que falla repetidamente. Registra su extensión, tamaño, ubicación de almacenamiento, estado de edición y si el teléfono puede abrir el original sin descargarlo.
Un problema de Immich describe que la copia de seguridad se detenía al encontrar archivos .pic no compatibles, en lugar de omitirlos y continuar. El fallo clave fue que un archivo no compatible bloqueaba la cola.
Saca el archivo del álbum seleccionado para la copia o expórtalo a un formato compatible y vuelve a intentarlo. No elimines el original hasta que exista en otra ubicación verificada y el resto de la cola se haya completado.
Prueba en condiciones de red lentas o interrumpidas
Comprueba si el teléfono cambia entre Wi‑Fi y datos móviles, se desplaza entre puntos de acceso, pierde la conectividad de la VPN o del proxy inverso, o se bloquea durante la carga de un vídeo grande. Compara una foto pequeña con el vídeo pendiente más grande.
Se ha informado de que las cargas en segundo plano se detienen después de que una conexión lenta agota el tiempo de espera y no se reanudan hasta reiniciar la aplicación. El patrón relevante es un tiempo de espera agotado que termina el proceso en segundo plano.
Prueba primero con una red Wi‑Fi local estable usando la dirección local del servidor y, después, mediante el nombre de host remoto habitual. Si la copia local funciona pero la remota se atasca, revisa los límites de carga del proxy, los tiempos de espera de inactividad, TLS y los cambios entre redes móviles.
Ten en cuenta los originales almacenados solo en la nube y el almacenamiento optimizado del teléfono
En los teléfonos que usan almacenamiento optimizado en la nube, la miniatura visible puede representar un original que ya no está almacenado localmente. La aplicación de copia debe descargar primero el original desde la nube antes de cargarlo en el servidor doméstico.
Una conversación de Immich describe una biblioteca grande de iOS optimizada en la que la aplicación tuvo que descargar decenas de miles de fotos antes de comprobar duplicados y cargarlas. Esto crea una dependencia de descarga desde la nube que la programación en segundo plano quizá no pueda mantener.
Mantén el teléfono cargando, conectado a una red Wi‑Fi estable y con suficiente espacio libre local durante la primera migración. Considera importar directamente en el servidor una exportación oficial de la nube y, después, usar la copia del teléfono solo para los archivos nuevos una vez verificada la biblioteca histórica.
Restablece únicamente el estado de copia que haya demostrado estar obsoleto
Cierra la sesión y vuelve a iniciarla solo después de guardar la dirección del servidor y confirmar las credenciales. Vacía una cola de carga atascada o los datos locales de la aplicación únicamente cuando esta ofrezca una vía de recuperación compatible y el servidor ya contenga originales verificados.
La guía de ZimaSpace sobre cómo hacer una copia de seguridad de las fotos del iPhone en un servidor doméstico establece la regla general de que debe verificarse la finalización de la carga antes de eliminar los originales del teléfono o de la nube.
El problema se resuelve cuando las fotos de prueba nuevas se cargan sin mantener la aplicación abierta, las transferencias interrumpidas se reanudan, los archivos no compatibles dejan de bloquear la cola y el progreso en segundo plano sigue siendo fiable al cargar el teléfono, cambiar de red Wi‑Fi, reiniciar el teléfono y actualizar la aplicación.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
