¿Qué es el estado de Immich y qué partes deben conservarse?

El estado de Immich es el conjunto combinado de medios, base de datos, identidad, configuración y datos derivados necesarios para reproducir el comportamiento previsto de la biblioteca.

Los archivos originales son esenciales, pero no constituyen toda la aplicación. Los álbumes, usuarios, propietarios, rostros, representaciones de búsqueda, asignaciones de rutas y secretos determinan cómo aparecen esos archivos y quién puede utilizarlos; algunos son autoritativos, mientras que otros pueden reconstruirse con un coste.

Los medios originales y las relaciones de la base de datos forman el núcleo

Las fotos y los vídeos originales conservan el contenido irreemplazable. La base de datos conserva cómo Immich interpreta ese contenido: usuarios, propietarios, álbumes, identificadores de recursos, metadatos y relaciones de procesamiento. Cada parte por separado queda incompleta cuando el objetivo es restaurar el mismo servicio doméstico y no simplemente recuperar archivos sueltos.

La guía de copias de seguridad de Immich de ZimaSpace explica que una protección integral incluye los medios subidos y la base de datos. Esta distinción proporciona una definición útil del estado: los medios responden a qué bytes existen, mientras que los registros de la base de datos responden a cómo la aplicación asocia, presenta y controla esos bytes.

Asigna la base de datos y cada ubicación de medios originales a rutas duraderas del host o del sistema de almacenamiento. Confirma que las bibliotecas externas estén protegidas por su propia política. No deduzcas la persistencia a partir de una ruta interna del contenedor; inspecciona el volumen efectivo o el montaje bind que sobreviva a la eliminación y recreación del contenedor.

La configuración y los secretos recrean los límites del servicio

Las definiciones de Compose, la configuración del entorno, las asignaciones de almacenamiento, las reglas del proxy y la configuración del proveedor de identidad determinan cómo los servicios encuentran los datos y entre sí. Las contraseñas, el material de firma y las credenciales de API también deben conservarse de forma segura. Reconstruir los archivos sin estos ajustes puede dejar la base de datos accesible con una identidad o unas rutas incorrectas.

Un análisis de planificación del almacenamiento de Immich separa la ubicación de la base de datos y las miniaturas del almacenamiento masivo de los originales. Su lección es arquitectónica: un único servicio lógico puede abarcar varias ubicaciones físicas, por lo que el inventario de persistencia debe seguir cada montaje y dependencia, no solo un directorio del proyecto.

Guarda las definiciones del despliegue en un sistema de control de versiones después de eliminar los secretos. Conserva los secretos en una copia de seguridad cifrada o en un gestor de secretos con una ruta de restauración documentada. Registra el propietario y los permisos de los montajes bind. Durante una prueba, verifica el acceso del servicio a la base de datos y la lectura de medios antes de habilitar el acceso remoto o aceptar nuevas cargas.

Los datos derivados se pueden reconstruir, pero son importantes desde el punto de vista operativo

Las miniaturas, los vídeos codificados y algunos resultados de aprendizaje automático pueden regenerarse a partir de entradas autoritativas, según la versión y los registros conservados. Excluirlos puede reducir el tamaño de las copias de seguridad. El coste es tiempo, capacidad de cálculo, calor y menor capacidad de respuesta mientras un servidor restaurado reconstruye una biblioteca familiar grande.

Una guía independiente de copias de seguridad distingue entre los datos imprescindibles de cargas, biblioteca y perfiles, y las miniaturas y vídeos codificados que Immich puede regenerar. Esto no hace irrelevantes los datos derivados; ofrece a los operadores la posibilidad de elegir entre el tamaño de la copia de seguridad y el tiempo necesario para recuperar una navegación y reproducción completamente preparadas.

Mide una tasa de reconstrucción representativa antes de excluir los datos derivados. Multiplica con cautela según la combinación de recursos afectada e incluye las escrituras de almacenamiento y la competencia con las cargas en primer plano. Si el retraso resultante incumple el objetivo de recuperación, protege determinadas rutas de datos derivados o mantén capacidad de cálculo adicional para la ventana de reconstrucción.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Demuestra la persistencia con una prueba de destrucción de contenedores

Utiliza un clon desechable del despliegue, nunca producción. Registra las sumas de comprobación de algunos originales, un álbum de prueba, dos cuentas con distintos niveles de acceso y una búsqueda conocida. Elimina únicamente los contenedores clonados conservando el almacenamiento persistente declarado; después, recrea la pila a partir de la configuración y los secretos guardados.

Un informe comunitario sobre persistencia describe cómo Immich volvía a mostrar la configuración inicial después de los reinicios porque el directorio de la base de datos previsto en el host permanecía vacío. Es un ejemplo aleccionador de por qué una ruta configurada no demuestra que las escrituras lleguen a ella; el estado observable debe sobrevivir a la operación real del ciclo de vida que se afirma proteger.

Da por superada la prueba solo cuando ambas cuentas reaparezcan, la pertenencia a los álbumes coincida, las sumas de comprobación de los originales sean iguales y la búsqueda conocida funcione como se espera o entre en un estado de reconstrucción documentado. Cualquier reinicio inexplicado identifica una persistencia ausente. Actualiza el mapa de estado antes de confiar en la automatización de copias de seguridad basada en los mismos supuestos.