¿Qué debe restaurarse conjuntamente para que una biblioteca de fotos autoalojada siga siendo searchable?
Restaura los originales, la base de datos del catálogo y la configuración que define las rutas como una unidad de recuperación.
Para una biblioteca NAS doméstica como Immich, Lightroom, PhotoPrism o similar, solo los archivos de imagen pueden abrirse nuevamente, pero se perderán personas, álbumes, calificaciones, ediciones, ubicaciones y resultados de búsqueda. Una recuperación que permita buscar debe alinear los archivos multimedia con la base de datos o catálogo que los describe, la configuración que mapea sus rutas y cualquier secreto o versión de la aplicación necesaria para leer ese estado.
Define la capacidad de búsqueda como algo más que abrir archivos originales
Una biblioteca de fotos es buscable cuando la aplicación puede conectar cada original con su registro en la base de datos, metadatos, membresía en álbumes, asignaciones de personas y ruta. Poder abrir un JPEG demuestra recuperación de archivos, no recuperación de la biblioteca.
Una discusión sobre la recuperación en Immich muestra que la base de datos contiene ubicaciones de archivos y metadatos de la biblioteca, mientras que las fotos reales permanecen en las carpetas de carga. Restaurar solo un lado puede producir miniaturas o registros que apuntan a originales ausentes.
Escribe el resultado requerido antes de restaurar: los originales se abren, las fechas de la línea de tiempo son correctas, los álbumes aparecen, la búsqueda de personas funciona, las ediciones o calificaciones regresan y los usuarios mantienen acceso. Ese resultado define qué componentes pertenecen a la unidad de recuperación.
Restaura los originales y el catálogo desde el mismo límite temporal
El árbol de medios y su catálogo deben representar el mismo punto de recuperación. Una base de datos más nueva puede referenciar archivos que faltan en una copia de medios más antigua, mientras que un catálogo más antiguo puede ignorar fotos que existen en el disco.
Un caso de recuperación de Lightroom requirió una restauración en dos pasos: primero la carpeta de fotos, luego una copia de seguridad del catálogo coincidente de antes del incidente. La misma dependencia aplica a bibliotecas autoalojadas que almacenan ediciones, calificaciones, personas o álbumes fuera de los originales.
Selecciona la marca de tiempo común más cercana entre la copia de seguridad de medios, el volcado de base de datos y la copia de configuración. Si no existe un punto común, restaura en una instancia aislada y reconcilia la diferencia antes de exponer la biblioteca a los usuarios.
Preserva las rutas, identificadores y configuración que unen las piezas
Un catálogo puede estar sano y aún mostrar activos faltantes cuando la ruta restaurada, el nombre del montaje, el identificador del volumen o la raíz de la biblioteca difieren de la referencia almacenada. La consistencia de la ruta es por lo tanto parte de la recuperación, no una tarea cosmética posterior a la restauración.
Los usuarios de Lightroom reportan que los archivos restaurados deben conservar los mismos nombres y estructura de carpetas. Para aplicaciones en contenedores, el equivalente puede ser una ruta de montaje bind, variable de entorno, URL de base de datos o raíz de almacenamiento.
Restaura el archivo Compose o la configuración de la aplicación, variables de entorno, secretos, IDs de usuario y definiciones de montaje junto a la base de datos. No realices relinks masivos ni reescaneos hasta confirmar qué identificadores espera la aplicación.
Separa el estado requerido de los activos de búsqueda regenerables
Los originales, registros de base de datos, datos de usuario, relaciones de álbumes, ediciones y configuración son normalmente requeridos. Las miniaturas, modelos en caché y algunas incrustaciones de aprendizaje automático pueden regenerarse, pero la biblioteca puede permanecer lenta o parcialmente no buscable hasta que esos trabajos terminen.
Una guía actual de despliegue de Immich describe servicios separados para el servidor, aprendizaje automático y cola de trabajos en segundo plano, y señala la programación integrada de respaldo de base de datos. Esos componentes explican por qué la búsqueda y el reconocimiento de personas pueden depender de más que el directorio visible de medios.
Documenta qué activos generados pueden reconstruirse y cuánto tiempo toma la regeneración. Si reconstruir consumiría días de tiempo de CPU o el estado original del modelo no puede reproducirse, protege ese activo como parte de la unidad práctica de recuperación aunque la aplicación pueda recrearlo técnicamente.
Haz coincidir el estado restaurado con una versión compatible de la aplicación
Un catálogo o base de datos puede requerir la versión de la aplicación que lo creó o migró. Iniciar un servicio más antiguo con un estado más nuevo, o viceversa, puede fallar antes de evaluar los medios.
Los usuarios de bibliotecas de fotos han encontrado incompatibilidad de versión de catálogo. Conserva la etiqueta de imagen desplegada, notas de migración y versión de base de datos para que el entorno de prueba pueda reproducir la ruta de actualización esperada.
Inicia la biblioteca restaurada sin conexión o bajo un nombre temporal. Confirma migraciones de base de datos, inicio de sesión de usuario y resolución de rutas antes de permitir que clientes móviles o trabajos en segundo plano modifiquen el estado restaurado.
Valida la búsqueda, álbumes y personas antes del cambio definitivo
Usa una prueba de restauración aislada que incluya fotos representativas antiguas y nuevas, elementos editados, múltiples usuarios, álbumes compartidos, metadatos de ubicación y personas conocidas. Busca registros cuyo resultado esperado ya esté documentado.
El plan existente de respaldo familiar Immich de ZimaSpace proporciona el contexto de planificación adyacente; esta prueba de restauración debe ahora demostrar que esos componentes regresan juntos.
Haz el cambio solo cuando los originales se abran, las cuentas coincidan, los álbumes y permisos regresen, los resultados de búsqueda sean plausibles y una nueva carga se indexe correctamente. Mantén la instancia anterior y los archivos de recuperación sin cambios hasta que la biblioteca de prueba haya sobrevivido a un reinicio y a una copia de seguridad fresca.
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...
