La ubicación de la base de datos de Immich afecta a la fiabilidad, porque la latencia, el comportamiento del sistema de archivos y la disponibilidad del montaje determinan si las escrituras autoritativas siguen siendo oportunas y duraderas.
Un servidor doméstico puede mantener los originales de forma segura en un NAS y, aun así, volverse inestable cuando su base de datos activa atraviesa el mismo montaje de red. La distinción importante no es simplemente SSD frente a HDD, sino si las operaciones de la base de datos reciben una semántica local predecible y si existen copias de recuperación fuera de ese mismo dominio de fallo.
La base de datos contiene relaciones autoritativas, no solo caché
Immich utiliza su base de datos para conectar usuarios, propietarios, álbumes, registros de recursos, metadatos y resultados del procesamiento. Esas relaciones no se reconstruyen simplemente al encontrar archivos de imagen en el disco. Por tanto, un fallo de ubicación puede dejar intactas las fotos originales mientras la aplicación pierde la estructura que hace utilizable la colección.
El artículo sobre copias de seguridad de Immich de ZimaSpace identifica los originales y la base de datos como el conjunto esencial para la recuperación. Esta distinción explica por qué la ubicación de la base de datos merece un tratamiento más estricto que el almacenamiento de miniaturas: la pérdida o inconsistencia de la base de datos cambia la identidad, el acceso y la organización de la biblioteca, incluso cuando los archivos multimedia permanecen.
Comienza la decisión sobre la ubicación clasificando el estado. Los originales y la base de datos necesitan protección independiente, mientras que las miniaturas y las copias codificadas pueden regenerarse a costa de tiempo. Colocar todos los directorios en un único volumen grande simplifica las rutas, pero también vincula los datos autoritativos y derivados a la misma interrupción.
La variabilidad de la latencia puede convertir las escrituras normales en inestabilidad del servicio
Las bases de datos realizan muchas operaciones síncronas y aleatorias pequeñas cuyo tiempo de finalización importa más que el resultado de una única transferencia de archivos grandes. Cuando la latencia se vuelve variable, las transacciones esperan más tiempo, se acumulan las colas de trabajo y las solicitudes en primer plano pueden bloquearse detrás de cambios de estado. Un montaje puede seguir técnicamente conectado y, aun así, ofrecer tiempos de respuesta poco fiables en la práctica.
Una implementación de la comunidad de TrueNAS mantuvo los datos de PostgreSQL de Immich en un SSD y trasladó las rutas de la biblioteca principal y de los vídeos codificados a almacenamiento HDD. El valor de este ejemplo reside en la separación de los patrones de acceso: los originales que requieren mucha capacidad y el estado de la aplicación sensible a la latencia no tienen que compartir una única ubicación física.
Mide la latencia del dispositivo y la respuesta de la base de datos mientras coinciden las importaciones, las búsquedas y las copias de seguridad. Un gran ancho de banda secuencial no demuestra un comportamiento estable de las transacciones. Si los picos de latencia coinciden con trabajos bloqueados o errores de los clientes, reduce la cola compartida o traslada la base de datos activa a una ruta con una finalización local más predecible.
La ubicación en red añade dominios de fallo relacionados con el montaje y las rutas
Una base de datos en almacenamiento remoto depende del cliente del sistema de archivos del host, la interfaz de red, la ruta de conmutación, el servidor de almacenamiento y el estado de la exportación antes de que se complete cada operación de E/S. Cualquier capa puede pausar o reconectarse de forma distinta a un sistema de archivos local. Los discos redundantes del destino no eliminan esas dependencias intermedias.
Un análisis detallado de Immich Compose desaconseja colocar la base de datos en un recurso compartido de red y la diferencia del almacenamiento de la biblioteca multimedia. Aunque el artículo se basa en las expectativas actuales de implementación, su conclusión arquitectónica perdurable es que la semántica de una base de datos activa y la capacidad para almacenar grandes volúmenes de fotos son requisitos distintos.
Este límite también funciona en sentido inverso: la ubicación local no es automáticamente fiable. Un único SSD de consumo sin protección eléctrica, supervisión del sistema de archivos ni copias de seguridad puede fallar de forma repentina. La ubicación local elimina el comportamiento de los montajes de red de la ruta activa; no proporciona recuperación versionada ni protege frente a la pérdida de todo el host.
Valida la ubicación con una prueba del dominio de fallo
Crea una biblioteca desechable con usuarios, álbumes, cargas y búsquedas conocidas de prueba. Mide la latencia de la base de datos durante una importación representativa y mientras el sistema de almacenamiento realiza su carga normal de copias de seguridad. Registra los errores de la aplicación, el progreso de las colas, las esperas del dispositivo y la solicitud interactiva más lenta, en lugar de basarte en el rendimiento medio.
Una conversación de la comunidad sobre la ubicación en HDD y SSD distingue repetidamente entre la base de datos activa y los datos generados, por un lado, y los archivos de la biblioteca principal, por otro. Los comentarios son informes de experiencias, no una prueba comparativa universal, pero refuerzan la necesidad de probar la clase de E/S que realmente produce la base de datos.
Después, simula el fallo real de la ubicación: desconecta el montaje remoto o detén el volumen local de la base de datos en el entorno desechable. Restaura desde una copia independiente y verifica los usuarios, la pertenencia a los álbumes, el acceso a los originales y el estado de las búsquedas. La ubicación solo supera la prueba cuando tanto el funcionamiento normal como la recuperación cumplen el objetivo establecido.
Centro de Tecnología e IA
Más para leer

¿Por qué Immich vuelve a procesar los datos existentes después de una actualización?
Immich puede reprocesar los archivos cuando una actualización invalida derivados, metadatos, modelos o el estado de los trabajos anteriores; el procesamiento interminable y repetido...

¿Qué dependencias suelen limitar realmente el rendimiento de Immich?
Immich está limitado por la dependencia más lenta de cada ruta medida, por lo que la carga, la búsqueda, la navegación y la reproducción...

Redes de Immich: cómo el descubrimiento, el DNS y el enrutamiento permiten la accesibilidad
Immich solo es accesible cuando la selección del endpoint, el DNS, el enrutamiento, la NAT o gestión del proxy, el TLS y la respuesta...

