¿Por qué Immich devuelve errores intermitentes durante las importaciones grandes de bibliotecas móviles?

Los errores intermitentes de Immich durante una importación móvil grande suelen significar que una capa falla bajo carga simultánea, no que toda la biblioteca o todos los archivos subidos estén dañados.

Las importaciones grandes combinan el comportamiento en segundo plano del móvil, solicitudes largas, límites del proxy inverso o túnel, escrituras en la base de datos, E/S de almacenamiento, procesamiento de miniaturas y vídeos, y colas de aprendizaje automático. Primero, recopila un pequeño grupo de archivos fallidos y sus marcas de tiempo. Después, determina si el fallo comienza en el teléfono, la ruta de red, el servidor de aplicaciones o una dependencia saturada.

Clasifica el grupo de errores antes de volver a intentarlo todo

Agrupa los fallos por tipo de contenido, tamaño de archivo, dispositivo de origen, ruta de red y hora. Si solo fallan los vídeos grandes, investiga la duración de las solicitudes y los límites de carga antes que la CPU. Si fallan fotos y vídeos aleatorios en los mismos intervalos de mayor actividad, los recursos compartidos del servidor o la inestabilidad de la red se convierten en candidatos más probables.

Un informe de un usuario de Immich de 2026 que describe muchos errores de carga móvil resulta útil porque muestra cómo una gran cola de archivos del teléfono puede provocar fallos repetidos que requieren un diagnóstico por elemento y por ruta. No demuestra que exista un único error universal del cliente móvil.

No selecciones «reintentar todo» como primera acción de diagnóstico. Guarda los nombres o ID de diez archivos fallidos, un elemento de control que se haya cargado correctamente y la ventana correspondiente de registros del cliente y del servidor. Un grupo pequeño y conocido permite probar cambios sin generar una nueva avalancha que oculte las pruebas originales.

Compara las cargas locales con la ruta remota habitual

Sube los mismos archivos de prueba pequeños y grandes mediante una conexión Wi-Fi local estable, directamente al endpoint local de confianza; después, repite la prueba a través del nombre de host remoto habitual, la VPN, el túnel o el proxy inverso. Mantén iguales la cuenta y el archivo para que la ruta sea la variable principal.

Un informe sobre fallos de copia de seguridad de archivos grandes muestra por qué los límites de solicitudes del proxy o del túnel deben investigarse en esta línea. El servicio y los umbrales indicados dependen de cada implementación; la prueba general consiste en comprobar si la transferencia local directa funciona mientras la ruta remota falla de forma constante.

Si ambas rutas fallan con los mismos archivos, sigue las pruebas del servidor y del almacenamiento. Si solo falla la ruta remota, revisa el tamaño máximo del cuerpo, el almacenamiento en búfer de las solicitudes, los tiempos de espera de inactividad y lectura, la terminación TLS, los cambios de red móvil y las retransmisiones. Cambiar la concurrencia de las miniaturas no reparará una solicitud que nunca llega por completo a Immich.

Relaciona los errores con el crecimiento de las colas y la presión sobre los recursos

Las importaciones grandes pueden seguir aceptando cargas mientras se acumulan tareas en segundo plano. Observa la CPU, la presión de memoria, la latencia de E/S de bloques, la capacidad de respuesta de la base de datos, los reinicios de contenedores y la finalización de tareas durante la ventana del fallo. Un uso elevado por sí solo no es una prueba; la métrica debe cambiar al mismo tiempo que aparecen los errores.

El artículo de monitorización de recursos de Docker sobre las métricas de CPU, memoria, red y disco de los contenedores muestra el valor de comparar contenedores en lugar de consultar un único promedio de todo el host. En Linux, combina las métricas de los contenedores con pruebas de almacenamiento del host y de presión de memoria correspondientes a las mismas marcas de tiempo.

Si la presión de memoria provoca la salida de contenedores, la latencia de almacenamiento aumenta junto con los errores de carga o el tiempo de respuesta de la base de datos se dispara mientras la cola deja de avanzar, reduce únicamente la carga de trabajo o la concurrencia responsable y repite la prueba con el mismo grupo fijo. Si los gráficos de recursos permanecen estables, continúa con los registros de la aplicación y el diagnóstico de la ruta de red.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Considera la tasa de errores y la latencia de cola como señales de carga

Un sistema puede parecer saludable según el tiempo de respuesta promedio mientras un pequeño porcentaje de solicitudes agota el tiempo de espera durante los picos. Registra el número de cargas intentadas, los fallos, el tiempo de respuesta mediano y las solicitudes más lentas durante un intervalo controlado. Así, lo «intermitente» se vuelve medible en lugar de anecdótico.

El marco de pruebas de carga para el análisis de errores y latencia recomienda analizar las clases de estado, los problemas de conexión, las distribuciones y las correlaciones en series temporales. No necesitas someter la biblioteca familiar a una carga agresiva; aplica esa misma estructura analítica a la tasa real de importación.

Si reducir considerablemente la tasa de llegada disminuye los fallos mientras cada archivo individual se carga correctamente, la pila actual no tiene suficiente margen para esa intensidad de importación. Si los mismos archivos fallan incluso de uno en uno, el problema es específico del archivo, de la ruta o un error de software determinista, no una saturación genérica.

Reduce una sola fuente de presión y vuelve a probar el mismo patrón de importación

Elige el cambio más seguro que predigan las pruebas: reduce una sola concurrencia en segundo plano, pausa otro contenedor pesado, utiliza la ruta local, realiza la importación fuera de una ventana de copias de seguridad o corrige el tiempo de espera del proxy. No cambies simultáneamente los límites de CPU, el almacenamiento, las reglas del proxy y las versiones de la aplicación.

El flujo de trabajo de ZimaSpace para las interrupciones de las copias de seguridad de fotos del teléfono ofrece la línea de investigación del móvil: la programación en segundo plano, los originales almacenados únicamente en la nube y los cambios en las condiciones de red pueden interrumpir las cargas incluso cuando el servidor funciona correctamente.

La prueba es satisfactoria cuando el grupo fijo se carga correctamente y la misma importación grande se ejecuta con una tasa de errores estable, colas que avanzan y un rendimiento interactivo aceptable. Escala el problema cuando los fallos persisten con poca carga o se repiten con archivos idénticos; incluye los registros del cliente, los registros del servidor, el estado del proxy, los gráficos de recursos, el tipo y tamaño de archivo y la primera solicitud fallida.